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

Kazakhstan to MitM all HTTPS traffic starting Jan 1

telecom.kz

Post reply on HN
Print view View original

251–260 of 378 posts

Re: Kazakhstan to MitM all HTTPS traffic starting Jan 1

#251

Post by com_kieffer »

duncan_bayne wrote: post #201
dujiulun2006 wrote: post #28

Earlier quoted context omitted.

Chinese govt is also capable of doing this. Best part? We even have our trusted* root certificate! Could this get any "better"? Sure! We can even MITM all the OUTGOING https traffic if we want! #GitHubDDoS * Recently un-trusted by Apple and Mozilla. https://support.apple.com/en-us/HT204938

I really don't understand how that sort of behaviour doesn't constitute an act of war. Imagine if China sent saboteurs in-country to physically destroy infrastructure being used by American businesses. That would Not Be Taken Lightly.

The same way that Stuxnet destroying Iranian centrifuges was an act of war ?

Re: Kazakhstan to MitM all HTTPS traffic starting Jan 1

#252

Post by throaway321 »

lmm wrote: post #248
tomjen3 wrote: post #211

Earlier quoted context omitted.

Can you name some examples of what they can do? Because other than release some sort of virus, which will be found in a matter of months, I don't think they can infect the entire country.

They can target more specifically than that. Suspected activists get a keylogger bundled in their next windows update. Later on another update removes all traces of it. It might take decades before something like that was noticed.

Windows doesn't use the certificate store for windows updates. Installing a root CA does not allow you to provide windows updates because I believe they hardcode the cert in the updater.

Other non-windows updates do allow you to install other software.

To set this up, Kazakhstan will have to set up their CA with the bit set for software signing. This bit will be visible by everyone and it'll be very telling instead of just being allowed as a root CA for ssl/https sites.

Re: Kazakhstan to MitM all HTTPS traffic starting Jan 1

#253

Post by netik »

andreyf wrote: post #178
dogma1138 wrote: post #160

Earlier quoted context omitted.

It's unlikely that the Kazakh government would be able to do that much with it. Kazakhstan has a population of about 18M and internet penetration of about 35% if they would really want to sift through all that traffic they are more than welcome to do so, just keep in mind that even the US would probably not be able to do so with any degree of effectiveness. The only thing that Google et al. could do is refuse to prov…

How is China doing the same?

Western companies sell them hardware and software to process the traffic that they Capture. Cisco, et.al is complicit in this work, including the firewall itself.

Re: Kazakhstan to MitM all HTTPS traffic starting Jan 1

#254

Post by duncan_bayne »

com_kieffer wrote: post #251
duncan_bayne wrote: post #201

Earlier quoted context omitted.

I really don't understand how that sort of behaviour doesn't constitute an act of war. Imagine if China sent saboteurs in-country to physically destroy infrastructure being used by American businesses. That would Not Be Taken Lightly.

The same way that Stuxnet destroying Iranian centrifuges was an act of war ?

Yes. Although I'd have thought that particular war would have started back with the hostage-taking in, what, 1979?

I really don't understand relationships between States.

Re: Kazakhstan to MitM all HTTPS traffic starting Jan 1

#255

Post by netik »

chatmasta wrote: post #135

Why is Kazakhstan's cert any different than the hundreds of "trusted" root certificates that came preinstalled on my mac? Looking at my mac's cert keychain, there are 185 trusted root certs. I don't know what any of them are or who has the private key to them. My ISP could MITM my traffic whenever it wants to, if it has the private key of one of the hundreds of trusted root certs on my device.

If you don't trust them, turn them off. That's what I do, at least. I've disabled the vast majority of those roots in Keychain Assistant.

Re: Kazakhstan to MitM all HTTPS traffic starting Jan 1

#257

Post by pdkl95 »

iofj wrote: post #128
exelius wrote: post #60

Earlier quoted context omitted.

Pretty sure that Netflix loads a Flash client (or some other trusted code module) to prevent this. But you're right; the browser isn't secure enough to enable client-side encryption over HTTP as it would be trivial to MITM and sideload JS code to defeat it.

That's the problem with "client-side encryption". It doesn't work because the provider also has the power to replace the code with no say from you. And it's not very detectible because they do it all the time.

Client side encryption works just fine. It's only a problem in a browser where you have to download the possibly-MitM'd program each time you want to use it. Actual installed client software that encrypts end-to-end is the proper way to use encryption.

One catch: remember that the browser itself absolutely should not be the installed program doing the end-to-end encryption, where bugs can allow the private keys to be leaked. Important data like the private keys shouldn't even be in the same address space. See gpg-agent/ssh-agent as an examples of how to keep sensitive data in a separate process.

Re: Kazakhstan to MitM all HTTPS traffic starting Jan 1

#258

Post by tptacek »

pdkl95 wrote: post #226
tptacek wrote: post #89

Earlier quoted context omitted.

No, it isn't. Locally installed certificates override pins; if they didn't, HPKP browsers wouldn't be deployable inside large companies that have regulatory requirements to monitor traffic from their own desktops, and there would be no benefit, because an adversary who can install software or reconfigure your machine can defeat pins in a variety of other less transparent ways. HPKP is great, but it doesn't address th…

> Locally installed certificates override pins. Which is a blatant security risk, which should be fixed immediately. > wouldn't be deployable inside large companies that have regulatory requirements to monitor traffic from their own desktops I guess they don't use ssh? This claim is complete nonsense, because you are conflating the installing of a certificate with a capability to override HPKP. All those businesses n…

I don't care enough about this to argue about it. I see why people don't like that Chromium works this way, and I see clearly why Chromium doesn't let pins override local configuration. Meanwhile, the cost of bypassing pins if you can run code locally is very low, not enough to change my risk calculus. I can see why Google doesn't start an arms race over a trivial speed bump, and I can see why you might want the speed bump.

If you want to be outraged about it, that's fine. I know other smart people who are also outraged about it.

Remember, though: we largely have Google and Chromium to thank for pioneering certificate pinning in the first place.

Re: Kazakhstan to MitM all HTTPS traffic starting Jan 1

#260

Post by tptacek »

pdkl95 wrote: post #257
iofj wrote: post #128

Earlier quoted context omitted.

That's the problem with "client-side encryption". It doesn't work because the provider also has the power to replace the code with no say from you. And it's not very detectible because they do it all the time.

Client side encryption works just fine. It's only a problem in a browser where you have to download the possibly-MitM'd program each time you want to use it. Actual installed client software that encrypts end-to-end is the proper way to use encryption. One catch: remember that the browser itself absolutely should not be the installed program doing the end-to-end encryption, where bugs can allow the private keys to be…

Nit: you are effectively re-downloading browser DOM JS crypto programs every time your browser loads a new DOM element for the page hosting the app. It's not just something that happens when you first visit the site.

That's one of the things that makes securing browser JS crypto so intractable.

Post reply on HN