I find the social aspect of this interesting. Us "smart tech people" have been pushing https everywhere for a few years now as a way of protecting internet privacy "for the masses". And now the government found a very simple non-technical workaround. Send a message to everyone requiring a government root CA with an easy install, or their internet won't work. Now "us techies" have to find a new technical solution to a…
Except I look at the linked mailing list and you already get "us techies" arguing "uh yeah but uhm this isn't so different from the corporate CA intercept thing right so let's not blacklist it uhm". What the fuck.
MITM on HTTPS traffic in Kazakhstan
221–230 of 471 posts
Re: MITM on HTTPS traffic in Kazakhstan
#222Earlier quoted context omitted.
That's exactly what will happen if they all-out blacklist. The best near-term option may be a compromise: a special indicator in the browser UI that the connection has been set up in such a way that some organization may be monitoring.
for all we know NSA may already be doing that all the time, and they're only the worst of the good guys.
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).
Re: MITM on HTTPS traffic in Kazakhstan
#223I have custom root certs for internal dev sites for my company. That's fine, but I'd like to add the root with a caveat that I control saying "I trust this root for *.mycompany.com,mycompany.org", but that I know means they wouldn't be able to proxy "mybank.com". I don't think Firefox or Chrome can do that can it?
There is a Name Constraints extension in X.509[1] that does exactly that, but to my knowledge no browser implements it. [1] https://tools.ietf.org/html/rfc5280#section-4.2.1.10
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...
Re: MITM on HTTPS traffic in Kazakhstan
#224This is bad because we don't like it when a foreign government infringes on foreign citizens' rights, but it may also be good (in a limited sense) because it might bring a whole lot more public scrutiny (from all countries and their citizens) towards the issue...
To the extent that Kazakhstan succeeds with this, it will only make other governments jealous of the capability and want it for themselves.
Re: MITM on HTTPS traffic in Kazakhstan
#225Earlier quoted context omitted.
Yep - without HTTPS everywhere, governments would have been silently able to snoop on Internet traffic without anyone knowing.
Sarcasm? Not sure. But all a government has to do is embed within the endpoint, post-decryption. "Or else."
That’s a pretty high bar to clear though.
Re: MITM on HTTPS traffic in Kazakhstan
#226Earlier quoted context omitted.
What root cert would they us for that?
The government of my country has at least one certificate that's trusted by Mozilla (and I guess Chrome and Windows too) by default.
Re: MITM on HTTPS traffic in Kazakhstan
#227Earlier quoted context omitted.
Yep - without HTTPS everywhere, governments would have been silently able to snoop on Internet traffic without anyone knowing.
Sarcasm? Not sure. But all a government has to do is embed within the endpoint, post-decryption. "Or else."
Re: MITM on HTTPS traffic in Kazakhstan
#228I have custom root certs for internal dev sites for my company. That's fine, but I'd like to add the root with a caveat that I control saying "I trust this root for *.mycompany.com,mycompany.org", but that I know means they wouldn't be able to proxy "mybank.com". I don't think Firefox or Chrome can do that can it?
I'd like that as well, for exactly the same purpose. 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 igno…
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.
Re: MITM on HTTPS traffic in Kazakhstan
#229Earlier quoted context omitted.
> Flag anything that isn't obvious plaintext or already being MiTM'ed for analysis follow up. The failure being that the long tail of uncategorized data would be large . Do you have a good reference for what game state updates look like for every game on the internet? What about custom IoT device protocols? Every type of DRM used for media streaming? Document attachments of spreadsheets or database images containing…
They don't need to. In an authoritarian state, you just start blocking and breaking things. Everything you don't understand, you block. And then you make the user explain it to you and then if it's a use case you care about, you do the work to either decide it doesn't have any danger of carrying traffic you care about or build an intercept scheme for it.
There are also a whole bunch of IP transport protocols other than TCP and UDP, but firewalls have a tendency to block them, so today people just encapsulate everything in TCP or UDP.
There are a lot of TCP and UDP ports too, with their own protocols, but those darn firewalls again, so now everything is increasingly using HTTP[S].
The things that get blocked never go away, they're just made to look like whatever is still allowed. Yes sir, Mr. Firewall, this is Hypertext Transfer Protocol over SSL on TCP port 443 using IPv4, which is approved for intercept.
Except that it's really email and games and file downloads and whatever else, with things added daily by everyone on the internet, and no reference for what all of that plaintext is even expected to look like.
So you say you're going to get a DPI classifier and try to distinguish all these different types of HTTP. Except that whatever you exclude will soon be right back encoded as formats and protocols you allowed, because information theory says you can encode anything into anything.
And it gets harder to distinguish them with every iteration, because what you're really using to distinguish them is their encoding inefficiency -- it's the things that are always the same for a given class of data, even though the relevant part of the message is the things that are different. The end state of all of this is that the real entropy is all that's left and there is nothing there to distinguish with anymore.
Re: MITM on HTTPS traffic in Kazakhstan
#230Earlier 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?
Chrome, etc., require that certificates which descend from publicly trusted roots have their certificates published in certificate transparency logs. Someone would quickly notice bogus certs being issued and the associated root would get blacklisted.