Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MITM on HTTPS traffic in Kazakhstan

bugzilla.mozilla.org

Post reply on HN
Print view View original

211–220 of 471 posts

Re: MITM on HTTPS traffic in Kazakhstan

#211

Post by mdhardeman »

stefan_ wrote: post #172
jedberg wrote: 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.

There's a broader reason. If the normal browsers break this, the response will just be that they do their own national fork of an open-source browser and distribute that to their people.

The downside of pushing them to that is that that browser will be unlikely to get regular security updates and will likely hide the interception.

Re: MITM on HTTPS traffic in Kazakhstan

#213

Post by mdhardeman »

schoen wrote: post #4
isostatic wrote: post #2

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?

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.

Actually true root certs when evaluated by the browsers will have their name constrains within the root certificate themselves ignored.

Modern browsers do respect name constraints of intermediate issuing certificates.

Re: MITM on HTTPS traffic in Kazakhstan

#214

Post by yjqcy »

cpach wrote: post #174
StreamBright wrote: post #143

Earlier quoted context omitted.

Not only that but they can happily MITM HTTPS as well. Not all the HTTPS sites use certificate pinning or HSTS.

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

#216

Post by baq »

mdhardeman wrote: post #193
terlisimo wrote: post #182

Earlier quoted context omitted.

Hello, To continue using internet, you need to install our government-provided fork of Firefox that doesn't blacklist our government-provided root cert. regards, your Tele2

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.

Re: MITM on HTTPS traffic in Kazakhstan

#217

Post by tgragnato »

mholt wrote: post #149
lame-robot-hoax wrote: post #92

Earlier quoted context omitted.

So uh, should I be concerned at all if my connection came back as a likely MITM from my home network in the US? Or is it most likely a false positive caused by my firewall or something? I tested it both off a VPN and on a VPN from my iPhone yet still had the same result both times.

iOS is tricky because of its weird rules regarding TLS libraries and web views. If you are sure you haven't any rogue CA certs in your applicable trust stores, it's probably a false positive.

FYI, Safari on iOS 13 (beta) uses a different set and ordering of extensions.

I currently see "0, 23, 65281, 10, 11, 16, 5, 13, 18, 51, 45, 43, 21".

Re: MITM on HTTPS traffic in Kazakhstan

#218

Post by vkou »

novok wrote: post #178
vkou wrote: post #152

Earlier quoted context omitted.

Okay, say you live in Kazakhstan. You stop using the Internet. Do you think the government will care?

If it ruins their economy, yes.

99% of the population will happily install the government cert, and life will move on.

The 1% will either put up with it, stop using the internet, or leave.

One thing will happen though - the economy will not be ruined.

Generally speaking, since the Cold War ended, these sorts of countries don't mind troublemakers leaving. It's better international PR for them to have 'problem people' leave voluntarily, than to repress them.

Re: MITM on HTTPS traffic in Kazakhstan

#219

Post by vbezhenar »

arpa wrote: post #170

Actually, a dns caa record could be of use in this scenario to at least alert the client that the traffic has been intercepted. Then again it is trivial to intercept and rewrite plain DNS requests and dns over https would also be subject to the same https mitm intercept... Maybe certificate pinning was a right idea.

CAA is for issuers, not for browsers. And yes, without DNSSEC it's easily spoofed.

Re: MITM on HTTPS traffic in Kazakhstan

#220

Post by cpach »

syn0byte wrote: post #204
cpeterso wrote: post #28

Earlier quoted context omitted.

But we are in a better place than before. Without HTTPS everywhere and governments needing to ask people to install new root certs, we would not have learned about this Kazakhstan MITM issue.

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?
Post reply on HN