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

301–310 of 471 posts

Re: MITM on HTTPS traffic in Kazakhstan

#301

Post by haimez »

u801e wrote: post #268
skela224 wrote: post #166

Earlier quoted context omitted.

How would the client certificates be distributed to users in Kazakhstan?

You could send them to the email address you used to register the account. Then install it in your browser's or OS' certificate store.

Email is similarly unencrypted by default and can be blocked if encrypted and being used as an active circumvention vector. Yes, mail servers outside the jurisdiction could work until https access to gmail is also blocked- but that’s not outside the realm of possibility (see: China) and also begs the question: how do you get to your secure gmail web interface if you need to receive a secure email before your first login?

Re: MITM on HTTPS traffic in Kazakhstan

#302

Post by vbezhenar »

technion wrote: post #296
vbezhenar wrote: post #282

Earlier quoted context omitted.

You don't have to serve that website publicly or even set up DNS records. You only need to set up DNS verification to serve one public TXT record for letsencrypt. Everything else could be internal. Letsencrypt certifies that you own domain. You can do anything with that domain.

I'm aware you can use Lets Encrypt that way, I just don't agree that it's bad use of an internal PKI to use it as an alternative.

Well, it's unnecessary work to install and maintain that internal CA. Keeping CA key safe is very important, because leaked key might lead to your internal connections to, e.g., Google be compromised, so it's like keeping a bomb inside your building. If you already have that internal PKI, you can use it, sure, but I still think that it's a bad idea to use it only for internal websites.

Re: MITM on HTTPS traffic in Kazakhstan

#303

Post by edoo »

I would actually be shocked if US agencies can't do the same here almost all the time. There has to be at least one trusted root authority that is controlled by an agency. Do you remember when RSA made a $10 mil deal to give .gov a backdoor back in the day. There is no reason any major US based certificate issuer couldn't do the same, or an employee turned into an asset to sneak it to them, or they just straight hack the places and get certs they can generate anything on. You might be able to detect it by logging the issuer of the cert, the browser doesn't care who auths it as long as it is trusted. It would be odd for most places to have certs issued by multiple authorities.

Re: MITM on HTTPS traffic in Kazakhstan

#304

Post by krick »

cpach wrote: post #165
JaRail wrote: post #142

I'm surprised at comments in the bug threads suggesting they do nothing. The idea being that fighting this would force governments to fork/change browsers, ultimately being a worse experience for users. Seems like betraying people's trust is a pretty bad user experience. There will always be a fight over privacy. Giving up to a foreign government is a terrible idea. It would absolutely just let the problem spread and…

If a government mandates its citizens to install the government’s own root certificate, then it’s not that easy to find a long-term technological solution. The problem here is not a technical one, IMHO. The problem is that the government of Kazakhstan is not respecting the freedom of its people. Point in case: In 2018, Kazakhstan ranked #144 in the Economist Intelligence Unit’s Democracy Index. Countries such as Chin…

I don't agree. First off, no matter how you or me may be enraged by the incident, this is not (and shouldn't be!) a "moral problem" for the Firefox. And, by the way, if you are not living in the Kazakhstan, it's not for you to decide "what is needed first and foremost in Kazakhstan", it's their business entirely.

From the point of view of the Firefox, this should be an extremely simple technical problem. There is CA that is known to be "compromised" in an entirely technical sense, i.e. it is known to allow MITM. So blacklist it, end of discussion. Allow the user to remove it from the blacklist somewhere in browser's settings: it's not for you (Firefox) to decide what the greater good is.

I assume, it would indeed be a problem for Kazakhstan to fixing the service if people are not using the internet, because their browser doesn't work (because it's both an economical and a social disaster, obviously). Or maybe it wouldn't, because Kazakhstan will send troops to every home to replace every browser by Kazakh-fox or whatever. And it may play out to the better in the end, as much as it can lead to massacre.

But (as a 3rd party technological company) don't play mighty and powerful, responsible for the lives of people in Kazakhstan, it's not your fucking business how they live. You see a technological problem (known CA allowing MITM) — you solve it (block the CA!). That's what you promised your users to provide, to fix technological problems, not to fix the political climate in Kazakhstan, USA, China, whatever.

Re: MITM on HTTPS traffic in Kazakhstan

#305

Post by PeterisP »

u801e wrote: post #269
zrm wrote: post #176

Earlier quoted context omitted.

