Live data from Hacker News

MITM on HTTPS traffic in Kazakhstan

bugzilla.mozilla.org

271–280 of 471 posts

Re: MITM on HTTPS traffic in Kazakhstan

#271

Earlier quoted context omitted.

Yes? This isn't that complicated. You break it, and when competitive browser X refuses to do so, you sell the idea that browser X is compromised for all users everywhere (not just in Kazakhstan) Stop thinking about the country with literally less than 1% of world internet users and start thinking of the reputational damage a less than charitable presentation of your collaboration with a totalitarian state against you…

That's fair, but the country doing this will just fork an open-source browser and make it their official browser.

Sure. "don't use Kazakhfox, it's malware, we've submitted definitions to the AV databases" isn't a hard sell for your 99%+ audience.

Malware forks of open source projects (and closed-source software!) are not a new problem.

Re: MITM on HTTPS traffic in Kazakhstan

#272

Earlier quoted context omitted.

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?

If you want to put a stop to things like this, then you have to. Complaints from companies and the general population should be enough to fix the issue.

Re: MITM on HTTPS traffic in Kazakhstan

#274
post #260

Earlier quoted context omitted.

I'll be 40 years old later this year. I've been interested in communications and communications protocols since I was about 12. I've been a software developer with a focus on network communications for over 15 years. I'm well aware of all that you've said. My point was, they get TLS interception down, and they capture what they want from a target of interest. When they look closely at your traffic and decide all thes…

You're proposing that the penalty for being suspected of subverting the firewall is death . In those cases you're going to want a highly refined system for avoiding detection, and it's also very important that one exist, because regimes that oppressive deserve to be opposed. Fortunately the more typical case isn't kidnapping and execution but only having your connection blocked, which creates a helpful feedback loop…

> You're proposing that the penalty for being suspected of subverting the firewall is death.

no, he's being hyperbolic to make the point that in an extreme situation, a default-deny approach could facilitate mass suppression of 'undesirable' traffic without creating an insurmountable backlog of traffic for the 'bad actor state' to review in determining what to process further.

Re: MITM on HTTPS traffic in Kazakhstan

#275
post #20

Could someone explain to me what this means and/or why it's bad?

When you connect to a website via HTTPS, your browser downloads the certificate from that website and validates it by checking that the website's certificate was cryptographically signed by an entity that the browser trusts. If the certificate is valid, then you can assume that your data will only be decrypt-able by the website owner, so the connection is secure. Your browser will display a happy green banner showing…

Could companies like Facebook, Google, perhaps CloudFlare detect this is happening in anyway I wonder? Are there any characteristics of the non-FB certificate connections that could reliably be detected either in the headers sent to FB, or via client-side JS?

How about comparing the IP address of the request with the IP address reported in requests to the FB server with the IP reported if you make an XHR call to a different domain endpoint that returns your IP? That would compare the physical browser's IP with the MITM 'requestors' IP?

If enough of the centralised sites and CDNs look out for this it would render it a lot less effective. This also turns a undetected user security/privacy problem into an in your face "firewall" from the user's point of view. Now the user asks their tech friend "why can't I see FB" and their tech friends sets them up on a VPN.

Apologies if this is hand wavey I'm not a network or security expert but I am curious about this.

Re: MITM on HTTPS traffic in Kazakhstan

#276

Earlier quoted context omitted.

There are more benign uses too - many organisations run an internal PKI, and installing their root CA prevents employees' browsers from displaying warnings about untrusted certificates when accessing internal web apps/sites.

That would be a bad use IMO. Letsencrypt solves any need for legitimate certificates.

> Letsencrypt solves any need for legitimate certificates.

... unless you want any private keys to be personally signed and or generated by bob & alice over in security after checking some boxes in an internal audit form, or any other number of company-internal schemes involving signing and encryption of business-specific data

Re: MITM on HTTPS traffic in Kazakhstan

#277

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…

A mechanism to constrain root CAs to particular URLs/domains was proposed in firefox a while ago[0]. Perhaps an idea whose time has now come?

It seems like the principle of least privilege could easily be applied to the CA system rather than trusting all CAs for all domains, as there seem to be obvious/natural constraints in certain cases (like CAs that only operate under a particular country TLD).

0: https://bugzilla.mozilla.org/show_bug.cgi?id=501697

Re: MITM on HTTPS traffic in Kazakhstan

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

>Send a message to everyone requiring a government root CA with an easy install, or their internet won't work.

but atleast we know

Re: MITM on HTTPS traffic in Kazakhstan

#279
post #234

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…

No, it's not pointless. This attack was detectable because of PKI. Without it the attack would not have been detectable. Being imperfect is different than being pointless. Even if you developed the perfect algorithm for global security infrastructure, the Kazakhstan government could still just break down your door and implant the backdoor into your hardware if they wanted. So by your logic should we just forget about…

> Being imperfect is different than being pointless.

In particular, we'd see a lot more places than Kazakhstan do this if good countermeasures weren't in place...

Re: MITM on HTTPS traffic in Kazakhstan

#280
post #274
post #260

Earlier quoted context omitted.

You're proposing that the penalty for being suspected of subverting the firewall is death . In those cases you're going to want a highly refined system for avoiding detection, and it's also very important that one exist, because regimes that oppressive deserve to be opposed. Fortunately the more typical case isn't kidnapping and execution but only having your connection blocked, which creates a helpful feedback loop…

> You're proposing that the penalty for being suspected of subverting the firewall is death. no, he's being hyperbolic to make the point that in an extreme situation, a default-deny approach could facilitate mass suppression of 'undesirable' traffic without creating an insurmountable backlog of traffic for the 'bad actor state' to review in determining what to process further.

You've elegantly stated my point precisely. Thank you!
Post reply on HN