Comment by coldpie | Hacker News Reader

Comment by coldpie | Hacker News Reader

Parent Full thread

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.

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.

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?

> 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.)

The thing with certificate is that they not only add security, but they also act as a signature.

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.

Trusted certificate authorities log issued certificates to verified certificate transparency logs.

Site owners can monitor these logs for rogue certs issued for their own domains.

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 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?

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).

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...

Reply on news.ycombinator.com