MITM on HTTPS traffic in Kazakhstan
71–80 of 471 posts
Re: MITM on HTTPS traffic in Kazakhstan
#72Earlier quoted context omitted.
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…
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?
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.)
Re: MITM on HTTPS traffic in Kazakhstan
#73Earlier quoted context omitted.
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.
What about just for the Alexa 100?
Re: MITM on HTTPS traffic in Kazakhstan
#74Earlier quoted context omitted.
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…
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?
Site owners can monitor these logs for rogue certs issued for their own domains.
Re: MITM on HTTPS traffic in Kazakhstan
#75Earlier quoted context omitted.
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". Seems a very solvable problem.
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.
Re: MITM on HTTPS traffic in Kazakhstan
#76The best solution would be to blacklist rouge SSL certs.
Re: MITM on HTTPS traffic in Kazakhstan
#77Warning: 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…
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.
Re: MITM on HTTPS traffic in Kazakhstan
#78Does such a certificate compromise non-browser traffic as well? Like SSH tunnels, mobile apps, Telegram etc.
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).
Re: MITM on HTTPS traffic in Kazakhstan
#79Earlier quoted context omitted.
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.
Any way to avoid or bypass name or path constraints would be considered a huge and monumental vulnerability today.
Re: MITM on HTTPS traffic in Kazakhstan
#80Question to local readers: Is Kazakhstan also blocking VPNs and SSH?
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.