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

191–200 of 471 posts

Re: MITM on HTTPS traffic in Kazakhstan

#191

Post by mholt »

darkpuma wrote: post #156
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.

On this machine I get "likely" in firefox, "unlikely" in a firefox private window and "unlikely" in chrome. Not sure what to make of that. (Also all of the installed extensions are also enabled in private mode. I know that changed recently so I checked. Also the certs the browers claim I'm getting in all three scenarios seem to be the same...)

Probably an outdated implementation of our rules, regarding Firefox on your machine. Feel free to file an issue; also we will be switching to Cloudflare's mitmengine (based on the same research paper, but they have way more resources to keep it maintained at scale, thus making it more accurate) in Caddy 2 in a matter of months.

Re: MITM on HTTPS traffic in Kazakhstan

#192

Post by cesarb »

lame-robot-hoax wrote: post #92
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…

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.

It also said "Likely MITM" for me (Firefox on CentOS 7), but the SHA256 certificate fingerprint in the browser matches the one seen by Qualys (https://www.ssllabs.com/ssltest/analyze.html?d=mitm.watch), so at least in my case it seems to be a false positive.

Re: MITM on HTTPS traffic in Kazakhstan

#193

Post by mdhardeman »

terlisimo wrote: post #182
akersten wrote: post #132

Google, Mozilla, and Microsoft need to take a stand here and blacklist these certs. All of the efforts to move to HTTPS, and all of the rhetoric surrounding it, are just wasted time and empty words if we as a tech community allow this kind of behavior to go unchallenged. This sets such a dangerous precedent, and governments need to know that this kind of meddling will not be tolerated.

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.

Re: MITM on HTTPS traffic in Kazakhstan

#194

Post by mkagenius »

break_the_bank wrote: post #124
gnull wrote: post #103

What is interesting is that some local internet providers in Kazakhstan used to inject their own ads into http websites their users visit. I wonder if they will start doing the same with https now. I noticed this behaviour last February with Kazakhtelecom (telecom.kz) internet provider. When I opened an http website in my browser and started clicking randomly on the parts of the page which are usually not clickable,…

This is so bad. I'm from India and at my parents place we have the government run internet provider. They MITM and inject advertisements all the time showing annoying popups whenever you open an http link. I don't know how this is legal even.

> I don't know how this is legal even.

Legality is secondary when you are punching up in a 3rd world country. (I am from India)

Re: MITM on HTTPS traffic in Kazakhstan

#195

Post by niij »

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…

Would this detect MITM if you installed a root cert from ex: school, employer, etc?

Re: MITM on HTTPS traffic in Kazakhstan

#196

Post by sbaha88 »

vbezhenar wrote: post #71

I'm from Kazakhstan using the biggest Internet provider (Kazaktelecom) and that's not true for me. No MITM here. May be not yet. Also checked mobile provider (Activ) and no MITM here too. But I saw local news, so probably not fake, though I'm not sure if it'll be mobile internet only or all providers.

Seems to affect Astana mobile users for now

Re: MITM on HTTPS traffic in Kazakhstan

#197

Post by zrm »

mdhardeman wrote: post #173
pcwalton wrote: post #159

Earlier quoted context omitted.

I'm less pessimistic. The practical result of this is likely just going to be more business for the cottage industry of Great Firewall VPNs, which already compete with one another in traffic obfuscation against an adversary far more sophisticated than the government of Kazakhstan. Thankfully, this is currently a case in which the incentives of the market happen to align well with the goals of defeating censorship.

The way that a real authoritarian government entity would handle that is... An agency is tasked with doing random sample captures of randomly selected target internet connections. Inventory all the types of traffic being exchanged. Flag anything that isn't obvious plaintext or already being MiTM'ed for analysis follow up. Implement new blocking rules or interception implementation for each flow that isn't already bei…

> 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 arbitrary numeric data?

How do you distinguish data like that, which outside of some headers may be indistinguishable from random numbers, from someone using the same format or protocol for encoding arbitrary encrypted data?

Re: MITM on HTTPS traffic in Kazakhstan

#198

Post by jcrites »

ralphm wrote: post #128
vbezhenar wrote: post #104

Earlier quoted context omitted.

A lot of internal enterprise networks use MITM, so your app won't work there as well. It might be a good thing or not, depending on your use-case.

Yeah, I considered this a feature. As mentioned elsewhere in these comments, we should have a way to limit the scope of corporate certs.

One solution is to use Name Constraints. The organizational certificate authority could be issued with Name Constraints limiting its power to a certain domain name only, e.g. *.example.com, using Permitted Subtree.

If I was setting up an organizational CA for internal websites (not MITM), I would consider using Name Constraints to limit the certificate's scope and potential for abuse or compromise.

Re: MITM on HTTPS traffic in Kazakhstan

#199

Post by AndyMcConachie »

What makes everyone so sure this isn't happening everywhere already?

The problem Kazakhstan had was that there was no existing CA they could already force to issue certs. So they had to make a new one. It would be foolish to assume that none of the many trust anchors your browser already trusts haven't already been compelled by your local government to do exactly this.

Also, DANE and DNSSEC solves this problem.

Re: MITM on HTTPS traffic in Kazakhstan

#200

Post by wiml »

acdha wrote: post #10
schoen wrote: post #4

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

The last time I looked into it, a few years ago, everyone except Apple had some basic amount of support. (That is, openssl, firefox, windows, and android — that's all I looked into.) I set up my private CA with name constraints, but I had to mark them noncritical if I wanted iDevices to be able to use the CA at all.

But the other systems did at least appear to honor the constraints.

I've asked Apple security folks about this a few times, but they just look uncomfortable and change the topic.

Post reply on HN