Using CAs to authenticate clients is subject to the same attack. They block communication from any client that won't disclose its private key to the MITM box or use it to encrypt/sign whatever the MITM requires it to. You can't have security if you have a MITM that says "compromise your endpoint or we block you" and you concede to that. The only real solutions are either political or making the encrypted traffic look…

> Using CAs to authenticate clients is subject to the same attack. You don't need to use a publicly available CA to verify client-side certificates. The server could use its own internal CA to sign CSRs from clients and send the reslting certificate back to the client via email or some other means.

In which case the MITM will be unable to connect to the server because it won't have the certificate (that you sent via email or some other means), so the service simply won't work. That's the whole point, you either go through MITM or not at all.

Re: MITM on HTTPS traffic in Kazakhstan

#306

Post by mdhardeman »

bcoates wrote: post #300
mdhardeman wrote: post #283

Earlier quoted context omitted.

Except they are a new problem when the use of them is mandated by a nation-state.

Which is bad news for the ~15m internet users in Kazakhstan. For the ~4000m internet users not in Kazakhstan & generally immune to their rubber hose attack, protecting them from being one BGP fuckup away from being MITMed by a hostile foreign power is much more important.

Totally separate problem that I agree needs to be fixed.

In reality, being one BGP trick away from a mere dedicated individual or corporate owning certs for your domain is an actual risk today.

Re: MITM on HTTPS traffic in Kazakhstan

#307

Post by bscphil »

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.

Actually, I don't see the issue here. It is literally the same thing as corps intercepting the connections of their employees or visitors. In fact I trust my employer even less than I trust the government.

But I disagree with the response that says we should do nothing. In fact, corporate root certs should be blocked / ignored by the browser in the exact same way and for the exact same reason. The only exception should be certs issued for a limited number of domains that are only active in a specific developer mode that can be enabled by knowledgeable users.

Sure, technological solutions can't solve this issue 100%. (My employer can also fork a browser.) But acting as if everything is OK when the connection is being MITMed is wrong and browsers shouldn't do it.

Re: MITM on HTTPS traffic in Kazakhstan

#308

Post by _jomo »

droithomme wrote: post #261
mkagenius wrote: post #194

Earlier quoted context omitted.

> 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)

I'm in the US and I've caught my ISP doing MITM exploits over http (not https... so far). It's global and regular folks have absolutely no chance of knowing what is going on. Needs to be criminalized for any hope of resolution.

Comcast has even published an informational RFC describing how to inject crap into HTTP requests:

https://tools.ietf.org/html/rfc6108

Re: MITM on HTTPS traffic in Kazakhstan

#309

Post by PeterisP »

dsl wrote: post #206
ignoramous wrote: post #122

Earlier quoted context omitted.

> Now "us techies" have to find a new technical solution to a very social problem. Cert pinning does mitigate it for apps, doesn't it? The end-user doesn't need to really worry abt rouge root CAs, if my understanding is right. Traditional VPNs, P2P VPNs, Tor as a Proxy (decentralised net? dat/i2p/freenet/ipfs) could solve it generally across various use-cases, of which, VPNs are already mainstream.

> Cert pinning does mitigate it for apps, doesn't it? Applications where the developer has pinned to their own certificate will stop this attack. Chrome and Firefox will ignore pinning for locally installed CAs. This is a very common use case in the enterprise where, for example, a bank has audit requirements to decrypt and store all workstation traffic.

It'll "stop this attack" by ensuring that the app won't work through the MITM - so it won't be able to connect from any Kazakhstan users unless/until the pinning is removed.

Re: MITM on HTTPS traffic in Kazakhstan

#310

Post by bscphil »

LoSboccacc wrote: post #69
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…

to be fair some of us told from the beginning that making all user used to trust the green check would have caused this sort of trust fatigue to the point the majority would have stopped bothering with the actual certificate content and trust chain, and you can search my history highlighting this very issue in relation to let's encrypt, it was a social issue from the very beginning and I got downvoted heavily and rep…

I think you're missing one important detail: the idea behind the green padlock is that the average end user isn't technically capable of (or shouldn't have to) monitor all the details of their internet connections to make sure they're secure.

If that basic intuition about users is correct, the solution is not to give up on this and force users to deal with the true complexity of the situation. The solution is for the browser to show a red blinking INSECURE instead of the green padlock when the cert it receives for a site doesn't have a valid chain to a root in the default key store shipped with the browser.

To be honest, I can't figure out why this isn't already the default behavior. It would solve a bunch of other problems as a side effect, including insecure crappy antivirus programs that MITM your internet connection.

Post reply on HN