I have custom root certs for internal dev sites for my company. That's fine, but I'd like to add the root with a caveat that I control saying "I trust this root for *.mycompany.com,mycompany.org", but that I know means they wouldn't be able to proxy "mybank.com".
I don't think Firefox or Chrome can do that can it?
No, although the root itself could be scoped that way with an X.509 name constraint. But if you add the root then I believe there's no browser policy to otherwise limit the names for which it can be trusted.
On a tangent, do you know off-hand what browser support for name constraints is like? The last time I looked was a few years ago and at the time it wasn't well supported but if that's improved it'd be a good step for intermediate certs.
> It must have been many many years ago, more than 10 at least.
You would be unduly optimistic — for example, Apple did not support them at least as recently as 2015 (see e.g. https://bugs.chromium.org/p/chromium/issues/detail?id=407093...) and 10 years ago OpenSSL hadn't even shipped support upstream, plus however long it took your distribution to ship a major version upgrade to 1.0.
I was hoping someone might have a pointer to current information on that topic since I believe Apple did finally fix Secure Transport but not when.
I am afraid I don't have better information on when but some anecdotal information about the state of it. I have done some limited testing and research for our own internal Root CA I got the impression it works nowadays.
I have not gotten as far as testing it in production but based on testing Safari and Chrome in https://nameconstraints.bettertls.com/ and creating our own name constrained cert and testing it with both OS X Curl and Linux Curl (OpenSSL) I am still of the impression it works.
The last time I looked into it, a few years ago, everyone except Apple had some basic amount of support. (That is, openssl, firefox, windows, and android — that's all I looked into.) I set up my private CA with name constraints, but I had to mark them noncritical if I wanted iDevices to be able to use the CA at all.
But the other systems did at least appear to honor the constraints.
I've asked Apple security folks about this a few times, but they just look uncomfortable and change the topic.
and that would have to be baked into the CA certificate, not specified when the CA is trusted. I dont want my browser to ask the CA what it's allowed to do, i want to tell it what it's allowed to do
It has to be baked into the CA, so that a browser vendor can check it before inclusion. If the CA specifies domains it is not allowed to sign certificates for, it will not be included.
I'd like that as well, for exactly the same purpose.
To the best of my knowledge, no browser can do this today, and I don't know of any other software that can do that either. (I'd want to have it in the system certificate store with the same constraint, as well.)
Name Constraints, as mentioned elsewhere in this thread, wouldn't solve the problem, for two reasons: most software doesn't support them (and silently ignores them rather than correctly failing closed), and they require the CA certificate to contain the constraints rather than system configuration adding the constraints.
We need a mechanism to place certificates in a certificate store (browser or system) with specific domain constraints configured by the administrator. To avoid the failure mode of Name Constraints, those certificates shouldn't be accessible to software that doesn't know to enforce domain constraints.
That would also require updates to various SSL libraries (and to browsers) to handle this new certificate store and enforce the constraints.
> most software doesn't support [name constraints] (and silently ignores them rather than correctly failing closed)
Could you elaborate on this? Specific examples? CVEs? My experience has been that most software will either honor them, or honor the "critical" flag, which is correct (if disappointing) behavior. If you want it to fail closed, use the critical flag. If you want it to fail open, clear the critical flag.
The last time I investigated this this, several years ago, I found that several SSL libraries simply ignored the extension entirely, whether it had "critical" or not. Older OpenSSL did so, for instance.
Doing some additional research, it looks like the situation has improved significantly now, and name constraints might actually work as designed if you don't care about older systems.
That still doesn't address the ability for a browser/administrator to apply such name constraints to a CA that didn't ship as part of its certificate, though.
A mechanism to constrain root CAs to particular URLs/domains was proposed in firefox a while ago[0]. Perhaps an idea whose time has now come?
It seems like the principle of least privilege could easily be applied to the CA system rather than trusting all CAs for all domains, as there seem to be obvious/natural constraints in certain cases (like CAs that only operate under a particular country TLD).
You should be able to do this for Firefox, in two ways, neither of them very convenient, but if you're excited enough about this to put some work in:
1. The actual browser software has its own rules for what's trusted on top of the root trust store often copy-pasted into other software (e.g. in the Python package Certifi). These rules include name constraints of the sort you're interested in, functionally they're used to constrain roots that might be fine but whose government operators promise they're only for some TLDs under authority of that government, so in a sense for those names the government decides who "really" owns them anyway.
Rather than link a horde of HN readers into Mozilla's poor mercurial server I'll point you more indirectly at a summary from their wiki:
You can fork Firefox and add your own rules to NSS, or if you're feeling really fancy, your own extension mechanism to add rules at runtime.
2. You can spin up a root, and trust it, and use that to sign a suitable constrained intermediate. Then, destroy the private key for the root and continue using the intermediate.
In this scenario Firefox gives total trust to your root, but it can't possibly proxy mybank.com because you destroyed the private keys, it can't do anything further at all. The intermediate, which can still issue, is constrained.
Google (I think? Some big tech firm with know-how) has used this trick for products that do loop-back HTTPS. It mints a root cert during instal, issues one certificate and then destroys the private key, then it can trust the root cert but without any danger you later get MITM'd by the root, because that root's private key no longer exists anywhere.
CAA is a mechanism for trustworthy CAs to agree not to issue certificates to people who don't want them.
So if you set CAA to insist you only want Comodo certificates in darkhorn.example, Let's Encrypt will refuse to issue certificates for names under darkhorn.example
But no matter how you set CAA for darkhorn.example, my private CA can issue certificates for it no problem. Let's Encrypt aren't _prevented_ from issuing, they are _declining_ to issue by policy, and that policy is part of why the world trusts them. But the world doesn't trust my private CA, so I don't have to follow that policy.
The state of Kazakhstan is intercepting all encrypted web traffic. They may filter it, block it, inject nasty things (malware etc) or just spy on the populace.
A Certificate Authority is an entity that verifies the identity of websites for your browser. There are only a few CA's in the world and their integrity is crucial because of how your browser trusts them. By making users install a government-issued CA, and also controlling their internet provider, the Kazakh government can pretend to be any website and therefore see all HTTPS traffic from the affected users.
When you connect to a website via HTTPS, your browser downloads the certificate from that website and validates it by checking that the website's certificate was cryptographically signed by an entity that the browser trusts. If the certificate is valid, then you can assume that your data will only be decrypt-able by the website owner, so the connection is secure. Your browser will display a happy green banner showing that the connection is secure, so you can feel safe sending private data to that website without it being eaves-dropped along the way.
The browser checks for validity by ensuring the website certificate is signed by a certificate that is shipped with the browser. These "root certificates" are usually owned by Certificate Authorities, such as Verisign or any other number of CAs. CAs ought to verify that the entity creating a new certificate is who they claim to be (the website owner) before signing a certificate. This way, you trust Verisign to tell you that you can trust the target website.
What Kazakhstan has done is create their own root certificate and asked people who live there to install it in their browsers. They are also intercepting any connection to facebook.com and giving your browser a Kazakhstan-created certificate, which is then verified against the Kazakhstan-owned root certificate. Since it will pass this check, the browser shows a happy green banner, even though the certificate is owned by Kazakhstan and not facebook.com. In other words, the data people in Kazakhstan send to facebook.com is now being intercepted and decrypted by Kazakhstan before being forwarded to facebook.com. Facebook is the example used in the linked bug, they can perform this with any other website, too.
> What Kazakhstan has done is create their own root certificate and asked people who live there to install it in their browsers.
Is this voluntary? If I bring a device into the country without this certificate (or if the local removes it from their machine) do things go back to normal?
Your browser will reject the bogus FB certificate. You can tell your browser to connect anyway with the bogus cert, but it will still be MITM'd. There's no way around this (outside of using a VPN or whatever to effectively remove yourself from Kazakhstan).
Going back to normal, i.e the browser saying that the presented certificate is invalid, yes. But you will not be able to browse anything over a HTTPS connection. (Or do other stuff over PKI based TLS, i.e downloading software updates etc.)
Shoot, I hadn't even considered software updates. If this is installed at the system level, they could MITM any software update mechanism that doesn't use cert pinning, couldn't they? Woof.
Yep... I wonder how common it for "sensitive" software to neither use pinned certs nor some package level signing? But probably common enough that it can be abused...
If you don't have the special root certificate installed, the browser will refuse to connect because the certificate being presented is invalid (it's the government spying certificate, which you don't trust, not Facebook's certificate, which you do trust).
What prevents us from having to trust Verisign (or its employees) or a government warrant, etc. to not do the same?
Can we leverage signed DNS records to add another layer of control needed?
Do we also need encrypted DNS where we can choose who to trust?
Are we stuck with the CA trust model?
You're right, trust is a major issue with any PKI. You can find hundreds of research papers and blog posts and probably even a few whole books on the topic, I'm sure :)
> What prevents us from having to trust Verisign (or its employees) or a government warrant, etc. to not do the same?
Certificate Transparency. Current browsers are moving to not trust any certificate whose issuance wasn't publicly logged. That doesn't prevent an attacker from issuing an MITM certificate, but doing so would permanently burn a CA. (At least, once the policies are in place and enforced.)
Could companies like Facebook, Google, perhaps CloudFlare detect this is happening in anyway I wonder? Are there any characteristics of the non-FB certificate connections that could reliably be detected either in the headers sent to FB, or via client-side JS?
How about comparing the IP address of the request with the IP address reported in requests to the FB server with the IP reported if you make an XHR call to a different domain endpoint that returns your IP? That would compare the physical browser's IP with the MITM 'requestors' IP?
If enough of the centralised sites and CDNs look out for this it would render it a lot less effective. This also turns a undetected user security/privacy problem into an in your face "firewall" from the user's point of view. Now the user asks their tech friend "why can't I see FB" and their tech friends sets them up on a VPN.
Apologies if this is hand wavey I'm not a network or security expert but I am curious about this.
It's been a long time since Verisign was a public CA.
The Verisign brand lives on, but it was acquired by Symantec back in 2010, Symantec then sold their CA business to DigiCert back in 2017. So although you may find certificates with "Verisign" branding on them, that has nothing to do with the company named Verisign.
hmm, certificate pinning will not allow this gov-ca to work for a lot of high profile web sites. i wonder if these sites with cert pins are whitelisted by the kz gov?
--
somehow i missed that HPKP is dead and will be removed from chromium and all the derivative browsers. now google is focusing on Expect-CT
Although pinned certificates have gone out of favor on the web, they are still very frequently used by iOS and Android apps. Last time I checked, the Facebook Messenger app refused to work when being MitM'ed.
I hope they pin on the key, not the certificate. For a mobile app I worked on, I had it pin the public key on the leaf certificate and indeed it would fail to connect in this scenario.
ZaTelecom Telegram channel (https://t.me/zatelecom) claims that that not all ISPs have rolled out the MITM attack. For now, a good solution would be to switch to a different ISP (it's not like in the US, each home has access to 2-5 different ISPs).
Also, users ask everyone to use a VPN. So, I think that they have access to VPNs.
Kazakhstan is blocking some websites, including home pages for Tor and popular VPN services. Also it uses some sophisticated Tor blocking: it establishes TCP connection but no bytes going there, so Tor client just hangs there without error or traffic, I wasn't able to unblock it, though I did not try hard enough. I think that they are blocking connections to popular VPN services as well, but I don't really know. Without access to their home pages it's hard to connect anyway. I know that people successfully using some mobile apps as VPNs, so while they are trying to block VPN, they are not trying hard enough.
I never had any problems with SSH and I operate my own OpenVPN on VPS using standard port and I never had any problems with it as well.
If it does not, could you file a bug report with a complete packet capture (and exact browser version - multiple browsers are preferred)? https://github.com/caddyserver/caddy/issues
(Edit: Reportedly, "not all Internet providers have started MITM attacks yet" so if you do the test, make sure you are on an intercepted network... if safe to do so.)
VPN with endpoint on affected ISP + Installing the cert (which is linked in the issue on Bugzilla) should be the same as just using the affect ISP directly, shouldn't it?
Yeah, it should, unless this is only for residential ISPs, which I strongly doubt. I can't appear to find a Kazakhstan-hosted VPN however, did you find one?
So uh, should I be concerned at all if my connection came back as a likely MITM from my home network in the US? Or is it most likely a false positive caused by my firewall or something?
I tested it both off a VPN and on a VPN from my iPhone yet still had the same result both times.
If your phone is also used for work, you might have gotten a root certificate installed through their MDM program. Check Settings>General>About>Certificate Trust Settings for a root certificate.
iOS is tricky because of its weird rules regarding TLS libraries and web views. If you are sure you haven't any rogue CA certs in your applicable trust stores, it's probably a false positive.
On this machine I get "likely" in firefox, "unlikely" in a firefox private window and "unlikely" in chrome. Not sure what to make of that.
(Also all of the installed extensions are also enabled in private mode. I know that changed recently so I checked. Also the certs the browers claim I'm getting in all three scenarios seem to be the same...)
Probably an outdated implementation of our rules, regarding Firefox on your machine. Feel free to file an issue; also we will be switching to Cloudflare's mitmengine (based on the same research paper, but they have way more resources to keep it maintained at scale, thus making it more accurate) in Caddy 2 in a matter of months.
It also said "Likely MITM" for me (Firefox on CentOS 7), but the SHA256 certificate fingerprint in the browser matches the one seen by Qualys (https://www.ssllabs.com/ssltest/analyze.html?d=mitm.watch), so at least in my case it seems to be a false positive.
I just tested with ExpressVPN via their Kazakhstan endpoint. On 46.244.29.XXX on the ISP A2B IP B.V. I don't seem to be MITM'ed at all, so I can't report anything about the MITM-detector.
Thanks for the report. Both I and Cloudflare[1] are interested in any updates. If you know your connection is being MITM'ed by your ISP or your government please do the test again if it is safe to do so.
This sort of misbehavior is, unfortunately, common to a number of VPN services that claim to have endpoints in many unusual countries. ExpressVPN has sort of owned up to it (but they don't exactly make those disclosures obvious); others have not.
I find the social aspect of this interesting. Us "smart tech people" have been pushing https everywhere for a few years now as a way of protecting internet privacy "for the masses".
And now the government found a very simple non-technical workaround. Send a message to everyone requiring a government root CA with an easy install, or their internet won't work.
Now "us techies" have to find a new technical solution to a very social problem.
The goal here is to validate that one is communicating with whom they think they are. That's as pure a technical goal as you can get. Oddly this is still an unsolved problem on the internet. BTW any solution to this problem will be attacked or shot down by governments and companies around the world.
But we are in a better place than before. Without HTTPS everywhere and governments needing to ask people to install new root certs, we would not have learned about this Kazakhstan MITM issue.
It's a tough problem because certificate pinning kills a lot of legitimate use patterns; it's not something I'd like to see being the default everywhere.
You mean CA? There are many options depending on which agency and which target you are talking about. They have few options from stealing a CA from a legitimate CA user if the want anonymity or use one that is built in to your browsers or systems somebody else already pointed out in the thread.
I haven’t immersed myself into the details of the Room 641A scandal, but it does indeed sound awful. I do not approve of the operations of NSA/Five Eyes.
But let my re-phrase my question like this: Do we have any evidence that NSA can perform MITM on TLS 1.3? Using a federal US CA would be one way, tricking a CA to issue fraudulent leaf certificates would be another, but as established elsewhere in this thread, both those ways are quite noisy. Attacking the endpoint is another way, but once Mallory does that, all bets are off.
It's not a technology problem, it's a social one. If a society values it's privacy enough then it will change.
The real issue is how abstract the consequences of loss of privacy are. It requires people to actually think beyond "I've got nothing to hide".
No worries though. Greedy corporations and governments are greedy and they'll keep pushing the limits of societie's tolerance until it blows up in their face.
No. we just feel better because it just sounds so obviously reasonable doesn't it?
Kazakhstan's low-tech approach is just that, low-tech and low-effort. They could have used tons of vectors besides simply saying "install this cert."
A tiny shred of effort would have been to package an "updater" that did the install without explicitly saying that's what it was for. Or better yet: Kazakhstan is committed to a greener more ecologically friendly future! All tax documentation will go paperless! Just use the provided USB Key to access your documents in electronic format!
A small morsel of effort would be to force it on OS vendors through regulation/licensing/threats/money for localized copies. A good deal of effort would hijack CRLs, pinnings, et al while demanding/sneaking the private keys of the CAs.
Public Key Infrastructure is fucking pointless when the infrastructure is precisely what you can't trust.
Chrome, etc., require that certificates which descend from publicly trusted roots have their certificates published in certificate transparency logs. Someone would quickly notice bogus certs being issued and the associated root would get blacklisted.
This is why certificate transparency is required now - it means that we no longer need to trust the CAs to tell us when they’ve issued an unconstrained intermediate or cross signed a root. Previously it was essentially luck that led to CA malfeasance being detected.
Especially in the post-finally-ending Symantec world the CAs understand that issuing any such cert is likely to very quickly end their business in most other countries.
I feel the real problem kz is going to have is that they have now demonstrated that they will abuse having a root cert, so there is no way any root stores will let them in in future. I imagine they’d even have difficulty getting any of the other roots to issue certs for them (managed sub-ca I think? I forget terminology)
We still would have easily found out had any of these methods been employed; any uncompromised machines still left in the country when they flipped the switch would start getting TLS warnings.
They could, of course, avoid spying on uncompromised machines to avoid detection, but then anyone practicing good security hygiene would be automatically left unaffected by the government spy program. Plus there'd still be the possibility of detecting malware through other means (malware on client machines is far easier to detect than MITM of unencrypted communications). Not to mention how much more difficult all this would be than simply MITMing unencrypted traffic.
The situation with HTTPS is significantly improved.
No, it's not pointless. This attack was detectable because of PKI. Without it the attack would not have been detectable.
Being imperfect is different than being pointless. Even if you developed the perfect algorithm for global security infrastructure, the Kazakhstan government could still just break down your door and implant the backdoor into your hardware if they wanted. So by your logic should we just forget about this encryption stuff and just do everything in plain text again?
Intel ME is indeed scary stuff, but I think you need to provide stronger evidence if you want to convince us that governments can snoop on anyone anywhere just because of ME.
> Public Key Infrastructure is fucking pointless when the infrastructure is precisely what you can't trust.
This seems a cynical and lazy evaluation of the situation. No solution is perfect, trade offs must be made everywhere. With the right precautions the average person can have his/her communications encrypted. This is a much better situation than the one we were on before.
We need new measures to not allow these certificates to be installed unless they're verified, or at least the OS shows a massive giant warning "DO NOT DO THIS unless you accept this cert gives $identity access to all your data".
Which is, tbqh, a useless solution. Oh wow, now an attacker just has to include some obfuscated javascript encryption lib. Bam. Exfil detection completely bypassed.
For example corporations might want to make sure that worker is not sending e-mails with confidential data from its gmail. Sophisticated thief surely will circumvent that kind of protection, but a lot of thieves are stupid, so simple measures actually work.
I mean, the choice being presented is to install the MITM cert, or to not use the internet at all. The latter is an answer, certainly, but not what I would call a very good solution.
It's a common meme that users will click "yes" to everything, but I'm not sure people realise just how far that goes. Look how it looks when Chrome marks a site as malware:
Wait until you're doing forensics on a cryptolocker outbreak and you find not only did a user do that, but multiple users helped her through it and the management then praised her for overcoming technical barriers even after it was found to be the cause of the incident.
Unfortunately nothing about warnings makes anything a solved problem.
This is why I'm always advocating for political engagement for fighting these kind of issues. It's not exactly hard for a government to ban or forbid circumventing their monitoring. It does take time, but they're about to catch up.
It’s far harder if you have a major tech industry to push back and the whole massive security risk this exposes big corporations to. Which is something Kazakhstan must not have much of.
This is also terrible for foreign investment and attracting business. It also makes foreign intelligence’s job easier.
You’ve got their priorities mixed up. Staying in power is more important than foreign investment if you’re an authoritarian government. What’s the point of growing the economic pie if you’re not in a position to profit from it ?
Now if you’re a politician in a democracy, you know it may be all over in about 8 years, so it’s more your interest to cosy up to the companies
It’s rare for a politician to only work 4yrs at the policy making level. Most of them are career politicians these days or retired wealthy people, not people with regular jobs giving politics a shot. Yet they all seem to be wealthy in the US, even after years of public service, regardless of their overt stance on business politically. Which is something the big firms can always rely on.
Maybe this sort of interruption is manageable when half of your 18 million people are rural and the economy isn't heavily dependent on internet traffic. Try doing this in a more urban populated country and you will see a much different outcome.
to be fair some of us told from the beginning that making all user used to trust the green check would have caused this sort of trust fatigue to the point the majority would have stopped bothering with the actual certificate content and trust chain, and you can search my history highlighting this very issue in relation to let's encrypt, it was a social issue from the very beginning and I got downvoted heavily and repeatedly because apparently "techies" can't be bothered with exceptions and failure modes once a catch all solution is found
We don’t want users to trust the green check, because it never meant you could trust a site. We do want users to distrust plaintext, because it means the café you’re visiting can steal your password. I don’t see how this is a good criticism of the push for HTTPS everywhere (which appears to be the context here).
because cafe can just ask people 'install this extension to navigate' and non-tech users being users will fall for it most of the time, because state actor can do even worse, and once we trained the users that non green check is dangerous they won't have the knowledge to distinguish between "insecure with no check" and "maybe secure with check but I've to control every time the details", people will shortcut that part, until some researcher finds our for them and even then it's not guaranteed that the message will reach everyone
Exactly - this is why we don't want to train people that non-TLS traffic is insecure, but rather keep them from encountering it, ever, ideally. TLS must be the default- a baseline- and deviating from that baseline must be at least as hard as getting a user to install a malicious extension.
Ever SSHed into a server and been told by your SSH client that, oh, by the way, the server is using the NULL cipher with no authentication, and network attackers can mess with your session arbitrarily? Probably not. That's what using plaintext HTTP should feel like.
I think you're missing one important detail: the idea behind the green padlock is that the average end user isn't technically capable of (or shouldn't have to) monitor all the details of their internet connections to make sure they're secure.
If that basic intuition about users is correct, the solution is not to give up on this and force users to deal with the true complexity of the situation. The solution is for the browser to show a red blinking INSECURE instead of the green padlock when the cert it receives for a site doesn't have a valid chain to a root in the default key store shipped with the browser.
To be honest, I can't figure out why this isn't already the default behavior. It would solve a bunch of other problems as a side effect, including insecure crappy antivirus programs that MITM your internet connection.
if they can force a cert into your os trust store they can force a cert into your browser trust store, this solves some very specific issue but not this one.
this is kinda rich under an article where they forced a cert into the is trust store. it takes the same amount of effort to get the cert into browser specific stores because these need to be editable and an installer get control of the system anyway
"it rather involves being already at the other end of this airtight d doorway"
the current page ask the user to run an installer, elevating privilege. there's nothing a browser can really do against that. DLL can be replaced and signatures can be tempered etc.
just because you said "ship them with the browse" doesn't make you magically right nor safe under the linked threat
Alerting the user when a MITM certificate is active in the trust store is relying on a completely different threat model than "protect the entire operating system against state-mandated malware". I'm saying browsers should at least do the former. You seem to think that's pointless unless they also do the latter, but of course they can't do that. Some security of the trust store is better than no security.
Will oscp stapling be able to be used to detect "something fishy" going on, because in that case the root ca wouldn't actually match. Do browsers compare the oscp root with the root of the current chain?
Actually, if it's mitm it's "all bets are off" isn't it, because the KZ government can filter that it out the proxied response?
Still, if oscp can assist at all, it's probably worth it that the browsers check for mismatch (if they don't already)
Browsers always trust manually installed CA roots, because that scenario is used by many corporations to monitor their traffic. OCSP, HPKP, etc won't help.
For mobile apps, though, you can bootstrap HPKP with a key built into the app. I worked on an app doing this, and it would certainly fail to connect in this scenario.
One solution is to use Name Constraints. The organizational certificate authority could be issued with Name Constraints limiting its power to a certain domain name only, e.g. *.example.com, using Permitted Subtree.
If I was setting up an organizational CA for internal websites (not MITM), I would consider using Name Constraints to limit the certificate's scope and potential for abuse or compromise.
There are more benign uses too - many organisations run an internal PKI, and installing their root CA prevents employees' browsers from displaying warnings about untrusted certificates when accessing internal web apps/sites.
You might be able to make intranet.company-name.tld and have a parking page on the company-name.tld and use that to get a wildcard cert that can be used for the internal pages.
However you would have a single wildcart cert + key that would need to be placed on thousands, or tens of thousands, of machines, by hundreds of staff is dozens of departments.
It would be meaningless.
I can prove ownership and then receive a wildcard certificate for *.internal.company.com, usually by a TXT record or similar (lets ignore EV certs for now), however that certificate isn't an intermediate certificate which is limited to signing new end certificates for blah1.internal.company.com, but wouldn't be able to sign for blah1.not.company.com.
I'm no SSL/TLS expert by any means, so please let me know if I'm wrong and it is fairly easy to get intermediate certificates that are domain name limited - x509 constraints are apparently flakey.
Letsencrypt only issues certs for publicly accessible hosts. If you've got a bunch of intranet servers / REST services / whatever that are firewalled from the public internet, you're out of luck.
> Letsencrypt solves any need for legitimate certificates.
... unless you want any private keys to be personally signed and or generated by bob & alice over in security after checking some boxes in an internal audit form, or any other number of company-internal schemes involving signing and encryption of business-specific data
You're generating private key securely. You're generating CSR which contains public key and signed by that private key and now you need to move that CSR from private location to a public location. But that's not bad, it does not contain anything that could be compromised and your private key is kept safe. Then you're using letsencrypt to issue that certificate using that CSR and keep using that CSR (it does not expire) to renew certificate. All that time private key is kept in safety and is only used by your webserver.
Letsencrypt allows you to generate legitimate certificate for internal websites without any compromise on security.
The only use-case that's not possible with Letsencrypt is to issue certificate for IP address.
I don't think it's a bad use. When I logon to my SAN or UPS web interfaces, I don't want to type https://ups01.publicDNSdomain.com, and visit a site with a CT logged certificate. It's an absolutely internal thing and every Active Directory domain already has an (ideally) non-externally resolved DNS domain setup for use. You've already got an internal CA and deployed your own root because there's a series of Microsoft services that work best this way, so it makes a lot of sense to continue to use rather than trying to introduce Lets Encrypt in this scenario.
You don't have to serve that website publicly or even set up DNS records. You only need to set up DNS verification to serve one public TXT record for letsencrypt. Everything else could be internal. Letsencrypt certifies that you own domain. You can do anything with that domain.
Well, it's unnecessary work to install and maintain that internal CA. Keeping CA key safe is very important, because leaked key might lead to your internal connections to, e.g., Google be compromised, so it's like keeping a bomb inside your building. If you already have that internal PKI, you can use it, sure, but I still think that it's a bad idea to use it only for internal websites.
Sometimes you don't want to make that information public though. For security (you don't want to publish your whole tech stack information) and secrecy (you don't want to publish registration of halflife3.internal.valve.com).
Wildcard certs are a security ops nightmare. You really don't want to throw the private key for that around to every small project, and you need some good, automated way of rolling them across multiple services. Doable, but if you can avoid this, it's a better to avoid.
This 100x - in just about any organisation of any size, if you use a single wildcard cert for all internal services, then it's inevitable that the private key will end up in the hands of an employee that shouldn't have it.
If they're scrutinizing you closely, I would not trust my life to it. If the hash of the cat gifs you're exchanging is different from others, eventually there's going to be too much or too little entropy in those pixels and they'll make a strong statistical case against you.
> Now "us techies" have to find a new technical solution to a very social problem.
Cert pinning does mitigate it for apps, doesn't it? The end-user doesn't need to really worry abt rouge root CAs, if my understanding is right.
Traditional VPNs, P2P VPNs, Tor as a Proxy (decentralised net? dat/i2p/freenet/ipfs) could solve it generally across various use-cases, of which, VPNs are already mainstream.
Not necessarily. We have rolled out SSL inspection at my company and have to exclude certain apps (e.g. Dropbox, Google Drive) or else they won't work. The FW just blocks the connection and the user gets a SSL/TLS error.
Sure, but then instead of the government saying "hey, run this thing or else your app won't work," they can only say "your app doesn't work now." Spying on you is still prevented.
I dont think pinning will work with for example letsencrypt. You can pin many certs but if you loose them all you are screwed. If you check your root cers you will likely find one from every major ISP in your country.
You would usually pin an intermediate, so for Let's Encrypt that would be Let's Encrypt Authority X3 (it might also make sense to pin Let's Encrypt Authority X4 as a backup)
And er, no, the overlap between operators of public Certificate Authorities and national ISPs is very small. There are only 57 root CAs trusted by Mozilla.
> Cert pinning does mitigate it for apps, doesn't it?
Applications where the developer has pinned to their own certificate will stop this attack.
Chrome and Firefox will ignore pinning for locally installed CAs. This is a very common use case in the enterprise where, for example, a bank has audit requirements to decrypt and store all workstation traffic.
It'll "stop this attack" by ensuring that the app won't work through the MITM - so it won't be able to connect from any Kazakhstan users unless/until the pinning is removed.
You don’t need to pin against a state. Just deselect Kazachstan as a region where your app is offered, because it’s not going to work anyway if you try.
One of our ("tech people") main failures was that, while we made a heavy push for server authentication, we didn't make a similarly strong push for client authentication. With client certificates, MITM like that is not possible, unless the server also trusts the MITM CA to authenticate its clients (and uses a CA for the client certificates in the first place, instead of a direct mapping between users and their certificates).
Email is similarly unencrypted by default and can be blocked if encrypted and being used as an active circumvention vector. Yes, mail servers outside the jurisdiction could work until https access to gmail is also blocked- but that’s not outside the realm of possibility (see: China) and also begs the question: how do you get to your secure gmail web interface if you need to receive a secure email before your first login?
Using CAs to authenticate clients is subject to the same attack. They block communication from any client that won't disclose its private key to the MITM box or use it to encrypt/sign whatever the MITM requires it to.
You can't have security if you have a MITM that says "compromise your endpoint or we block you" and you concede to that. The only real solutions are either political or making the encrypted traffic look like some permitted traffic. (Or using a different network.)
> Using CAs to authenticate clients is subject to the same attack.
You don't need to use a publicly available CA to verify client-side certificates. The server could use its own internal CA to sign CSRs from clients and send the reslting certificate back to the client via email or some other means.
In which case the MITM will be unable to connect to the server because it won't have the certificate (that you sent via email or some other means), so the service simply won't work. That's the whole point, you either go through MITM or not at all.
Somewhat related: if there were a shared password between the client and server, Password Authenticated Key Exchange techniques [0] could offer protection even when the server CA was compromised. PAKEs use zero-knowledge proof techniques to assert that each side already had password material (and derive a key from it) without revealing what the actual password was if the other side didn't have it to begin with.
In this case, only connections where a password was already agreed on would be protected vs. general unauthenticated browsing.
There was a draft proposal to add PAKE support to TLS 1.3, but it appears to have unfortunately expired [1].
TLS 1.3 was in some part an exercise in removing crap people thought might be a good idea in earlier versions, but then either never used or turned out to be a terrible idea but was notionally "optional" so you could say to keep using TLS but just disable that feature. So there is skepticism pre-existing in that room against the idea of just adding more stuff than might be cool unless it's clearly _needed_.
A feature that keeps six people in Kazakhstan (who happen to have manually pre-configured a PAKE) safe but everybody else is still screwed isn't the sort of impact TLS 1.3 was looking for.
It's just the way this universe works. The struggle is eternal. Probably built into the root parameters of the Big Bang, if you could somehow trace it that far back in time and causality (which you probably can't, I dunno).
I'm less pessimistic. The practical result of this is likely just going to be more business for the cottage industry of Great Firewall VPNs, which already compete with one another in traffic obfuscation against an adversary far more sophisticated than the government of Kazakhstan. Thankfully, this is currently a case in which the incentives of the market happen to align well with the goals of defeating censorship.
> Flag anything that isn't obvious plaintext or already being MiTM'ed for analysis follow up.
The failure being that the long tail of uncategorized data would be large.
Do you have a good reference for what game state updates look like for every game on the internet? What about custom IoT device protocols? Every type of DRM used for media streaming? Document attachments of spreadsheets or database images containing arbitrary numeric data?
How do you distinguish data like that, which outside of some headers may be indistinguishable from random numbers, from someone using the same format or protocol for encoding arbitrary encrypted data?
In an authoritarian state, you just start blocking and breaking things.
Everything you don't understand, you block. And then you make the user explain it to you and then if it's a use case you care about, you do the work to either decide it doesn't have any danger of carrying traffic you care about or build an intercept scheme for it.
Ethernet can carry protocols other than IPv4. IPv6 is one of them, but there were at one time a whole slew of them, like IPX and Appletalk. But ISPs don't carry them, so they're effectively blocked and have largely died out, and everything uses IPv4 or IPv6. Even if you want to use Appletalk today, you encapsulate in IPv4 or IPv6.
There are also a whole bunch of IP transport protocols other than TCP and UDP, but firewalls have a tendency to block them, so today people just encapsulate everything in TCP or UDP.
There are a lot of TCP and UDP ports too, with their own protocols, but those darn firewalls again, so now everything is increasingly using HTTP[S].
The things that get blocked never go away, they're just made to look like whatever is still allowed. Yes sir, Mr. Firewall, this is Hypertext Transfer Protocol over SSL on TCP port 443 using IPv4, which is approved for intercept.
Except that it's really email and games and file downloads and whatever else, with things added daily by everyone on the internet, and no reference for what all of that plaintext is even expected to look like.
So you say you're going to get a DPI classifier and try to distinguish all these different types of HTTP. Except that whatever you exclude will soon be right back encoded as formats and protocols you allowed, because information theory says you can encode anything into anything.
And it gets harder to distinguish them with every iteration, because what you're really using to distinguish them is their encoding inefficiency -- it's the things that are always the same for a given class of data, even though the relevant part of the message is the things that are different. The end state of all of this is that the real entropy is all that's left and there is nothing there to distinguish with anymore.
I'll be 40 years old later this year. I've been interested in communications and communications protocols since I was about 12. I've been a software developer with a focus on network communications for over 15 years.
I'm well aware of all that you've said.
My point was, they get TLS interception down, and they capture what they want from a target of interest.
When they look closely at your traffic and decide all these cat gifs have too much or too little entropy in the data that forms their pixels, they simply (if they're courteous) say, "Persuade me that you did not know that this app was helping you hide messages back and forth. Persuade me or we shoot you now." And then they shoot.
You're proposing that the penalty for being suspected of subverting the firewall is death. In those cases you're going to want a highly refined system for avoiding detection, and it's also very important that one exist, because regimes that oppressive deserve to be opposed.
Fortunately the more typical case isn't kidnapping and execution but only having your connection blocked, which creates a helpful feedback loop that enables continuous improvement in the ability of secure communications to avoid detection. Which benefits everybody, but especially those in violent authoritarian countries that need it all the more.
No disagreement here. What's being done is despicable.
Rather than death, if we look at the history of oppressive societies, the more likely outcome is a job offer, the kind they won't let you refuse but they'll make it so you don't want to refuse anyway. They find the clever people who are working around the filters and interception and hire them to be the watchers. They get perks like time to spend on a real private connection, etc. Meanwhile they are required to contribute to making the noose ever tighter.
> You're proposing that the penalty for being suspected of subverting the firewall is death.
no, he's being hyperbolic to make the point that in an extreme situation, a default-deny approach could facilitate mass suppression of 'undesirable' traffic without creating an insurmountable backlog of traffic for the 'bad actor state' to review in determining what to process further.
> no, he's being hyperbolic to make the point that in an extreme situation, a default-deny approach could facilitate mass suppression of 'undesirable' traffic without creating an insurmountable backlog of traffic for the 'bad actor state' to review in determining what to process further.
Only it doesn't, because as soon as they allow anything, everything else starts to look enough like whatever is still allowed to make it through, because that's the only way to make it through.
Slashing away more things only increases the resources people will put behind making arbitrary traffic look like allowed traffic. It trades not having to review everything for having to fight everyone instead of only the people they want to block.
Then some people win, everyone copies the winners' methods to get through, and you're back to square one only now everything looks even more like everything else than it did before.
I could split hairs and suggest that the browser accept the phony CA and simply use a secondary encryption layer on top of it, but that misses your point. A sufficiently clever evil government will see that you're doing something encryption-like and shoot you.
But, being "sufficiently clever" isn't all that easy. China has done a good job, but they're a very big country with a lot of resources and a lot of very smart people, and let's be honest, even as good as they are, anyone with a will to get that censored information will get it.
It costs a lot to censor people on the Internet. The goal of people like me is not to stop the most determined, intelligent censorship approaches, but rather to make them as expensive as possible to build and maintain.
My ideal is force governments to either accept the Internet without censorship, or almost completely disconnect from the Internet (and simultaneously deny their nations the competitive advantages that come with it). North Korea is a good model. They basically don't have Internet in North Korea. It's sad, but I can live with that; it's better than allowing an oppressive regime to benefit from the Internet while oppressing their citizens.
"Sufficiently clever" has historically been more expensive than difficult.
For example, in order to scale less expensively, the Great Firewall is architected such that it need not actively be in the middle of the entire flow of traffic and need not actively proxy. Historically, they didn't need it to do so in order to achieve their goals.
Now, however, the advancement of a combination of new technologies is finally closing that gap.
In order to maintain historic blocking capability it becomes necessary in the long run to actively MiTM all the connections.
But that can be made to scale and there are nations who can afford it.
How do we know? Because the job is not significantly harder than serving up all that content. (At worst it's a little more than 2x the work.)
And today most content is served up from a handful of privately owned infrastructures. If a corporation can build it, so too can a lot of nation-states.
In that case, the old field of steganography might become useful. Embed illegal content within legal content and figure out another means of sharing the decryption scheme.
> Everything you don't understand, you block. And then you make the user explain it to you and then if it's a use case you care about, you do the work to either decide it doesn't have any danger of carrying traffic you care about...
You say "authoritarian state", sounds to me like the network at many employers and institutions in the US!
> An agency is tasked with doing random sample captures
not really, we know exactly what the government response is and it's turning citizen one another, that applied with the gestapo back then and it's happening today with the "social credit system"
why do all the random sampling work if all you need is one "regime believer" among a hundred person or so to maintain full awareness of dissident activities.
I was certain I read a few years ago that Google would mandate that all OEMs would be forced to use a single unified certificate list, which I thought at the time was a way to pre-empt this sort of thing. But I can't find any new info about that anywhere. I only found an article about how to add new certificates on new Android versions in 2019, so I guess you can still change them.
I wonder if Google changed its mind about this once Sundar Pichai took over and then gave Project Dragonfly the greenlight.
Except I look at the linked mailing list and you already get "us techies" arguing "uh yeah but uhm this isn't so different from the corporate CA intercept thing right so let's not blacklist it uhm".
Yes? This isn't that complicated. You break it, and when competitive browser X refuses to do so, you sell the idea that browser X is compromised for all users everywhere (not just in Kazakhstan)
Stop thinking about the country with literally less than 1% of world internet users and start thinking of the reputational damage a less than charitable presentation of your collaboration with a totalitarian state against your users would do to the other 99%+ of your market.
Which is bad news for the ~15m internet users in Kazakhstan. For the ~4000m internet users not in Kazakhstan & generally immune to their rubber hose attack, protecting them from being one BGP fuckup away from being MITMed by a hostile foreign power is much more important.
Apple is openly collaborating with Chinese regime, including allowing the government to snoop on all Chinese traffic, yet they still have a high reputation for privacy. This just doesn't work, people don't give a shit about other countries.
There's a broader reason. If the normal browsers break this, the response will just be that they do their own national fork of an open-source browser and distribute that to their people.
The downside of pushing them to that is that that browser will be unlikely to get regular security updates and will likely hide the interception.
If you want to put a stop to things like this, then you have to. Complaints from companies and the general population should be enough to fix the issue.
Is it better to be complicit with an authoritarian regime that is actively spying on their people, in order to have a marginally larger user base? I don't think so.
In fact, you're making it worse because you're giving legitimacy to a government that is conducting actions which we shouldn't consider acceptable. If the US government started doing the same thing, I would really hope that browsers would block those certificates too.
Actually, I don't see the issue here. It is literally the same thing as corps intercepting the connections of their employees or visitors. In fact I trust my employer even less than I trust the government.
But I disagree with the response that says we should do nothing. In fact, corporate root certs should be blocked / ignored by the browser in the exact same way and for the exact same reason. The only exception should be certs issued for a limited number of domains that are only active in a specific developer mode that can be enabled by knowledgeable users.
Sure, technological solutions can't solve this issue 100%. (My employer can also fork a browser.) But acting as if everything is OK when the connection is being MITMed is wrong and browsers shouldn't do it.
> corporate root certs should be blocked / ignored by the browser in the exact same way and for the exact same reason ... technological solutions can't solve this issue 100%
Technological solutions can't solve this at all if the entire stack is controlled by the interested party.
In the case of government snooping, you (theoretically) own the end device being used for access. In the case of corporate snooping, you're using corporate owned and managed devices. There is absolutely no technological solution that exists that will prevent another person from building software for (or selling to) corporations who need to snoop on their employees. Considering the selling price of appliances that perform these services (e.g. Bluecoat's range), the cost of a browser is negligible in comparison.
I don't think it's fair to conflate a lack of privacy on corporate owned devices with a lack of privacy on your own personal devices.
Unfortunately governments like that will continue to do low effort workarounds as long as they have police and military forces to respond to those who don't conform.
Everything can be justified by national security. You can't try and block something with "an end-less series of law suites" if the defending party doesn't even need to provide any kind of proof. "Why are we MTiMing HTTPS? This is un-constitutional! -- Because internet is a threat to national security which in turn has higher priority than your rights, Citizen!. Everything else is classified and will be discussed in a closed court." Take a wild guess what that court is going to decide...
Aren't some US providers (Comcast, Verizon?) injecting nasty tracking/advertising into HTTP pages?
That's extremely worrying as well and it appears politics so far are unwilling to make it illegal. There needs to be more protest and more competition so consumers can vote with their wallets.
The solution is to warn users that their security+privacy is compromised, and let them make their own informed choice. Techies don't often see that their own wishes shouldn't trump those of individuals (but maybe we're getting into politics now)
Another technical solution would have been to allow security without privacy. If the purpose of the government actions is just to monitor content, you can enable that without disabling security. The HTTP protocol could be modified to transmit checksums signed by a cert, so that a client can verify that content has not been modified, but that content can be (optionally) not encrypted, but still no content-injecting attacks can take place.
But privacy advocates don't like it, so the result is either you have total security + privacy (such as it is), or none at all.
They should just put a red dot on the browser bar somewhere indicating a non-normal root cert is being used (this would also help in dev / test scenarios).
That would help people who already know what a root cert is, but it's well known that most people ignore any indicator in a URL bar. Even "smart people" ignore them. Do you actually check the lock status of every site you visit?
Also, it would be great if there were a "red dot" style warning when you manually click "Proceed anyway" while viewing a https page with an invalid certificate (currently, the browser remembers the "Proceed anyway" decision and accepts the invalid cert after the initial acceptance of the warning)
There's the big red X over the HTTPS icon in the address bar in Chrome and I'm pretty sure there's something similar done to the padlock icon in Firefox, no?
This is actually the subject of some debate, believe it or not, there is a good argument against it.
Here is the crux of the issue, many TLS middleware providers install their own root certificate for network monitoring, data loss prevention, security scanning and so on. I personally would like them to stop doing that or at least make it obvious to end users it's happening. However, in order to modify the root store, they must have been authorized to do so by the Administrator, and it's their network or hardware.
If we try to make it obvious to users that this inspection is happening, these providers will switch to using alternative methods, such as using Microsoft Detours - which would be even worse, now you have random vendors patching security critical code in such a way that is not discoverable for end-users. This cannot be prevented, because they must already have Administrator access or they wouldn't have been able to modify the root certificate store in the first place.
In this Kazakhstan scenario, imagine if adding the government certificate put a red dot that said "You are being monitored". If the government didn't like that, they could instead require you to install monitor.exe that had the exact same effect, but didn't show the dot by patching and hooking all the crypto APIs. I find this argument against adding an obvious indicator quite compelling.
In this case though, it seems like the government has no problem with telling people they're being monitored. The fact that they're willing to tell people to install a TLS certificate is indicative of that.
I think companies in the US are legally required to provide similar disclosure when monitoring their employees, so I don't see why they'd have a problem with a persistent indicator like that.
In this case though, it seems like the government has no problem with telling people they're being monitored
Not at all. They spin it as providing security:
"Due to frequent cases of theft of personal and credential data, as well as money from bank accounts of Kazakhstan, a security certificate was introduced that will become an effective tool for protecting the country’s information space from hackers, Internet fraudsters and other types of cyber threats.
...
What is a security certificate?
A security certificate is an electronic certificate that allows to protect Internet users from content that is prohibited by the laws of the Republic of Kazakhstan, as well as from malicious and potentially dangerous content. The security certificate is intended to provide subscribers of cellular communication in Kazakhstan with Internet access in the most secure manner."
Companies will typically want their employees to know they are being monitored for legal reasons (as well as deterrence), so it seems like they'd have no reason to want to hide this?
Maybe clicking on the red dot could show a page with company policy.
This is a silly argument. You might as well say that Firefox should include an option to silently submit all your keystrokes to a designated endpoint, because after all if you have access to set that option you have access to install a keylogger.
So what if they could, in theory, work around the indicator by asking users to install some dubious live-patching executable? Firstly, the users wouldn't have to do so - the enforcement mechanism here is ultimately the MITM itself, so as long as the users just installed the certificate they could continue to access sites (they would have to make the certificate available separately, for installation on iOS / Android / ChromeOS etc). Secondly, the security implications of live-patching the executable are mostly irrelevant, because the only people installing this have already lost the security game. Thirdly, there is a benefit in making the bastards work for it - keeping that live-patcher up-to-date and working against a range of target executable versions is going to be bitter work.
Warning: what follows is completely baseless speculation, and let's concede that right off the bat.
Who's to say that this isn't happening in the US as well? The US has invested billions of dollars in dragnet surveillance that is allegedly useless for anything other than metadata in the context of HTTPS.
Is it out of the question to ask whether our secret courts could issue gag orders and claim that national security mandates CA root keys? Such a gag order would only be served to a small group of engineers at large companies, and those engineers would have no right to report on it. We're talking about only a few hundred FISA gag orders, and thousands are served annually. It would make
their multibillion dollar infrastructure useful again, wouldn't surprise me if some (unnamed, anonymous) judge bought the argument.
To employees at vulnerable companies, what's your PKI like? Is anyone aware of a company that implements strong multi-party checks on accesses to important private keys? If the NSA wanted your keys, how many employees would need to be served gag orders? Is it on the order of dozens or hundreds?
If the NSA was using their own certificates to MITM all HTTPS traffic it would be easily noticed by security researchers. Its not like they obtain the private keys of every US company. They'd have to make their own replacement certain for every site they wish to intercept. That could easily be noticed by security professionals and targeted companies by monitoring.
There are a lot easier ways to exfiltrate data than wholesale breaking TLS encryption and MITM'ing 295+ tbps of domestic traffic. That said, every super power is working on better decryption capabilities.
Event just a single site from the alexa 100 would be too obvious. I'm sure some security researchers and/or companies are already monitoring the certificates issued from major websites for abnormalities.
Earlier this would probably have been a somewhat plausible solution, but not even then for mass scale surveillance.
Assume NSA et. al had access to trusted CA private keys, then they could generate certificates for arbitrary domains which would be trusted by clients. But if they MITM'ed _all_ connections (or even a large portion) surely someone would have noticed, like in the DigiNotar case [0].
But it's even harder (or better) now, with the advent of Certificate Transparency. Since browsers check certificates, periodically, against the CT logs which would fail for forged certificates [1].
However, stealing private keys from companies themselves is a practice that I can imagine happening on a small scale, like the Realtek signing keys for Stuxnet [2]. But doing that on a large scale is not really sustainable.
The larger the conspiracy theory is, the higher the risk that someone will simply decide it's worth whistleblowing on. The whistleblowing could even be effectively done anonymously in this case. Secret Government surveillance of end to end encrypted data in the US would be such a huge news story and public interest that it wouldn't be difficult to find engineers willing to take the risk of anonymously providing evidence of it to the press.
A "few hundred" gag orders placed on engineers about something deeply outrageous sounds completely implausible as lasting secrecy. Secrets simply can't be kept at that scale.
Even NSA employees themselves would eventually refuse to keep such a program secret, as we saw with Snowden.
I could of sworn there are instances where root authorities had brush ins with the law, maybe I'm just remembering a theoretical rant I heard somewhere.
SSH doesn't depend on certificate authorities, it's up to you to manage your own keys, each end point also has a uniquely generated signature which avoids MITM after first time auth (including by taking over domains).
This is a HTTPS only issue and fundamentally it's the same problem as control over domains (ease of manipulation through centralisation).
As far as I know, both the apps you mentioned use HTTPS. However, apps have the option of doing what's called Certificate Pinning.
That's when the application ignore OS/User trust settings about certificates, and just allows a list of hardcoded certificates / certificates signed by a hardcoded CA. Akin to how SSH works (kind of...).
If I remember correctly both Telegram and Instagram have pinned their certificates, which would probably block all network communication but not allow for a MITM attack, even if the user installed the KZ root certificate.
I think all Facebook apps do this, and probably most major apps from big companies. I tried to do some research on what requests the Facebook app was making on my phone and it was pretty difficult to get it to allow me to use Charles proxy (when I installed the cert on my phone the app just stopped working) because of the certificate pinning. The only way this would work is if the government created their own FB, etc. app and somehow distributed it.
I guess you'd have to install the certificate on your phone too. I guess that means that visitors to Kazakhstan won't have internet access during their stay, unless they install the malicious certificate on their phones as well. I really hope this doesn't set a precedent.
Just don't install that certificate. If something stops working, you'll know that they tried to break that channel. If something's working, then it's OK. And if you need things to work, use VPN.
99% of the population will happily install the government cert, and life will move on.
The 1% will either put up with it, stop using the internet, or leave.
One thing will happen though - the economy will not be ruined.
Generally speaking, since the Cold War ended, these sorts of countries don't mind troublemakers leaving. It's better international PR for them to have 'problem people' leave voluntarily, than to repress them.
For example there's no way for my LG TV to install that root CA, so all that smartness basically rendered useless, unless LG would issue new firmware for that region and I'm not really sure that they would care enough. I bet that there are plenty of devices that would stop working. Think about all those IoT devices. I could imagine some kind of eye surgery laser device to stop working because it can't connect to its Zurich servers to check license. Yes, it won't cause revolution, but there will be a lot of issues.
Think more towards break everything, as you would end up with out of date broowsers being used. This will have the side effect of causing almost the whole country to be vulnerable to attack.
They probably will issue alternative Firefox and Chromium build. That would be worse. Though if entire tech industry will fight this attempt, like Windows will stop updating, macOS, iOS, Android, etc, probably they will step back. But I don't think that anyone would do so. Especially because that scenario is legitimate and widely used by corporations to control their perimeter and Kazakhstan ultimately does not differ.
Have other governments requested their citizens to install country specific CAs? For some reason, I thought China already employed this practice (although I guess they wouldn't need to, as they just tend to block everything that isn't government approved).
I'm from Kazakhstan using the biggest Internet provider (Kazaktelecom) and that's not true for me. No MITM here. May be not yet. Also checked mobile provider (Activ) and no MITM here too. But I saw local news, so probably not fake, though I'm not sure if it'll be mobile internet only or all providers.
Same here. Haven't yet got any SMS or notifications from my mobile/home ISPs, but couple of my friends are reporting that they did / there are many posts at social media, proving the fact, like this one: https://www.instagram.com/p/B0Do5IOHjab/
> This comment on the mozilla.dev.security.policy mailing list says that right now it's only for users in the nation's capital
I'm from capital (Nur-Sultan, former Astana).
I just checked my wife's phone and apparently she got SMS. Funnily enough, her cellular internet now does not work at all. Probably rollout is not going easy.
What is interesting is that some local internet providers in Kazakhstan used to inject their own ads into http websites their users visit. I wonder if they will start doing the same with https now.
I noticed this behaviour last February with Kazakhtelecom (telecom.kz) internet provider. When I opened an http website in my browser and started clicking randomly on the parts of the page which are usually not clickable, sometimes such click would open a pop-up window with ads. Those pop-ups did also open sometimes, when I clicked on links of the page. It was unusual, because I used the same websites just a few days before that from Russia and nothing like that happened.
To figure out what's going on I opened the same webpage through proxy and compared it with localy opened one. Shell command for that was something like:
And the only difference was that directly downloaded webpage contained a reference to some suspicious script in a place, where the proxied one had a reference to a google analytics script. I reproduced this behaviour with multiple websites from two different homes, on two different laptops (Linux and Windows). So this is unlikely to be a malware in my router, and I'm pretty sure it's not in my laptop.
I'll be back in Kazakhstan in 3-5 days, I'll try to reproduce this once again.
This is so bad. I'm from India and at my parents place we have the government run internet provider. They MITM and inject advertisements all the time showing annoying popups whenever you open an http link. I don't know how this is legal even.
I'm in the US and I've caught my ISP doing MITM exploits over http (not https... so far). It's global and regular folks have absolutely no chance of knowing what is going on. Needs to be criminalized for any hope of resolution.
1. Please stop self-generalizing. This only leads to hopelessness, which is unwarrented since there's a huge amount of Internet-related activism in India, even more than the Western countries.
2. Plese stop using the label "Third-world". You are your own "first-world". There's better labels to describe yourself, namely "developing".
The present judiciary in India lacks spine, on one hand they say privacy is fundamental right on other hand they drag their feet to stop the project aadhaar which required collecting biometric dataset on whole population.
And their defense claims US has SSN which is equivalent of Aadhaar why anyone can see ludicrous
And still Aadhar requirement is not removed for filing income tax return (which results in massive penalities)
I wonder if they also proxy stuff like the Google endpoints where chrome does key pinning, or if they whitelist those. I imagine other large systems like those of facebook (when using the app) and Apple are actively remembering what the keys are supposed to look like. That would mean that even a custom CA wouldn't allow carte blanche MITM.
Chrome will disable key pinning for CAs that are user installed rather than system provided (to support companies/schools who want to MITM for slightly less draconian reasons).
I do wonder if Chrome will go to requiring CAs for this purpose be deployed via something more “enterprise” (e.g. custom extensions on Windows need to deployed via group policy now).
Regardless of where the cert store is, it came with some CA certs "in the box". Pinning applies to these CAs. Any CA's added by the end user (aka person at the keyboard, or enterprise admins, etc) bypass pinning.
For better or worse, bypassing of pinning is required in some enterprise scenarios to inspect traffic leaving the network. e.g. Is someone attaching all our customer data to a email in gmail? To know that, I need to MITM mail.google.com.
”Any CA's added by the end user (aka person at the keyboard, or enterprise admins, etc) bypass pinning.”
But how would Chrome know if a root cert from Windows’ cert store was added by the user or not? They would all be located in the ”Trusted Root Certification Authorities” container.
"The" Trusted Root Certification Authorities store isn't a real thing, it's just a view onto a bunch of different stores that are actually separate, including a local machine store and per-user stores plus of course stores added by your membership of a domain or other grouping.
So Chrome gets to distinguish between certificates that Microsoft added and the ones added by Group Policy or whatever else to your system.
Very interesting. It would be neat to put a service together that could crawl a site from different restricted countries to observe / track what is injected (assuming they aren't just wanting to MITM for visibility).
Comcast used to do this to me about 6 or 7 years ago to tell me, or someone, about torrent use on the connection and something or other about copyright infringement. They'd inject their messages into the html of websites and you'd have to dismiss them to continue to use the site. Not their site. All sites.
I had ads injected by some European and UK ISPs on my own website. I pushed me to finally get LetsEncrypt implemented and switch everything over to https.
> What is interesting is that some local internet providers in Kazakhstan used to inject their own ads into http websites their users visit.
Several ISPs (including some big national players, not smaller local/struggling/other ISPs) trialled that sort of thing in the UK in the mid/late 00s but there was a big enough ruckus about it that they stopped.
The really egregious thing about what some of them were doing is that they replaced existing ads so were basically trying to take money of the sites (they were at the same time also trying to get sites to pay or be considered "low priority" traffic so were trying to tripple-dip: get paid by their primary consumer, get paid by the sites, and take the sites' ad money).
It doesn't surprise me that it is actively happening in places there is less choice (so "voting with your feet" is not an option for telling ISPs what you think) or public outcry is less effective (or drowned out by more pressing issues the area might have).
I had a similar experience with my ISP in Canada. Infact, I did a talk on how I worked out what was going on from a technology perspective: https://www.youtube.com/watch?v=_YeaYIPM-QI
If you want to conduct some testing, I'd be more than happy to help.
If I visit https://gmail.com, I expect all traffic to be encrypted because my browser checks that gmail is indeed using encrypted connection. How is this getting intruded upon?
More importantly, suppose I checkin to a hotel in USA as I usually do and use the hotel's wifi. Would they be able to intrude into my connection to https://gmail.com?
Could someone please give me some clarity on this.
The connection is still encrypted the whole purpose of certificates is to verify with WHO you are connected with. In the Kazakhstan case the government by installing a root certificate has the ability to impersonate gmail.
> More importantly, suppose I checkin to a hotel in USA as I usually do and use the hotel's wifi. Would they be able to intrude into my connection to https://gmail.com?
If the site you visit is over https you can be relatively certain that you are indeed establishing an encrypted connection with the domain owner. If it's plain http anyone sniffing in the same wifi can see and mess with your traffic
> I think this CA should be blacklisted by Mozilla and Firefox should not accept it at all even user installed it manually.
> This will save privacy of all Internet users in Kazakhstan.
No. This will mean that users would simply switch to chrome, edge, brave, ... , n + 1.
In case all of them block this CA, the government will force people to install an older version or will patch any open source browser so that it works with their certificates.
IMO, this is also wrong from a philosophical point of view. Your browser should just be your browser and not take part in political disputes. It doesn't sit well with me that Firefox has anything to say in the politics of its users.
In the United States, for example, it's legal (even expected?) that corporations can install custom CAs into their user's browsers and prevent internet access to any browser without it installed. Is it Mozilla's job to prevent these CAs from being installed on user's workstations? Should Mozilla reject any certificate from Blue Snort, etc.?
Kazakhstan has likewise declared it legal (under their own sovereign legal authority) to prevent web access to its citizens without the required CA installed. Just like it's legal in the US for corporations to "spy" on their employees, it's legal in Kazakhstan for it to spy on its citizens.
Laws of Western countries do not extend into other sovereign nations, regardless of what one thinks of those laws. It's not Mozilla's job to get involved in this case.
> And finally, encryption doesn't solve violence.
Nor abuse of freedom by nation states, unfortunately.
American and European companies and organisations put on loads of protest against acts like SOPA and Article 13. I don't see why this is any different.
Just because a nation state decides on something doesn't mean that foreign entities can't protest that decision. Firefox and Chrome can add very scary warnings to users about government sabotage if they want to; they can even start including ads for Tor and comparable services if they want to. Blocking the cert would at most be very consumer-unfriendly to people wanting the certificate to be in place. If they disagree with a particular browser vendor, those people can switch browsers or fork an open source one.
Mozilla's job is to provide a safe and open web. The Kazakh government is opposing that. In this case, it's perfectly in line with Mozilla's mission to warn users as best they can against the scary precedent their government is setting.
Of course this only works well if Google, Microsoft and Apple join the effort to warn users. Google is already showing a constant warning on Android when a device is being MitM'd and many of their apps do certificate pinning. Facebook and Twitter do certificate pinning in their apps as well.
I don't see why browsers couldn't take action as well. Just don't show any green locks during a MitM and show periodic notifications about the users' security being compromised. Block the certificate if you have to; as a party people rely on for choosing what certificate authorities to trust, they can't allow themselves to be compromised by governments enforcing laws endangering the safety of the web.
You're forgetting the power a discontent population can have on government. In case all browsers took a stance against cooperating with silent MITM, this would be a great pressure on powerful entities not to do it. Governments can get away with suppressing people's online experience for a while, but if they have subpar experience and basic websites won't function properly due to dated browsers, the pressure on governments to get modern browsers may increase.
Given the rise of HTTPS, intentionally or unintentionally, politics now lives in the endpoint (smartphone/tablet/computer)'s tech stack. Some part - the browser (and thus its vendor), the operating system (and its vendor), or some add-on (and thus its vendor) - gets to determine who/what's considered a root CA, and is thus allowed to decrypt message contents.
Can we, endpoints outside Kazakhstan, detect when a MITM client is connected and serve a boiler plate message "Untrusted connection"?
If enough high level sites do this (Google, Cloudflare, Wikipedia etc) it might force the hand of the government since they are the ones effectively breaking the internet.
At what point does this become an OFAC issue for browser vendors based in the states? I would be stunned if someone at Commerce isn't already circulating enforcement memos about this.
I think that's terribly optimistic. I think there are all kinds of people in the US government who would like to be able to point to a success story of a scheme like this, so that they'll have more ammunition in support of implementing it here.
As for whether designating that browser vendors can't distribute software to Kazakhstan, their government would just fork an open-source one, mod it to pre-include their MiTM cert, and force their citizens to use that.
Google, Mozilla, and Microsoft need to take a stand here and blacklist these certs. All of the efforts to move to HTTPS, and all of the rhetoric surrounding it, are just wasted time and empty words if we as a tech community allow this kind of behavior to go unchallenged. This sets such a dangerous precedent, and governments need to know that this kind of meddling will not be tolerated.
That's exactly what will happen if they all-out blacklist. The best near-term option may be a compromise: a special indicator in the browser UI that the connection has been set up in such a way that some organization may be monitoring.
Modern browsers require that leaf certificates which are issued in a chain which descends from a built in publicly trusted root include "certificate transparency" information. This means that the certificate has been published in numerous public logs and so would be discovered.
No doubt the NSA intercepts all kinds of things, but they're not doing it with TLS MITM technology (at least not without further additional hacks).
They don't even need to fork Firefox - there are couple of Russian browsers (https://browser.yandex.com/, https://browser.ru/) that would definitely allow Kazakhstan government to snoop into traffic (and hey even have Kazakh language support already). ISP will just advise clients that bad western companies banned Kazakhstan, so please use good safe Russian browsers.
Let's get Congress to do it - fix the collective action problem. Pass a law that says that all American companies are forbidden from serving traffic to countries which require their citizens to install compromised roots on their personal devices. Treat them like North Korea / Iran.
I'm surprised at comments in the bug threads suggesting they do nothing. The idea being that fighting this would force governments to fork/change browsers, ultimately being a worse experience for users. Seems like betraying people's trust is a pretty bad user experience.
There will always be a fight over privacy. Giving up to a foreign government is a terrible idea. It would absolutely just let the problem spread and get worse.
I don't think Kazakhstan has the resources to replace outside online services. A move like this should simply result in them shooting themselves in the foot. This needs to be a firm line such that it's simply not practical for them to implement.
I understand that bugs/discussions should weigh both sides. And ultimately, we may need more than HTTPS. That's fine. The point is we don't just roll over and give up.
If a government mandates its citizens to install the government’s own root certificate, then it’s not that easy to find a long-term technological solution. The problem here is not a technical one, IMHO. The problem is that the government of Kazakhstan is not respecting the freedom of its people.
IMO what’s needed is first and foremost more democracy in Kazakhstan. That’s not something that Firefox can solve.
With that said, perhaps anti-surveillance technology can assist the affected users. Maybe Tor. I’ve heard about some other, similar project but I can’t recall its name right now.
I don't agree. First off, no matter how you or me may be enraged by the incident, this is not (and shouldn't be!) a "moral problem" for the Firefox. And, by the way, if you are not living in the Kazakhstan, it's not for you to decide "what is needed first and foremost in Kazakhstan", it's their business entirely.
From the point of view of the Firefox, this should be an extremely simple technical problem. There is CA that is known to be "compromised" in an entirely technical sense, i.e. it is known to allow MITM. So blacklist it, end of discussion. Allow the user to remove it from the blacklist somewhere in browser's settings: it's not for you (Firefox) to decide what the greater good is.
I assume, it would indeed be a problem for Kazakhstan to fixing the service if people are not using the internet, because their browser doesn't work (because it's both an economical and a social disaster, obviously). Or maybe it wouldn't, because Kazakhstan will send troops to every home to replace every browser by Kazakh-fox or whatever. And it may play out to the better in the end, as much as it can lead to massacre.
But (as a 3rd party technological company) don't play mighty and powerful, responsible for the lives of people in Kazakhstan, it's not your fucking business how they live. You see a technological problem (known CA allowing MITM) — you solve it (block the CA!). That's what you promised your users to provide, to fix technological problems, not to fix the political climate in Kazakhstan, USA, China, whatever.
> Giving up to a foreign government is a terrible idea. It would absolutely just let the problem spread and get worse.
Their government isn't merley "snooping" on it's citizens due to a week chain of trust architecture and a lack of ethical clarity... it's requiring by law that it's citizens be snooped on and censored. In such a regime, a technological arms race is not going to change the legality of subverting their measures, and cannot help the masses without simultaneously jeopardising their safety.
History contradicts you. There are examples from communist block where technological solutions that bypassed government restrictions helped to spread banned information.
I did not say it cannot help, I said it cannot change the legality of subverting the government, and so cannot subvert the government without simultaneously jeopardising citizens safety.
470 comments
[ 3.1 ms ] story [ 253 ms ] threadI don't think Firefox or Chrome can do that can it?
Any way to avoid or bypass name or path constraints would be considered a huge and monumental vulnerability today.
You would be unduly optimistic — for example, Apple did not support them at least as recently as 2015 (see e.g. https://bugs.chromium.org/p/chromium/issues/detail?id=407093...) and 10 years ago OpenSSL hadn't even shipped support upstream, plus however long it took your distribution to ship a major version upgrade to 1.0.
I was hoping someone might have a pointer to current information on that topic since I believe Apple did finally fix Secure Transport but not when.
I have not gotten as far as testing it in production but based on testing Safari and Chrome in https://nameconstraints.bettertls.com/ and creating our own name constrained cert and testing it with both OS X Curl and Linux Curl (OpenSSL) I am still of the impression it works.
Most other people seem to be sure that it does not though (for example in this discussion and here https://security.stackexchange.com/questions/95600/are-x-509...) so I am not sure if I missed something or if people are just not up to date.
But the other systems did at least appear to honor the constraints.
I've asked Apple security folks about this a few times, but they just look uncomfortable and change the topic.
Modern browsers do respect name constraints of intermediate issuing certificates.
You only need a root if you're issuing other keys.
[1] https://tools.ietf.org/html/rfc5280#section-4.2.1.10
Firefox does, though I don't know how much they check beyond just the dNSName constraints. Here's the unit test making sure it stays working: https://github.com/mozilla/gecko-dev/blob/b8157dfaafc42deb3b...
To the best of my knowledge, no browser can do this today, and I don't know of any other software that can do that either. (I'd want to have it in the system certificate store with the same constraint, as well.)
Name Constraints, as mentioned elsewhere in this thread, wouldn't solve the problem, for two reasons: most software doesn't support them (and silently ignores them rather than correctly failing closed), and they require the CA certificate to contain the constraints rather than system configuration adding the constraints.
We need a mechanism to place certificates in a certificate store (browser or system) with specific domain constraints configured by the administrator. To avoid the failure mode of Name Constraints, those certificates shouldn't be accessible to software that doesn't know to enforce domain constraints.
That would also require updates to various SSL libraries (and to browsers) to handle this new certificate store and enforce the constraints.
Could you elaborate on this? Specific examples? CVEs? My experience has been that most software will either honor them, or honor the "critical" flag, which is correct (if disappointing) behavior. If you want it to fail closed, use the critical flag. If you want it to fail open, clear the critical flag.
Doing some additional research, it looks like the situation has improved significantly now, and name constraints might actually work as designed if you don't care about older systems.
That still doesn't address the ability for a browser/administrator to apply such name constraints to a CA that didn't ship as part of its certificate, though.
It seems like the principle of least privilege could easily be applied to the CA system rather than trusting all CAs for all domains, as there seem to be obvious/natural constraints in certain cases (like CAs that only operate under a particular country TLD).
0: https://bugzilla.mozilla.org/show_bug.cgi?id=501697
1. The actual browser software has its own rules for what's trusted on top of the root trust store often copy-pasted into other software (e.g. in the Python package Certifi). These rules include name constraints of the sort you're interested in, functionally they're used to constrain roots that might be fine but whose government operators promise they're only for some TLDs under authority of that government, so in a sense for those names the government decides who "really" owns them anyway.
Rather than link a horde of HN readers into Mozilla's poor mercurial server I'll point you more indirectly at a summary from their wiki:
https://wiki.mozilla.org/CA/Additional_Trust_Changes
You can fork Firefox and add your own rules to NSS, or if you're feeling really fancy, your own extension mechanism to add rules at runtime.
2. You can spin up a root, and trust it, and use that to sign a suitable constrained intermediate. Then, destroy the private key for the root and continue using the intermediate.
In this scenario Firefox gives total trust to your root, but it can't possibly proxy mybank.com because you destroyed the private keys, it can't do anything further at all. The intermediate, which can still issue, is constrained.
Google (I think? Some big tech firm with know-how) has used this trick for products that do loop-back HTTPS. It mints a root cert during instal, issues one certificate and then destroys the private key, then it can trust the root cert but without any danger you later get MITM'd by the root, because that root's private key no longer exists anywhere.
https://blog.qualys.com/ssllabs/2017/03/13/caa-mandated-by-c...
CAA is a mechanism for trustworthy CAs to agree not to issue certificates to people who don't want them.
So if you set CAA to insist you only want Comodo certificates in darkhorn.example, Let's Encrypt will refuse to issue certificates for names under darkhorn.example
But no matter how you set CAA for darkhorn.example, my private CA can issue certificates for it no problem. Let's Encrypt aren't _prevented_ from issuing, they are _declining_ to issue by policy, and that policy is part of why the world trusts them. But the world doesn't trust my private CA, so I don't have to follow that policy.
https://en.wikipedia.org/wiki/Man-in-the-middle_attack
The browser checks for validity by ensuring the website certificate is signed by a certificate that is shipped with the browser. These "root certificates" are usually owned by Certificate Authorities, such as Verisign or any other number of CAs. CAs ought to verify that the entity creating a new certificate is who they claim to be (the website owner) before signing a certificate. This way, you trust Verisign to tell you that you can trust the target website.
What Kazakhstan has done is create their own root certificate and asked people who live there to install it in their browsers. They are also intercepting any connection to facebook.com and giving your browser a Kazakhstan-created certificate, which is then verified against the Kazakhstan-owned root certificate. Since it will pass this check, the browser shows a happy green banner, even though the certificate is owned by Kazakhstan and not facebook.com. In other words, the data people in Kazakhstan send to facebook.com is now being intercepted and decrypted by Kazakhstan before being forwarded to facebook.com. Facebook is the example used in the linked bug, they can perform this with any other website, too.
Is this voluntary? If I bring a device into the country without this certificate (or if the local removes it from their machine) do things go back to normal?
Can we leverage signed DNS records to add another layer of control needed? Do we also need encrypted DNS where we can choose who to trust? Are we stuck with the CA trust model?
Certificate Transparency. Current browsers are moving to not trust any certificate whose issuance wasn't publicly logged. That doesn't prevent an attacker from issuing an MITM certificate, but doing so would permanently burn a CA. (At least, once the policies are in place and enforced.)
Site owners can monitor these logs for rogue certs issued for their own domains.
If Verisign deliver a certificate with the wrong domain, you'll be able to know that Verisign signed that certificate.
They could certainly say it was a mistake somewhere in the process, but that argument won't work for ever.
At one point sadly you need to trust someone. This model at least give you a way to prove that trust has been broken.
How about comparing the IP address of the request with the IP address reported in requests to the FB server with the IP reported if you make an XHR call to a different domain endpoint that returns your IP? That would compare the physical browser's IP with the MITM 'requestors' IP?
If enough of the centralised sites and CDNs look out for this it would render it a lot less effective. This also turns a undetected user security/privacy problem into an in your face "firewall" from the user's point of view. Now the user asks their tech friend "why can't I see FB" and their tech friends sets them up on a VPN.
Apologies if this is hand wavey I'm not a network or security expert but I am curious about this.
The Verisign brand lives on, but it was acquired by Symantec back in 2010, Symantec then sold their CA business to DigiCert back in 2017. So although you may find certificates with "Verisign" branding on them, that has nothing to do with the company named Verisign.
--
somehow i missed that HPKP is dead and will be removed from chromium and all the derivative browsers. now google is focusing on Expect-CT
ZaTelecom Telegram channel (https://t.me/zatelecom) claims that that not all ISPs have rolled out the MITM attack. For now, a good solution would be to switch to a different ISP (it's not like in the US, each home has access to 2-5 different ISPs).
Also, users ask everyone to use a VPN. So, I think that they have access to VPNs.
I never had any problems with SSH and I operate my own OpenVPN on VPS using standard port and I never had any problems with it as well.
If it does not, could you file a bug report with a complete packet capture (and exact browser version - multiple browsers are preferred)? https://github.com/caddyserver/caddy/issues
(Edit: Reportedly, "not all Internet providers have started MITM attacks yet" so if you do the test, make sure you are on an intercepted network... if safe to do so.)
I tested it both off a VPN and on a VPN from my iPhone yet still had the same result both times.
I currently see "0, 23, 65281, 10, 11, 16, 5, 13, 18, 51, 45, 43, 21".
(Also all of the installed extensions are also enabled in private mode. I know that changed recently so I checked. Also the certs the browers claim I'm getting in all three scenarios seem to be the same...)
[1]: https://twitter.com/grittygrease/status/1151921809417048064
https://restoreprivacy.com/vpn-server-locations/
The code is here: https://github.com/caddyserver/caddy/blob/master/caddyhttp/h...
The paper: https://jhalderm.com/pub/papers/interception-ndss17.pdf
https://www.grc.com/fingerprints.htm
And now the government found a very simple non-technical workaround. Send a message to everyone requiring a government root CA with an easy install, or their internet won't work.
Now "us techies" have to find a new technical solution to a very social problem.
It never ends. :(
But all a government has to do is embed within the endpoint, post-decryption. "Or else."
That’s a pretty high bar to clear though.
They did it to everyone whose traffic transited ATT's backbone
But let my re-phrase my question like this: Do we have any evidence that NSA can perform MITM on TLS 1.3? Using a federal US CA would be one way, tricking a CA to issue fraudulent leaf certificates would be another, but as established elsewhere in this thread, both those ways are quite noisy. Attacking the endpoint is another way, but once Mallory does that, all bets are off.
The real issue is how abstract the consequences of loss of privacy are. It requires people to actually think beyond "I've got nothing to hide".
No worries though. Greedy corporations and governments are greedy and they'll keep pushing the limits of societie's tolerance until it blows up in their face.
It's both, everyone can contribute to the solution or the problem.
Kazakhstan's low-tech approach is just that, low-tech and low-effort. They could have used tons of vectors besides simply saying "install this cert."
A tiny shred of effort would have been to package an "updater" that did the install without explicitly saying that's what it was for. Or better yet: Kazakhstan is committed to a greener more ecologically friendly future! All tax documentation will go paperless! Just use the provided USB Key to access your documents in electronic format!
A small morsel of effort would be to force it on OS vendors through regulation/licensing/threats/money for localized copies. A good deal of effort would hijack CRLs, pinnings, et al while demanding/sneaking the private keys of the CAs.
Public Key Infrastructure is fucking pointless when the infrastructure is precisely what you can't trust.
Chrome, etc., require that certificates which descend from publicly trusted roots have their certificates published in certificate transparency logs. Someone would quickly notice bogus certs being issued and the associated root would get blacklisted.
Especially in the post-finally-ending Symantec world the CAs understand that issuing any such cert is likely to very quickly end their business in most other countries.
I feel the real problem kz is going to have is that they have now demonstrated that they will abuse having a root cert, so there is no way any root stores will let them in in future. I imagine they’d even have difficulty getting any of the other roots to issue certs for them (managed sub-ca I think? I forget terminology)
They could, of course, avoid spying on uncompromised machines to avoid detection, but then anyone practicing good security hygiene would be automatically left unaffected by the government spy program. Plus there'd still be the possibility of detecting malware through other means (malware on client machines is far easier to detect than MITM of unencrypted communications). Not to mention how much more difficult all this would be than simply MITMing unencrypted traffic.
The situation with HTTPS is significantly improved.
Being imperfect is different than being pointless. Even if you developed the perfect algorithm for global security infrastructure, the Kazakhstan government could still just break down your door and implant the backdoor into your hardware if they wanted. So by your logic should we just forget about this encryption stuff and just do everything in plain text again?
In particular, we'd see a lot more places than Kazakhstan do this if good countermeasures weren't in place...
This seems a cynical and lazy evaluation of the situation. No solution is perfect, trade offs must be made everywhere. With the right precautions the average person can have his/her communications encrypted. This is a much better situation than the one we were on before.
Seems a very solvable problem.
Too much security is willing to give up on the 95% because they can't get the 100%.
Trivial technological solutions will not stop the state actor from retaliating against those not following their policy either.
https://www.removemalware.net/wp-content/uploads/2016/06/the...
Wait until you're doing forensics on a cryptolocker outbreak and you find not only did a user do that, but multiple users helped her through it and the management then praised her for overcoming technical barriers even after it was found to be the cause of the incident.
Unfortunately nothing about warnings makes anything a solved problem.
This is also terrible for foreign investment and attracting business. It also makes foreign intelligence’s job easier.
Now if you’re a politician in a democracy, you know it may be all over in about 8 years, so it’s more your interest to cosy up to the companies
but the warning signs were all there i.e. https://news.ycombinator.com/item?id=17298747#17304077
Ever SSHed into a server and been told by your SSH client that, oh, by the way, the server is using the NULL cipher with no authentication, and network attackers can mess with your session arbitrarily? Probably not. That's what using plaintext HTTP should feel like.
If that basic intuition about users is correct, the solution is not to give up on this and force users to deal with the true complexity of the situation. The solution is for the browser to show a red blinking INSECURE instead of the green padlock when the cert it receives for a site doesn't have a valid chain to a root in the default key store shipped with the browser.
To be honest, I can't figure out why this isn't already the default behavior. It would solve a bunch of other problems as a side effect, including insecure crappy antivirus programs that MITM your internet connection.
"it rather involves being already at the other end of this airtight d doorway"
the current page ask the user to run an installer, elevating privilege. there's nothing a browser can really do against that. DLL can be replaced and signatures can be tempered etc.
just because you said "ship them with the browse" doesn't make you magically right nor safe under the linked threat
Actually, if it's mitm it's "all bets are off" isn't it, because the KZ government can filter that it out the proxied response?
Still, if oscp can assist at all, it's probably worth it that the browsers check for mismatch (if they don't already)
Edit: typos
If I was setting up an organizational CA for internal websites (not MITM), I would consider using Name Constraints to limit the certificate's scope and potential for abuse or compromise.
Always seemed like a misfeature to me, but all the browsers do it.
[1] https://chromium.googlesource.com/chromium/src/+/master/net/...
It would be meaningless.
I can prove ownership and then receive a wildcard certificate for *.internal.company.com, usually by a TXT record or similar (lets ignore EV certs for now), however that certificate isn't an intermediate certificate which is limited to signing new end certificates for blah1.internal.company.com, but wouldn't be able to sign for blah1.not.company.com.
I'm no SSL/TLS expert by any means, so please let me know if I'm wrong and it is fairly easy to get intermediate certificates that are domain name limited - x509 constraints are apparently flakey.
... unless you want any private keys to be personally signed and or generated by bob & alice over in security after checking some boxes in an internal audit form, or any other number of company-internal schemes involving signing and encryption of business-specific data
The only use-case that's not possible with Letsencrypt is to issue certificate for IP address.
Cert pinning does mitigate it for apps, doesn't it? The end-user doesn't need to really worry abt rouge root CAs, if my understanding is right.
Traditional VPNs, P2P VPNs, Tor as a Proxy (decentralised net? dat/i2p/freenet/ipfs) could solve it generally across various use-cases, of which, VPNs are already mainstream.
And er, no, the overlap between operators of public Certificate Authorities and national ISPs is very small. There are only 57 root CAs trusted by Mozilla.
Applications where the developer has pinned to their own certificate will stop this attack.
Chrome and Firefox will ignore pinning for locally installed CAs. This is a very common use case in the enterprise where, for example, a bank has audit requirements to decrypt and store all workstation traffic.
You can't have security if you have a MITM that says "compromise your endpoint or we block you" and you concede to that. The only real solutions are either political or making the encrypted traffic look like some permitted traffic. (Or using a different network.)
You don't need to use a publicly available CA to verify client-side certificates. The server could use its own internal CA to sign CSRs from clients and send the reslting certificate back to the client via email or some other means.
In this case, only connections where a password was already agreed on would be protected vs. general unauthenticated browsing.
There was a draft proposal to add PAKE support to TLS 1.3, but it appears to have unfortunately expired [1].
0: https://en.wikipedia.org/wiki/Password-authenticated_key_agr... 1: https://tools.ietf.org/html/draft-barnes-tls-pake-04
https://youtu.be/mx40DSeoxnw?t=1230
TLS 1.3 was in some part an exercise in removing crap people thought might be a good idea in earlier versions, but then either never used or turned out to be a terrible idea but was notionally "optional" so you could say to keep using TLS but just disable that feature. So there is skepticism pre-existing in that room against the idea of just adding more stuff than might be cool unless it's clearly _needed_.
A feature that keeps six people in Kazakhstan (who happen to have manually pre-configured a PAKE) safe but everybody else is still screwed isn't the sort of impact TLS 1.3 was looking for.
Yeah. Fangs vs shells. Microbes vs white cells.
It's just the way this universe works. The struggle is eternal. Probably built into the root parameters of the Big Bang, if you could somehow trace it that far back in time and causality (which you probably can't, I dunno).
An agency is tasked with doing random sample captures of randomly selected target internet connections.
Inventory all the types of traffic being exchanged.
Flag anything that isn't obvious plaintext or already being MiTM'ed for analysis follow up.
Implement new blocking rules or interception implementation for each flow that isn't already being intercepted.
The failure being that the long tail of uncategorized data would be large.
Do you have a good reference for what game state updates look like for every game on the internet? What about custom IoT device protocols? Every type of DRM used for media streaming? Document attachments of spreadsheets or database images containing arbitrary numeric data?
How do you distinguish data like that, which outside of some headers may be indistinguishable from random numbers, from someone using the same format or protocol for encoding arbitrary encrypted data?
In an authoritarian state, you just start blocking and breaking things.
Everything you don't understand, you block. And then you make the user explain it to you and then if it's a use case you care about, you do the work to either decide it doesn't have any danger of carrying traffic you care about or build an intercept scheme for it.
There are also a whole bunch of IP transport protocols other than TCP and UDP, but firewalls have a tendency to block them, so today people just encapsulate everything in TCP or UDP.
There are a lot of TCP and UDP ports too, with their own protocols, but those darn firewalls again, so now everything is increasingly using HTTP[S].
The things that get blocked never go away, they're just made to look like whatever is still allowed. Yes sir, Mr. Firewall, this is Hypertext Transfer Protocol over SSL on TCP port 443 using IPv4, which is approved for intercept.
Except that it's really email and games and file downloads and whatever else, with things added daily by everyone on the internet, and no reference for what all of that plaintext is even expected to look like.
So you say you're going to get a DPI classifier and try to distinguish all these different types of HTTP. Except that whatever you exclude will soon be right back encoded as formats and protocols you allowed, because information theory says you can encode anything into anything.
And it gets harder to distinguish them with every iteration, because what you're really using to distinguish them is their encoding inefficiency -- it's the things that are always the same for a given class of data, even though the relevant part of the message is the things that are different. The end state of all of this is that the real entropy is all that's left and there is nothing there to distinguish with anymore.
I'm well aware of all that you've said.
My point was, they get TLS interception down, and they capture what they want from a target of interest.
When they look closely at your traffic and decide all these cat gifs have too much or too little entropy in the data that forms their pixels, they simply (if they're courteous) say, "Persuade me that you did not know that this app was helping you hide messages back and forth. Persuade me or we shoot you now." And then they shoot.
Fortunately the more typical case isn't kidnapping and execution but only having your connection blocked, which creates a helpful feedback loop that enables continuous improvement in the ability of secure communications to avoid detection. Which benefits everybody, but especially those in violent authoritarian countries that need it all the more.
Rather than death, if we look at the history of oppressive societies, the more likely outcome is a job offer, the kind they won't let you refuse but they'll make it so you don't want to refuse anyway. They find the clever people who are working around the filters and interception and hire them to be the watchers. They get perks like time to spend on a real private connection, etc. Meanwhile they are required to contribute to making the noose ever tighter.
no, he's being hyperbolic to make the point that in an extreme situation, a default-deny approach could facilitate mass suppression of 'undesirable' traffic without creating an insurmountable backlog of traffic for the 'bad actor state' to review in determining what to process further.
Only it doesn't, because as soon as they allow anything, everything else starts to look enough like whatever is still allowed to make it through, because that's the only way to make it through.
Slashing away more things only increases the resources people will put behind making arbitrary traffic look like allowed traffic. It trades not having to review everything for having to fight everyone instead of only the people they want to block.
Then some people win, everyone copies the winners' methods to get through, and you're back to square one only now everything looks even more like everything else than it did before.
But, being "sufficiently clever" isn't all that easy. China has done a good job, but they're a very big country with a lot of resources and a lot of very smart people, and let's be honest, even as good as they are, anyone with a will to get that censored information will get it.
It costs a lot to censor people on the Internet. The goal of people like me is not to stop the most determined, intelligent censorship approaches, but rather to make them as expensive as possible to build and maintain.
My ideal is force governments to either accept the Internet without censorship, or almost completely disconnect from the Internet (and simultaneously deny their nations the competitive advantages that come with it). North Korea is a good model. They basically don't have Internet in North Korea. It's sad, but I can live with that; it's better than allowing an oppressive regime to benefit from the Internet while oppressing their citizens.
For example, in order to scale less expensively, the Great Firewall is architected such that it need not actively be in the middle of the entire flow of traffic and need not actively proxy. Historically, they didn't need it to do so in order to achieve their goals.
Now, however, the advancement of a combination of new technologies is finally closing that gap.
In order to maintain historic blocking capability it becomes necessary in the long run to actively MiTM all the connections.
But that can be made to scale and there are nations who can afford it.
How do we know? Because the job is not significantly harder than serving up all that content. (At worst it's a little more than 2x the work.)
And today most content is served up from a handful of privately owned infrastructures. If a corporation can build it, so too can a lot of nation-states.
The incentives to build this have changed.
You say "authoritarian state", sounds to me like the network at many employers and institutions in the US!
not really, we know exactly what the government response is and it's turning citizen one another, that applied with the gestapo back then and it's happening today with the "social credit system"
why do all the random sampling work if all you need is one "regime believer" among a hundred person or so to maintain full awareness of dissident activities.
I wonder if Google changed its mind about this once Sundar Pichai took over and then gave Project Dragonfly the greenlight.
What the fuck.
Stop thinking about the country with literally less than 1% of world internet users and start thinking of the reputational damage a less than charitable presentation of your collaboration with a totalitarian state against your users would do to the other 99%+ of your market.
Malware forks of open source projects (and closed-source software!) are not a new problem.
In reality, being one BGP trick away from a mere dedicated individual or corporate owning certs for your domain is an actual risk today.
The downside of pushing them to that is that that browser will be unlikely to get regular security updates and will likely hide the interception.
In fact, you're making it worse because you're giving legitimacy to a government that is conducting actions which we shouldn't consider acceptable. If the US government started doing the same thing, I would really hope that browsers would block those certificates too.
But I disagree with the response that says we should do nothing. In fact, corporate root certs should be blocked / ignored by the browser in the exact same way and for the exact same reason. The only exception should be certs issued for a limited number of domains that are only active in a specific developer mode that can be enabled by knowledgeable users.
Sure, technological solutions can't solve this issue 100%. (My employer can also fork a browser.) But acting as if everything is OK when the connection is being MITMed is wrong and browsers shouldn't do it.
Technological solutions can't solve this at all if the entire stack is controlled by the interested party.
In the case of government snooping, you (theoretically) own the end device being used for access. In the case of corporate snooping, you're using corporate owned and managed devices. There is absolutely no technological solution that exists that will prevent another person from building software for (or selling to) corporations who need to snoop on their employees. Considering the selling price of appliances that perform these services (e.g. Bluecoat's range), the cost of a browser is negligible in comparison.
I don't think it's fair to conflate a lack of privacy on corporate owned devices with a lack of privacy on your own personal devices.
In places like Kazakhstan and China it's a harder problem, and HTTPS is necessary but not sufficient to solve it.
HTTPS is that tool. It is a social problem now, it was a technical problem problem just recently.
but atleast we know
And compromising HTTPS in places with a functional judicial system (and human rights) would probably be blocked by an end-less series of law suites.
That's extremely worrying as well and it appears politics so far are unwilling to make it illegal. There needs to be more protest and more competition so consumers can vote with their wallets.
They’re training their entire population to install things that they get in unsolicited emails that purport to be from a legitimate source.
What could go wrong?
Another technical solution would have been to allow security without privacy. If the purpose of the government actions is just to monitor content, you can enable that without disabling security. The HTTP protocol could be modified to transmit checksums signed by a cert, so that a client can verify that content has not been modified, but that content can be (optionally) not encrypted, but still no content-injecting attacks can take place.
But privacy advocates don't like it, so the result is either you have total security + privacy (such as it is), or none at all.
If HN didn't have the lock in the url bar (no https), it would have zero impact on my behavior. I had to look just now to even know if there was one.
If HN still wasn't using https, we'd still be here. Virtually nobody really cares day to day.
Also, it would be great if there were a "red dot" style warning when you manually click "Proceed anyway" while viewing a https page with an invalid certificate (currently, the browser remembers the "Proceed anyway" decision and accepts the invalid cert after the initial acceptance of the warning)
https://bugzilla.mozilla.org/show_bug.cgi?id=1549605
Here is the crux of the issue, many TLS middleware providers install their own root certificate for network monitoring, data loss prevention, security scanning and so on. I personally would like them to stop doing that or at least make it obvious to end users it's happening. However, in order to modify the root store, they must have been authorized to do so by the Administrator, and it's their network or hardware.
If we try to make it obvious to users that this inspection is happening, these providers will switch to using alternative methods, such as using Microsoft Detours - which would be even worse, now you have random vendors patching security critical code in such a way that is not discoverable for end-users. This cannot be prevented, because they must already have Administrator access or they wouldn't have been able to modify the root certificate store in the first place.
In this Kazakhstan scenario, imagine if adding the government certificate put a red dot that said "You are being monitored". If the government didn't like that, they could instead require you to install monitor.exe that had the exact same effect, but didn't show the dot by patching and hooking all the crypto APIs. I find this argument against adding an obvious indicator quite compelling.
I think companies in the US are legally required to provide similar disclosure when monitoring their employees, so I don't see why they'd have a problem with a persistent indicator like that.
It's going to be a lot fewer than the people who'd be able to understand they'd need to do X to keep the internet working.
Not at all. They spin it as providing security:
"Due to frequent cases of theft of personal and credential data, as well as money from bank accounts of Kazakhstan, a security certificate was introduced that will become an effective tool for protecting the country’s information space from hackers, Internet fraudsters and other types of cyber threats.
...
What is a security certificate?
A security certificate is an electronic certificate that allows to protect Internet users from content that is prohibited by the laws of the Republic of Kazakhstan, as well as from malicious and potentially dangerous content. The security certificate is intended to provide subscribers of cellular communication in Kazakhstan with Internet access in the most secure manner."
(source: https://www.kcell.kz/ru/product/3585/658 -- but this text seems to be coming from government, since it's quoted by all providers).
Maybe clicking on the red dot could show a page with company policy.
So what if they could, in theory, work around the indicator by asking users to install some dubious live-patching executable? Firstly, the users wouldn't have to do so - the enforcement mechanism here is ultimately the MITM itself, so as long as the users just installed the certificate they could continue to access sites (they would have to make the certificate available separately, for installation on iOS / Android / ChromeOS etc). Secondly, the security implications of live-patching the executable are mostly irrelevant, because the only people installing this have already lost the security game. Thirdly, there is a benefit in making the bastards work for it - keeping that live-patcher up-to-date and working against a range of target executable versions is going to be bitter work.
Who's to say that this isn't happening in the US as well? The US has invested billions of dollars in dragnet surveillance that is allegedly useless for anything other than metadata in the context of HTTPS.
Is it out of the question to ask whether our secret courts could issue gag orders and claim that national security mandates CA root keys? Such a gag order would only be served to a small group of engineers at large companies, and those engineers would have no right to report on it. We're talking about only a few hundred FISA gag orders, and thousands are served annually. It would make their multibillion dollar infrastructure useful again, wouldn't surprise me if some (unnamed, anonymous) judge bought the argument.
To employees at vulnerable companies, what's your PKI like? Is anyone aware of a company that implements strong multi-party checks on accesses to important private keys? If the NSA wanted your keys, how many employees would need to be served gag orders? Is it on the order of dozens or hundreds?
No one can say it because you just claimed it's all secret and can't be proven.
edit: not to say they are specifically MITM'ing HTTPS widescale.
Assume NSA et. al had access to trusted CA private keys, then they could generate certificates for arbitrary domains which would be trusted by clients. But if they MITM'ed _all_ connections (or even a large portion) surely someone would have noticed, like in the DigiNotar case [0].
But it's even harder (or better) now, with the advent of Certificate Transparency. Since browsers check certificates, periodically, against the CT logs which would fail for forged certificates [1].
However, stealing private keys from companies themselves is a practice that I can imagine happening on a small scale, like the Realtek signing keys for Stuxnet [2]. But doing that on a large scale is not really sustainable.
[0]: https://en.wikipedia.org/wiki/DigiNotar#Issuance_of_fraudule... [1]: https://security.stackexchange.com/questions/190096/how-will... [2]: https://en.wikipedia.org/wiki/Stuxnet#Windows_infection
A "few hundred" gag orders placed on engineers about something deeply outrageous sounds completely implausible as lasting secrecy. Secrets simply can't be kept at that scale.
Even NSA employees themselves would eventually refuse to keep such a program secret, as we saw with Snowden.
https://en.wikipedia.org/wiki/Lavabit
I could of sworn there are instances where root authorities had brush ins with the law, maybe I'm just remembering a theoretical rant I heard somewhere.
This is a HTTPS only issue and fundamentally it's the same problem as control over domains (ease of manipulation through centralisation).
As far as I know, both the apps you mentioned use HTTPS. However, apps have the option of doing what's called Certificate Pinning.
That's when the application ignore OS/User trust settings about certificates, and just allows a list of hardcoded certificates / certificates signed by a hardcoded CA. Akin to how SSH works (kind of...).
If I remember correctly both Telegram and Instagram have pinned their certificates, which would probably block all network communication but not allow for a MITM attack, even if the user installed the KZ root certificate.
Do you think the government will care?
The 1% will either put up with it, stop using the internet, or leave.
One thing will happen though - the economy will not be ruined.
Generally speaking, since the Cold War ended, these sorts of countries don't mind troublemakers leaving. It's better international PR for them to have 'problem people' leave voluntarily, than to repress them.
Instability is the key.
> At the moment, providers started to use the certificate in the capital of Kazakhstan - Nur-Sultan (ex. Astana).
So it may not be nationwide yet.
I'm from capital (Nur-Sultan, former Astana).
I just checked my wife's phone and apparently she got SMS. Funnily enough, her cellular internet now does not work at all. Probably rollout is not going easy.
I noticed this behaviour last February with Kazakhtelecom (telecom.kz) internet provider. When I opened an http website in my browser and started clicking randomly on the parts of the page which are usually not clickable, sometimes such click would open a pop-up window with ads. Those pop-ups did also open sometimes, when I clicked on links of the page. It was unusual, because I used the same websites just a few days before that from Russia and nothing like that happened.
To figure out what's going on I opened the same webpage through proxy and compared it with localy opened one. Shell command for that was something like:
And the only difference was that directly downloaded webpage contained a reference to some suspicious script in a place, where the proxied one had a reference to a google analytics script. I reproduced this behaviour with multiple websites from two different homes, on two different laptops (Linux and Windows). So this is unlikely to be a malware in my router, and I'm pretty sure it's not in my laptop.I'll be back in Kazakhstan in 3-5 days, I'll try to reproduce this once again.
Legality is secondary when you are punching up in a 3rd world country. (I am from India)
https://tools.ietf.org/html/rfc6108
2. Plese stop using the label "Third-world". You are your own "first-world". There's better labels to describe yourself, namely "developing".
> how this is legal even.
The government writes and enforces the laws. They'll never self incriminate.
And their defense claims US has SSN which is equivalent of Aadhaar why anyone can see ludicrous
And still Aadhar requirement is not removed for filing income tax return (which results in massive penalities)
I do wonder if Chrome will go to requiring CAs for this purpose be deployed via something more “enterprise” (e.g. custom extensions on Windows need to deployed via group policy now).
Regardless of where the cert store is, it came with some CA certs "in the box". Pinning applies to these CAs. Any CA's added by the end user (aka person at the keyboard, or enterprise admins, etc) bypass pinning.
For better or worse, bypassing of pinning is required in some enterprise scenarios to inspect traffic leaving the network. e.g. Is someone attaching all our customer data to a email in gmail? To know that, I need to MITM mail.google.com.
Sadly, this mechanism does get abused :(
But how would Chrome know if a root cert from Windows’ cert store was added by the user or not? They would all be located in the ”Trusted Root Certification Authorities” container.
"The" Trusted Root Certification Authorities store isn't a real thing, it's just a view onto a bunch of different stores that are actually separate, including a local machine store and per-user stores plus of course stores added by your membership of a domain or other grouping.
So Chrome gets to distinguish between certificates that Microsoft added and the ones added by Group Policy or whatever else to your system.
Several ISPs (including some big national players, not smaller local/struggling/other ISPs) trialled that sort of thing in the UK in the mid/late 00s but there was a big enough ruckus about it that they stopped.
The really egregious thing about what some of them were doing is that they replaced existing ads so were basically trying to take money of the sites (they were at the same time also trying to get sites to pay or be considered "low priority" traffic so were trying to tripple-dip: get paid by their primary consumer, get paid by the sites, and take the sites' ad money).
It doesn't surprise me that it is actively happening in places there is less choice (so "voting with your feet" is not an option for telling ISPs what you think) or public outcry is less effective (or drowned out by more pressing issues the area might have).
I had a similar experience with my ISP in Canada. Infact, I did a talk on how I worked out what was going on from a technology perspective: https://www.youtube.com/watch?v=_YeaYIPM-QI
If you want to conduct some testing, I'd be more than happy to help.
If I visit https://gmail.com, I expect all traffic to be encrypted because my browser checks that gmail is indeed using encrypted connection. How is this getting intruded upon?
More importantly, suppose I checkin to a hotel in USA as I usually do and use the hotel's wifi. Would they be able to intrude into my connection to https://gmail.com?
Could someone please give me some clarity on this.
The connection is still encrypted the whole purpose of certificates is to verify with WHO you are connected with. In the Kazakhstan case the government by installing a root certificate has the ability to impersonate gmail.
> More importantly, suppose I checkin to a hotel in USA as I usually do and use the hotel's wifi. Would they be able to intrude into my connection to https://gmail.com?
If the site you visit is over https you can be relatively certain that you are indeed establishing an encrypted connection with the domain owner. If it's plain http anyone sniffing in the same wifi can see and mess with your traffic
> This will save privacy of all Internet users in Kazakhstan.
No. This will mean that users would simply switch to chrome, edge, brave, ... , n + 1.
In case all of them block this CA, the government will force people to install an older version or will patch any open source browser so that it works with their certificates.
IMO, this is also wrong from a philosophical point of view. Your browser should just be your browser and not take part in political disputes. It doesn't sit well with me that Firefox has anything to say in the politics of its users.
And finally, encryption doesn't solve violence.
In the United States, for example, it's legal (even expected?) that corporations can install custom CAs into their user's browsers and prevent internet access to any browser without it installed. Is it Mozilla's job to prevent these CAs from being installed on user's workstations? Should Mozilla reject any certificate from Blue Snort, etc.?
Kazakhstan has likewise declared it legal (under their own sovereign legal authority) to prevent web access to its citizens without the required CA installed. Just like it's legal in the US for corporations to "spy" on their employees, it's legal in Kazakhstan for it to spy on its citizens.
Laws of Western countries do not extend into other sovereign nations, regardless of what one thinks of those laws. It's not Mozilla's job to get involved in this case.
> And finally, encryption doesn't solve violence.
Nor abuse of freedom by nation states, unfortunately.
Just because a nation state decides on something doesn't mean that foreign entities can't protest that decision. Firefox and Chrome can add very scary warnings to users about government sabotage if they want to; they can even start including ads for Tor and comparable services if they want to. Blocking the cert would at most be very consumer-unfriendly to people wanting the certificate to be in place. If they disagree with a particular browser vendor, those people can switch browsers or fork an open source one.
Mozilla's job is to provide a safe and open web. The Kazakh government is opposing that. In this case, it's perfectly in line with Mozilla's mission to warn users as best they can against the scary precedent their government is setting.
Of course this only works well if Google, Microsoft and Apple join the effort to warn users. Google is already showing a constant warning on Android when a device is being MitM'd and many of their apps do certificate pinning. Facebook and Twitter do certificate pinning in their apps as well.
I don't see why browsers couldn't take action as well. Just don't show any green locks during a MitM and show periodic notifications about the users' security being compromised. Block the certificate if you have to; as a party people rely on for choosing what certificate authorities to trust, they can't allow themselves to be compromised by governments enforcing laws endangering the safety of the web.
https://bugzilla.mozilla.org/show_bug.cgi?id=1232689
If enough high level sites do this (Google, Cloudflare, Wikipedia etc) it might force the hand of the government since they are the ones effectively breaking the internet.
https://mitm.watch
As for whether designating that browser vendors can't distribute software to Kazakhstan, their government would just fork an open-source one, mod it to pre-include their MiTM cert, and force their citizens to use that.
To continue using internet, you need to install our government-provided fork of Firefox that doesn't blacklist our government-provided root cert.
regards, your Tele2
No doubt the NSA intercepts all kinds of things, but they're not doing it with TLS MITM technology (at least not without further additional hacks).
There will always be a fight over privacy. Giving up to a foreign government is a terrible idea. It would absolutely just let the problem spread and get worse.
I don't think Kazakhstan has the resources to replace outside online services. A move like this should simply result in them shooting themselves in the foot. This needs to be a firm line such that it's simply not practical for them to implement.
I understand that bugs/discussions should weigh both sides. And ultimately, we may need more than HTTPS. That's fine. The point is we don't just roll over and give up.
Point in case: In 2018, Kazakhstan ranked #144 in the Economist Intelligence Unit’s Democracy Index. Countries such as China, Cuba and Belarus had a better ranking. [See https://en.wikipedia.org/wiki/Democracy_Index#Democracy_Inde...]
IMO what’s needed is first and foremost more democracy in Kazakhstan. That’s not something that Firefox can solve.
With that said, perhaps anti-surveillance technology can assist the affected users. Maybe Tor. I’ve heard about some other, similar project but I can’t recall its name right now.
[Edit: These where the anti-censorship applications I was thinking of: https://www.psiphon3.com/ and https://getlantern.org/. Can’t vouch for their security though.]
From the point of view of the Firefox, this should be an extremely simple technical problem. There is CA that is known to be "compromised" in an entirely technical sense, i.e. it is known to allow MITM. So blacklist it, end of discussion. Allow the user to remove it from the blacklist somewhere in browser's settings: it's not for you (Firefox) to decide what the greater good is.
I assume, it would indeed be a problem for Kazakhstan to fixing the service if people are not using the internet, because their browser doesn't work (because it's both an economical and a social disaster, obviously). Or maybe it wouldn't, because Kazakhstan will send troops to every home to replace every browser by Kazakh-fox or whatever. And it may play out to the better in the end, as much as it can lead to massacre.
But (as a 3rd party technological company) don't play mighty and powerful, responsible for the lives of people in Kazakhstan, it's not your fucking business how they live. You see a technological problem (known CA allowing MITM) — you solve it (block the CA!). That's what you promised your users to provide, to fix technological problems, not to fix the political climate in Kazakhstan, USA, China, whatever.
Their government isn't merley "snooping" on it's citizens due to a week chain of trust architecture and a lack of ethical clarity... it's requiring by law that it's citizens be snooped on and censored. In such a regime, a technological arms race is not going to change the legality of subverting their measures, and cannot help the masses without simultaneously jeopardising their safety.