Kazakhstan government is intercepting HTTPS traffic in its capital (again)(zdnet.com)
zdnet.com
Kazakhstan government is intercepting HTTPS traffic in its capital (again)
https://www.zdnet.com/article/kazakhstan-government-is-intercepting-https-traffic-in-its-capital/
71 comments
There's a bug open on BugZilla to get this new CA added to OneCRL: https://bugzilla.mozilla.org/show_bug.cgi?id=1680927
I've tried finding my way through that Atlas Ripe website but it's very confusing. I don't know how others are able to pinpoint that problem so well.
https://atlas.ripe.net/frames/measurements/28334941/#!probes is showing you that, for a v4 connection to twitter.com, probe 6745 is getting back a TLS cert which does not match the cert provided to the majority of other probes.
If you expand the row you can see the nation state MitM: notice the O=ISCA, C=KZ.
If you expand the row you can see the nation state MitM: notice the O=ISCA, C=KZ.
So what’s the point? If you don’t trust the certificate you won’t be able to browse the internet at all.
> So what’s the point? If you don’t trust the certificate you won’t be able to browse the internet at all.
If all the major browser vendors do this it makes Kazakhstan's position quite difficult.
If all the major browser vendors do this it makes Kazakhstan's position quite difficult.
Unless they decide to cat-and-mouse: issue a new one.
Every time they issue a new certificate, they need to get every single user to install it, whereas it should only take a moment for the browser vendors to block it. I would think it's pretty clear who has the upper hand there.
They would be better off releasing some fork of Chromium—which is, unfortunately, also a thing they can presumably do...
They would be better off releasing some fork of Chromium—which is, unfortunately, also a thing they can presumably do...
The browser vendors could stop trusting O=ISCA, C=KZ entirely.
The point is that if browsers block the cert it will make the MITM impossible without them releasing thieir own browser. It will be much more clear for normal uaers that the custom browser can intercept internet traffic than that "security certificate". Also good luck getting that browser into the AppStore and PlayStore or making users install the apk.
I think it's either consciously let users to browse the Web over HTTPS and see green locks everywhere while effectively being MITM’d (undermining the point of encrypted connection), or ban each compromised certificate (making the Web difficult or impossible to access for folks in this situation).
The remaining alternative is not defaulting to HTTPS for cases like non-sensitive static sites, which would be an unpopular proposition with some objective downsides.
The remaining alternative is not defaulting to HTTPS for cases like non-sensitive static sites, which would be an unpopular proposition with some objective downsides.
So this certificate will be added to "not trusted" of all the certificate storages (Windows, Firefox, Chrome, Java, and all others) ... riiight?
I expect it to be added to Chrome and Firefox blacklists. Not sure about others. I don't think that Java even have a concept of CA blacklist.
Translation:
"From December 6th 2020 there will be a study conducted in Nur-Sultan called "Cybersecurity Nur-Sultan 2020".
We ask you to install a certificate of safety on all your devices in order to retain access to some foreign internet resources.
Please, follow the link: [link]"
"From December 6th 2020 there will be a study conducted in Nur-Sultan called "Cybersecurity Nur-Sultan 2020".
We ask you to install a certificate of safety on all your devices in order to retain access to some foreign internet resources.
Please, follow the link: [link]"
> certificate of safety
Gotta love government doublespeak...
Gotta love government doublespeak...
It's simply incorrect translation; the correct one is security certificate (безопасность means either security or safety in Russian, often leading to confusion). The rest is correct.
You're correct. The translation should indeed be "security certificate". Would edit it if I still could.
[deleted]
So... they resort to intercepting traffic rather than outright blocking them. Interesting. That would mean they want people to speak and they can take them out? In India administered Kashmir, they just banned the entire intenet for months, then whitelisted websites one by one. Prevention is better than cure? Fuck these governenments.
I think that they want to block specific URLs without blocking entire domains. For example block specific youtube video without blocking entire youtube.
Of course technically they can spy as well, so one should assume so.
Of course technically they can spy as well, so one should assume so.
India already blocks specific YouTube videos in geographical India, they don't want dissent. For that they just approach YouTube or twitter or whatever because these companies have financial incentives aka ads to earn in India and non compliance would mean no business. Big woop.
I was routed through a bunch of proxies at ISP level last year because of the internet gag by India and I did not feel safe. Not that I didnt do shit what I wanted to but for the end user, https://theintercept.com/2020/12/06/kashmir-social-media-pol...
This just came up yesterday. Now, I have said this multiple tines before, they dont have "sophisticated surveillance techniques" as alluded to by the article here but a simple handle search in twitter, which links to FB, which links to phone, address, work, parents and next thing you know police are knocking on the door.
Its just really scummy of the government to assume they can kill dissent or that these scare tactics would work. They don't.
I was routed through a bunch of proxies at ISP level last year because of the internet gag by India and I did not feel safe. Not that I didnt do shit what I wanted to but for the end user, https://theintercept.com/2020/12/06/kashmir-social-media-pol...
This just came up yesterday. Now, I have said this multiple tines before, they dont have "sophisticated surveillance techniques" as alluded to by the article here but a simple handle search in twitter, which links to FB, which links to phone, address, work, parents and next thing you know police are knocking on the door.
Its just really scummy of the government to assume they can kill dissent or that these scare tactics would work. They don't.
I live in Kazakhstan and I can confirm that I'm observing this behavior on Google websites (they don't MitM all websites and I think they don't MitM all connections, just some percentage). Simple IPsec VPN works fine.
I wonder which Western company sold them the products to do so.
To be fair, this one could easily have been the PRC, they have some, uh, domain expertise.
Easy to hate on PRC, but majority of such acts are conducted by CIA supported or Israeli companies.
While that could be the case, the majority of surveillance infrastructure is sold by Western companies, Israel in particular being a terrible actor on this space.
This is not cutting edge tech so you can dyi this pretty easily
Uh Huawei?
If at first you don't succeed, tou try again, again and again... until a significant percentage of your less technically savvy populace is interceptable.
How would it work if you had a VPN and a private certificate installed on your browser?
1. Traffic encrypted in browser using SSL
2. Traffic routed to VPN server
3. Traffic routed to target web server over public internet*
4. Back to VPN server
5. Back to browser
*I assume at this point the Kazakh government can intercept the traffic and decrypted the HTTPS traffic, but that would itself be garbage because it's been encrypted by the VPN. Is this correct?
1. Traffic encrypted in browser using SSL
2. Traffic routed to VPN server
3. Traffic routed to target web server over public internet*
4. Back to VPN server
5. Back to browser
*I assume at this point the Kazakh government can intercept the traffic and decrypted the HTTPS traffic, but that would itself be garbage because it's been encrypted by the VPN. Is this correct?
If the VPN endpoint is in KZ, then yes. Otherwise, no. However, if you were to be a person of interest, it would be possible to spoof the page of your vpn provider and provide you with fake vpn.
Eventually the opposition gets weary, and you can sneak it in
Cybersecurity training exercise with great success, ah very nice!
Borat reference?
The goverment created a commercial as well https://www.youtube.com/watch?v=eRGXq4t9wY4
I keep trying to imagine a way that a website could inform a user "only these certificates are valid for me", but with a trusted MITM, it just doesn't seem like it's possible.
Whatever content or data the website included, the MITM can just alter it accordingly. Short of a browser knowing what Certificates are allowed for what websites (and the trusted MITM not modifying THAT content) there just isn't a simple way to know that your connection is being monitored or modified.
Short of quantum encryption, is there any simple way to detect such an attack once the user trusts the MITM's CA?
Whatever content or data the website included, the MITM can just alter it accordingly. Short of a browser knowing what Certificates are allowed for what websites (and the trusted MITM not modifying THAT content) there just isn't a simple way to know that your connection is being monitored or modified.
Short of quantum encryption, is there any simple way to detect such an attack once the user trusts the MITM's CA?
> it just doesn't seem like it's possible
Mobile apps can do this with certificate pinning. Web apps used to be able to do this with HTTP Public Key Pinning (HPKP) [1], but it was deprecated because it was too much of a footgun. Instead you can monitor for certificates for your domain that aren't expected via Certificate Transparency logs.
[1]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Public_Key...
Mobile apps can do this with certificate pinning. Web apps used to be able to do this with HTTP Public Key Pinning (HPKP) [1], but it was deprecated because it was too much of a footgun. Instead you can monitor for certificates for your domain that aren't expected via Certificate Transparency logs.
[1]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Public_Key...
A "trusted MITM" is just that, a trusted MITM...You kind of accept the compromises that come with such a setup.
A CA that can issue a certificate to a third-party without the consent of the domain owner is not a trusted CA by definition.
In other words the issue in Kazakhstan should probably not be viewed as a technical issue...authoritarian governments will always get their way if the only recourse against them is a technical solution. In the case of Kazakhstan, they are forcing their citizens to accept the compromised CA, that is not a technical problem to solve.
A CA that can issue a certificate to a third-party without the consent of the domain owner is not a trusted CA by definition.
In other words the issue in Kazakhstan should probably not be viewed as a technical issue...authoritarian governments will always get their way if the only recourse against them is a technical solution. In the case of Kazakhstan, they are forcing their citizens to accept the compromised CA, that is not a technical problem to solve.
It is possible using a "Certification Authority Authorization" (CAA) DNS record to specify which CA is allowed to sign certs for your domain and using DNSSEC you get a separate channel of trust.
However CAA (and DNSSEC) is rarely used, so most likely the MITM-part will just block lookups.
Also, CAA is explicitly specified to only constrain certificate issuance, not certificate acceptance. Only the issuing CA is supposed to check it, not the browser. RFC 8659:
A set of CAA records describes only current grants of authority to
issue certificates for the corresponding DNS domain name. Since
certificates are valid for a period of time, it is possible that a
certificate that is not conformant with the CAA records currently
published was conformant with the CAA records published at the time
that the certificate was issued. Relying Parties MUST NOT use CAA
records as part of certificate validation.CAA is not the record for this. As @schoen already replied, it is only used by CA's to check if they are allowed to issue a certificate to a domain.
But with DANE TLSA Resource Records you can pin a public key to a website. Alas the implementation of TLSA-RR checking in browsers is dependent on extensions at this time. I wish it was native in browsers with a big red sign when violated. When done in combination with DNSSEC it's very hard to fake certificates. Or more precisely asymmetric cryptography key pairs used by servers. Certificates for TLS would not be needed anymore if TLSA-RR's were standard practice. A company might still use a certificate to attest it's identity beyond internet domain ownership.
Edit: This is for TLSA 3 1 1 and 3 1 2 records. That's what I have experience with. Just read on Wikipedia a lot more is possible with TLSA-RR's including certificate and CA pinning. https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na...
But with DANE TLSA Resource Records you can pin a public key to a website. Alas the implementation of TLSA-RR checking in browsers is dependent on extensions at this time. I wish it was native in browsers with a big red sign when violated. When done in combination with DNSSEC it's very hard to fake certificates. Or more precisely asymmetric cryptography key pairs used by servers. Certificates for TLS would not be needed anymore if TLSA-RR's were standard practice. A company might still use a certificate to attest it's identity beyond internet domain ownership.
Edit: This is for TLSA 3 1 1 and 3 1 2 records. That's what I have experience with. Just read on Wikipedia a lot more is possible with TLSA-RR's including certificate and CA pinning. https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na...
It's unlikely ever to be native in browsers. Native DANE code was proposed in Firefox and actually landed in Chrome, which later removed it, because it (a) didn't work reliably on the actual Internet, and (b) in fallback mode, amounts to adding just one more CA to the pile of CAs Chrome already has to trust.
When a CA can be shown to have misissued a certificate, Google can (and has, as it did in the Symantec case) distrust it, nuking the CA from orbit. It has no such powers with a CA baked into the DNS; Google can't distrust .COM. People should be careful what they wish for.
But not too careful in this case; DNSSEC is moribund, and unlikely to be revived.
When a CA can be shown to have misissued a certificate, Google can (and has, as it did in the Symantec case) distrust it, nuking the CA from orbit. It has no such powers with a CA baked into the DNS; Google can't distrust .COM. People should be careful what they wish for.
But not too careful in this case; DNSSEC is moribund, and unlikely to be revived.
> Short of quantum encryption, is there any simple way to detect such an attack once the user trusts the MITM's CA?
If the website uses client certificate authentication, any MITM attempt will fail authentication unless either the website trusts the MITM's CA, or the MITM somehow has access to the private key of the client certificate; the browser trusting the MITM's CA is not enough. Unfortunately, client certificate authentication in websites is rare (unlike for instance ssh, where public key authentication of both the server and the client is common).
Another way to detect MITM attempts would be if TLS channel binding were used for authentication, since any MITM would be using separate connections for the server and the client and therefore the authentication (bound to the TLS connection) would fail. I don't know if newer authentication protocols like WebAuthn support it, and if they do, how common is the support for it in browsers.
If the website uses client certificate authentication, any MITM attempt will fail authentication unless either the website trusts the MITM's CA, or the MITM somehow has access to the private key of the client certificate; the browser trusting the MITM's CA is not enough. Unfortunately, client certificate authentication in websites is rare (unlike for instance ssh, where public key authentication of both the server and the client is common).
Another way to detect MITM attempts would be if TLS channel binding were used for authentication, since any MITM would be using separate connections for the server and the client and therefore the authentication (bound to the TLS connection) would fail. I don't know if newer authentication protocols like WebAuthn support it, and if they do, how common is the support for it in browsers.
>know that your connection is being monitored or modified
Probably some low hanging fruit here are 1. Inspect the CA used by a few different websites 2. Try visiting the website from different countries (vpns and proxies) to see if the same cert is used
Theoretically a MITM could tamper with the software download but I think for most cases this would be reasonable
Probably some low hanging fruit here are 1. Inspect the CA used by a few different websites 2. Try visiting the website from different countries (vpns and proxies) to see if the same cert is used
Theoretically a MITM could tamper with the software download but I think for most cases this would be reasonable
Surely people own devices (TVs etc) that don’t support updating the list of CAs?
Yes but people probably access Facebook/Twitter/other potentially politically sensitive content more with their phone than through their TV, and their phone would have probably been handed to them by their operator with the updated CA already installed.
> and their phone would have probably been handed to them by their operator with the updated CA already installed.
Outside of the US, almost no one buys their phones from their carriers. You usually buy an unlocked phone from an electronics store and it's sealed in the box. You're the first person to ever turn it on.
Outside of the US, almost no one buys their phones from their carriers. You usually buy an unlocked phone from an electronics store and it's sealed in the box. You're the first person to ever turn it on.
Plus hey are aware of this type of thing now and more politically minded people will be taking the precautions they are able to.
When visiting a neighboring country the local market's Wifi forced an intermediate cert which my US Blackberry immediately flagged. I learned to assume every network and local device was compromised.
What year was this? I can't imagine Android BlackBerrys doing this.
One of the purported benefits of DoH, and especially of not using one's ISP's DNS servers, was privacy from authoritative governments.
Some critics of DoH, and especially centralized DoH, said that it would not help; see "DoH for oppressive regimes":
* https://blog.powerdns.com/2019/09/25/centralised-doh-is-bad-...
See also Paul Vixie:
* https://blog.apnic.net/2019/11/04/dns-wars/
Personally I prefer DoT: it allows me to control resolution on my network, but if you want to allow 953 and use a third party DNS service because of your ISP, you still can.
Some critics of DoH, and especially centralized DoH, said that it would not help; see "DoH for oppressive regimes":
* https://blog.powerdns.com/2019/09/25/centralised-doh-is-bad-...
See also Paul Vixie:
* https://blog.apnic.net/2019/11/04/dns-wars/
Personally I prefer DoT: it allows me to control resolution on my network, but if you want to allow 953 and use a third party DNS service because of your ISP, you still can.
[deleted]
How a device (Android, iPhone, Mac and others) do initialize at first boot/system recovery if this CA is not installed?
Don't editorialise titles.
https://news.ycombinator.com/newsguidelines.html
DPI Vendors:
Belarus = Sandvine (USA) Kazakhstan = Allot (Israel)
Belarus = Sandvine (USA) Kazakhstan = Allot (Israel)
To protect your users
Add your domain name to https://hstspreload.org
Get A+ from https://www.ssllabs.com/ssltest/
Use DNSSEC for your domain name https://dnssec-name-and-shame.com
Enable Encrypted SNI in your web server https://www.cloudflare.com/ssl/encrypted-sni/
Add your domain name to https://hstspreload.org
Get A+ from https://www.ssllabs.com/ssltest/
Use DNSSEC for your domain name https://dnssec-name-and-shame.com
Enable Encrypted SNI in your web server https://www.cloudflare.com/ssl/encrypted-sni/
None of those steps will protect against a government requiring you to install a certificate
I've talked with people at times that hierarchical CA is a bad idea and that peer-trust schemes are better for several reasons.
They looked at me like I've just dropped from the Moon. I find these recent developments as evidence that I'm not.
None of that would help against this though, right? HPKP would if the site was visited before, but that is deprecated and removed from major browsers. Expect-CT might help but IIRC that is still a soft-fail.
Why is this news when:
'US government is intercepting worldwide internet traffic through Silicon Valley and NSA cooperation (again, everyday)'
'US government is intercepting worldwide internet traffic through Silicon Valley and NSA cooperation (again, everyday)'
Because when the US does it is Freedom Interception, or Freeception if you will. And when its corporations do it, they are simply projecting Freedom into uncivilized* parts of the world.
* uncivilized meaning both 'shithole' countries and those otherwise not a part of the USA
* uncivilized meaning both 'shithole' countries and those otherwise not a part of the USA
Because NSA collection does not involve breaking encryption on all connections for now. (No, the "SSL removed and added here" slide is not the same thing)
[deleted]
https://blog.mozilla.org/security/2019/08/21/protecting-our-...
---
Nevermind, I went and checked. It's a new CA.
The certificate is here: https://isca.gov.kz/
The first button downloads the cert.
It's a newly issued one, valid from Feb 2020 to 2040.
I've put it on Pastebin as well: https://pastebin.com/ERqCMCBf
---
Common Name: Information Security Certification Authority CA
Organization: ISCA
Country: KZ
Valid From: February 27, 2020
Valid To: February 27, 2040
Issuer: Information Security Certification Authority CA,ISCA
Serial Number: 287dce0ce3c6f7aaa33ff965e76ea98c824a59db