Live data from Hacker News

MITM on HTTPS traffic in Kazakhstan

bugzilla.mozilla.org

221–230 of 471 posts

Re: MITM on HTTPS traffic in Kazakhstan

#221
post #21

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.

Are you willing to intentionally break your software (which is currently working) for an entire country?

Re: MITM on HTTPS traffic in Kazakhstan

#222
post #216

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

Modern browsers require that leaf certificates which are issued in a chain which descends from a built in publicly trusted root include "certificate transparency" information. This means that the certificate has been published in numerous public logs and so would be discovered.

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

#223

I 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

> but to my knowledge no browser implements it

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

#224

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

This will _not_ be good.

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

#225
post #88
post #58

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

”all a government has to do is embed within the endpoint”

That’s a pretty high bar to clear though.

Re: MITM on HTTPS traffic in Kazakhstan

#226
post #214
post #174

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

It won't stay trusted if it is actively used for MITM attacks. At least that's the idea.

Re: MITM on HTTPS traffic in Kazakhstan

#227
post #88
post #58

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

This is exactly what Carnivore and PRISM were

Re: MITM on HTTPS traffic in Kazakhstan

#228

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

> most software doesn't support [name constraints] (and silently ignores them rather than correctly failing closed)

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

#229
post #197

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

Ethernet can carry protocols other than IPv4. IPv6 is one of them, but there were at one time a whole slew of them, like IPX and Appletalk. But ISPs don't carry them, so they're effectively blocked and have largely died out, and everything uses IPv4 or IPv6. Even if you want to use Appletalk today, you encapsulate in IPv4 or IPv6.

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

#230
post #220

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?

And there would be no point in doing so anyway.

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.

Post reply on HN