101–110 of 471 posts
The best solution would be to blacklist rouge SSL certs.
They should just put a red dot on the browser bar somewhere indicating a non-normal root cert is being used (this would also help in dev / test scenarios).
Here is the crux of the issue, many TLS middleware providers install their own root certificate for network monitoring, data loss prevention, security scanning and so on. I personally would like them to stop doing that or at least make it obvious to end users it's happening. However, in order to modify the root store, they must have been authorized to do so by the Administrator, and it's their network or hardware.
If we try to make it obvious to users that this inspection is happening, these providers will switch to using alternative methods, such as using Microsoft Detours - which would be even worse, now you have random vendors patching security critical code in such a way that is not discoverable for end-users. This cannot be prevented, because they must already have Administrator access or they wouldn't have been able to modify the root certificate store in the first place.
In this Kazakhstan scenario, imagine if adding the government certificate put a red dot that said "You are being monitored". If the government didn't like that, they could instead require you to install monitor.exe that had the exact same effect, but didn't show the dot by patching and hooking all the crypto APIs. I find this argument against adding an obvious indicator quite compelling.
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, sometimes such click would open a pop-up window with ads. Those pop-ups did also open sometimes, when I clicked on links of the page. It was unusual, because I used the same websites just a few days before that from Russia and nothing like that happened.
To figure out what's going on I opened the same webpage through proxy and compared it with localy opened one. Shell command for that was something like:
diff I'll be back in Kazakhstan in 3-5 days, I'll try to reproduce this once again.
Earlier quoted context omitted.
Browsers always trust manually installed CA roots, because that scenario is used by many corporations to monitor their traffic. OCSP, HPKP, etc won't help.
For mobile apps, though, you can bootstrap HPKP with a key built into the app. I worked on an app doing this, and it would certainly fail to connect in this scenario.
Earlier quoted context omitted.
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…
We don’t want users to trust the green check, because it never meant you could trust a site. We do want users to distrust plaintext, because it means the café you’re visiting can steal your password. I don’t see how this is a good criticism of the push for HTTPS everywhere (which appears to be the context here).
Does such a certificate compromise non-browser traffic as well? Like SSH tunnels, mobile apps, Telegram etc.
I guess you'd have to install the certificate on your phone too. I guess that means that visitors to Kazakhstan won't have internet access during their stay, unless they install the malicious certificate on their phones as well. I really hope this doesn't set a precedent.
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.
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.
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…
Steganography. With a good key and enough stuffing, it is undetectable
Earlier quoted context omitted.
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.
It must have been many many years ago, more than 10 at least. Any way to avoid or bypass name or path constraints would be considered a huge and monumental vulnerability today.
You would be unduly optimistic — for example, Apple did not support them at least as recently as 2015 (see e.g. https://bugs.chromium.org/p/chromium/issues/detail?id=407093...) and 10 years ago OpenSSL hadn't even shipped support upstream, plus however long it took your distribution to ship a major version upgrade to 1.0.
I was hoping someone might have a pointer to current information on that topic since I believe Apple did finally fix Secure Transport but not when.