> Kcell JSC informs its customers of the need to install Security Certificate on personal devices capable of connecting to the Internet
> Due to the increase of identity and personal data theft, including stealing money from bank accounts, introduced a security certificate as an effective tool to protect the country’s information space from hackers, online fraudsters and other types of cyber threats.
And some FAQs are hilarious (as in hilariously devious):
> What happens if I do not install the Security Certificate?
You may have problems accessing the Internet.
> Will installation of the Security Certificate affect the protection of my personal data?
The security certificate has no access to your personal data.
Yeah, true that, literally, but you forgot to mention something there...
 https://www.kcell.kz/en/product/3585/658, might have to switch to EN in top right corner
I don't think Firefox or Chrome can do that can it?
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.
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).
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.
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...
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.
You only need a root if you're issuing other keys.
Modern browsers do respect name constraints of intermediate issuing certificates.
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.
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.
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.
To continue using internet, you need to install our government-provided fork of Firefox that doesn't blacklist our government-provided root cert.
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).
> 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.
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.
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).
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.
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.
Maybe clicking on the red dot could show a page with company policy.
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)
The problem Kazakhstan had was that there was no existing CA they could already force to issue certs. So they had to make a new one. It would be foolish to assume that none of the many trust anchors your browser already trusts haven't already been compelled by your local government to do exactly this.
Also, DANE and DNSSEC solves this problem.
DANE is, unfortunately, not viable to implement in browsers right now for a variety of reasons: https://www.imperialviolet.org/2015/01/17/notdane.html
CT makes such an attack obvious, but the harm can't be undone.
A case study: root certificates for the GPKI, the South Korean governmental CA primarily used for public institutions, are not included in most browsers except for maybe IE  but frequently trusted due to (still) prevalent uses of ActiveX controls. It is of course subject to CA/B Forum baseline requirements  and publishes CT records, so you may guess their "accidentally" invalid wildcard certificates  are quickly spotted... Heck no! It was only noticed 3 years later . No one knows what happened in this period.
 For example, Firefox doesn't include it: https://bugzilla.mozilla.org/show_bug.cgi?id=1377389
 For example, https://crt.sh/?id=6990343 contains a public suffix `.co.kr` (comparable to `.com`). Note that the BR contains very strong requirements for such public suffixes, which the GPKI didn't follow.
The increasing politicisation of Mozilla is also a concern --- it seems unwise for it to fight a government, or turn their core product into a platform for doing so. It's sad to see "privacy" brought up as an argument, and that seems to be Mozilla's main one these days; I think it's perfectly fine for people to desire privacy (and my MITM proxy will help with that, by stripping out trackers and such), and for Mozilla to offer services that do (they could work on their own VPNs and "firewall busters", for example), but the attitude of knowing better than the users or forcing them to trust or not trust certain entities is wrong.
Or replace it with a compromised version.
> 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.
Wouldn't be the first scandalous thing in the former Soviet Union that a Swedish phone network was involved in: https://en.wikipedia.org/wiki/Telecom_corruption_scandal
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.
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.
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.
Guess it wasn't canceled after all.
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
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.
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.
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.)
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.
Site owners can monitor these logs for rogue certs issued for their own domains.
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?
This will immediately block their services in the country and will raise awareness at scale.
I understand that by making people install the government cert, any website with a cert signed by that government cert will happily speak TLS.
But, how can they read data transmitted between websites they don't control? When the client asks for Facebook's cert, wouldn't the government have to sneak in and show a fake cert signed by them instead? How does that work?
The regime has just painted a huge "X" on their backs.
If you hack the governments servers and steal the certificate private key you can pretty much rob the entire country - all bank transactions, pins, passwords etc. will be in the clear for you, ripe for the picking.
This is yet another reason why backdoors are so dangerous, not just for the privacy of all citizens.
If someone manages to redirect traffic by e.g DNS spoof to some server which presents a self-signed certificate for e.g Facebook.com, the government-MITM would just sign that as being Facebook.com.
$ wrk -t 50 -c 500 -d 5m --latency --timeout 3s http://qca.kz/
It would probably be illegal and if the regime finds out they'll put you into jail etc.
It's not even this blatant in most cases. About 6 countries have issued certificates for Google, India being one of them. And they all made use of the fact that they were part of the trusted root certificates on our systems.
I like the idea of a permanent, non-removable banner saying "Kazakhstan is spying on you, learn more here <link to more info>.".
Edit: RFC 6844 very unambigously states that it can be used for additional verification:
CAA records MAY be used by Certificate Evaluators as a possible indicator of a security policy violation. Such use SHOULD take account of the possibility that published CAA records changed between the time a certificate was issued and the time at which the certificate was observed by the Certificate Evaluator.
To the extent that Kazakhstan succeeds with this, it will only make other governments jealous of the capability and want it for themselves.
"I knew the techies could do it! They told me they couldn't but I knew they were lies. See! even Kazakhstan can do it, so why can't I also break HTTPS encryption?"
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.
I think ultimately the solution is going to be p2p content-centric approaches.
Do you think the government will care?
Instability is the key.
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.
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.
Previously, a government could monitor what site a user is visiting just by looking at the TLS session startup. Even if it is hosted on a cloud provider and 100 different sites are hosted from the same IP, they could look at the TLS-SNI data in the plain text to choose to interrupt and block the connection.
A fallback would be to manipulate DNS queries and force all DNS queries to be directed to official DNS resolvers. But DoH makes that far harder to control.
This is a bluff being called. Tech said "If we make it so that they have to spend all this money and build a massive scale intercept that actively participates in each TLS session, they won't buy into the cost."
Costs keep going down for this sort of thing. Now there are large organizations and governments willing to work on this stuff.
DoH is easy to block. They can look at SNI and cut DoH connections.
Being able to access all the content is far more valuable than hostnames.
And then massive CDNs will start to support it.
Some of them might even enable it, with encrypted SNI, on _every single listener on all of their IPs_.
DoH was designed to evolve into something nearly unblock able. Unless you active intercept 100%.
Which some people believed no one would pay up for or that it would be unscalable. This stuff only gets cheaper and easier.
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?
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.
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 .
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 .
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 . But doing that on a large scale is not really sustainable.
edit: not to say they are specifically MITM'ing HTTPS widescale.
No one can say it because you just claimed it's all secret and can't be proven.
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.