MITM on HTTPS traffic in Kazakhstan • Hacker News Board

Re: MITM on HTTPS traffic in Kazakhstan

#311

Post by oneplane » Thu, Jul 18, 2019, 11:56 PM UTC

jasonh3 wrote: post #252

cesarb wrote: post #150

Earlier quoted context omitted.

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 certif…

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 th…

I suppose that'd take something pike obfuscated paper mail password exchange before digital. Or rtty. Or 56k international calls for key setup?

Re: MITM on HTTPS traffic in Kazakhstan

#312

Post by effie » Fri, Jul 19, 2019, 12:12 AM UTC

tomxor wrote: post #181

JaRail wrote: post #142

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…

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

History contradicts you. There are examples from communist block where technological solutions that bypassed government restrictions helped to spread banned information.

Re: MITM on HTTPS traffic in Kazakhstan

#313

Post by cascom » Fri, Jul 19, 2019, 12:13 AM UTC

mholt wrote: post #15

Would someone with network access in Kazakhstan check if Caddy's MITM detector catches this please? https://caddyserver.com/docs/mitm-detection - or https://mitm.watch (Cloudflare's unofficial deployment of the same tech). 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: Reported…

Does this do something substantially different than:

https://www.grc.com/fingerprints.htm

Re: MITM on HTTPS traffic in Kazakhstan

#314

Post by olliej » Fri, Jul 19, 2019, 12:20 AM UTC

cpach wrote: post #220

syn0byte wrote: post #204

Earlier quoted context omitted.

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 m…

How would they sneak the private keys from e.g. Digicert/Geotrust/ISRG?

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)

Re: MITM on HTTPS traffic in Kazakhstan

#315

Post by effie » Fri, Jul 19, 2019, 12:24 AM UTC

hombre_fatal wrote: post #151

saagarjha wrote: post #81

Earlier quoted context omitted.

The goal is to make it evident when there isn't one.

Well, Chrome does make it evident. That wasn't my point. My point, and the point of the comment above, is that it doesn't matter to almost anyone. If HN still wasn't using https, we'd still be here. Virtually nobody really cares day to day.

So? It matters to those who care about their communication not being spied on / silently modified by third parties. That set isn't empty.

Re: MITM on HTTPS traffic in Kazakhstan

#316

Post by ElijahLynn » Fri, Jul 19, 2019, 12:25 AM UTC

This is being discussed here as well https://groups.google.com/forum/#!msg/mozilla.dev.security.p...

I like the idea of a permanent, non-removable banner saying "Kazakhstan is spying on you, learn more here .".

Re: MITM on HTTPS traffic in Kazakhstan

#317

Post by tialaramex » Fri, Jul 19, 2019, 12:27 AM UTC

z3t4 wrote: post #186

ignoramous wrote: post #122

Earlier quoted context omitted.

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

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.

Re: MITM on HTTPS traffic in Kazakhstan

#318

Post by effie » Fri, Jul 19, 2019, 12:34 AM UTC

lone_haxx0r wrote: post #114

> 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 wo…

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.

Re: MITM on HTTPS traffic in Kazakhstan

#319

Post by jupp0r » Fri, Jul 19, 2019, 12:40 AM UTC

So it took them only two weeks to take advantage of Firefox's new policy to automatically "fix"[1] man in the middle attacks through enterprise/antivirus CAs. As expected, this "convenience" will make us all less safe :(.

[1] https://blog.mozilla.org/security/2019/07/01/fixing-antiviru...

Re: MITM on HTTPS traffic in Kazakhstan

#320

Post by userbinator » Fri, Jul 19, 2019, 12:44 AM UTC

I think the most important thing to keep in mind as you read through this issue and the comments is "be careful what you wish for". No doubt cases like this will be taken as arguments for making it even harder to install your own root certs than it already is, meaning that those who run MITM proxies on their own networks (e.g. to filter out ads even in otherwise unconfigurable browsers and such) get affected negatively, and it takes away from personal freedom. Also, don't forget that the pro-DRM and adtech crowd would love for nothing other than you to get exactly what they serve, whether you want it or not.

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.