> In order to successfully pull off the MITM attack against TLS connections they will need a rogue CA or cooperation from browsers.

Well, "fortunately", Blue Coat Systems, leading manufacturer of intercept devices for authoritarian regimes, now has an intermediate cert courtesy of Symantec CA, so they're fully capable of issuing and installing MITM certs for use on their clients' devices.

Would it be hyperbolic to say vendors like Blue Coat have blood on their hands?

Yeah it's just a tool and yeah your workplace or school might need one to "keep the children safe", and yeah they're not responsible for what their customers do with their products. But when they knowingly sell[1] to repressive governments where bad things happen to dissenters, what does that make them? And please spare us the "terrorist" and "criminal" barf, we've heard it in the West.

Any Blue Coat care to comment?

1. https://www.eff.org/deeplinks/2011/10/blue-coat-acknowledges...

This is why HSTS pre-loading is so important: https://hstspreload.appspot.com

Excellent point. The trustworthiness of the CA system demands the revocation of that certificate.

Said trustworthiness should have stopped them from granting the certificate in the first place.

Yeah. Maybe its issuer should also be revoked for good measure.

I was under the impression that they can't issue Sub-CAs because the pathlen of their Cert is set to 0. [0]

They would have to give their private key to their clients to achieve a MITM attack, right?

[0] https://crt.sh/?id=19538258

They might have to deploy their private key on the devices they maintain for their clients, perhaps relying on a secure keystore on-device to try to protect it from client sniffing (presuming quietly selling it to the client isn't part-and-parcel of the deal).

Others have suggested they could provide a cloud-type service to achieve the same result.

Thank you, do you have a link with more technical explanations?

I'm not entirely familiar with sub-CA specifics, but CloudFlare (at the very least) has developed a system for deploying SSL with off-site private keys[0]; I imagine that could be used in a situation like this.

[0]: https://blog.cloudflare.com/keyless-ssl-the-nitty-gritty-tec...

You would think that if they did something like this their (or Symantec) CA will be revoked... right guys?

If Blue Coat issues a certified for google.com, then its own intermediate certificate gets revoked by all browser vendors in a matter of days. They can use rogue certificates for targeted attacks, not for mass surveillance.

How the fuck did they get that and why is Symantec still included in common roots?

Thats literally the one thing you aren't allowed to do as a CA.

> why is Symantec still included in common roots?

Because they (and the companies they own, like Verisign), are the root of about 30-40% of all active, web-visible ssl certs at the moment.

No browser maker, even Google is going to break that much of the web over one shady intermediate cert. The consequences for users are too high and too many people are willing to excuse it because it's "only" a pathlen=0 and it would be noticed if used en masse so it's "only" useful for targeted attacks by state-actor clients.

I think they'll go the simple route: They;ll install a root CA that signs all other CAs going through to mitm. People will get warnings and just install the root CA. The government will probably be helpful by giving you links to browser binaries that already have the root CA installed. Of course their systems will be hacked by the americans, russians, israelis and chinese, at which point all of these entities will be able to mitm the mitm - mitm-ception!

Cert pinning doesn't just give warnings, it simply refuses connect over MITM, period. Just a few days ago I was at some airport wifi hotspot that was MITM'ing things, my android phone simply refused to go to https://google.com with a warning about this and no option to accept the cert signed by their fake CA.

Unfortunately browsers exempt locally installed CAs from MITM countermeasures, to support employer/school mandated domestic surveillance in the USA.

Do those bypasses apply for HSTS-preloaded certs as well? My understanding is that the intention of HSTS preloading is to address this sort of attack, but haven't dug through the browser code to see what's happening in standard distributions.

Yes. It's explicitly not part of their threat model: https://www.chromium.org/Home/chromium-security/security-faq...

If you have a Root Cert installed on your system, and they are MITMing traffic to a HSTS site with that Cert then your browser will give no warnings (for HSTS or non-HSTS sites).

The point of HSTS (and preloading) is to protect clients from sslstrip (and similar attacks). as in, client types in a http url, and the attacker prevents the http connection from being upgraded.

That's one of the goals of HSTS itself, but preloading designed to allow secure-only communications when establishing a connection to a hitherto-unused site, so that MITM attacks can't simply provide their own certs on first connect.

But locally installed certs can bypass that restriction in all major browsers.

Well, so they will helpfully supply browser binaries that have cert pinning disabled?

Though I don't see how they will manage that for mobile browsers.

I think that it will be just like the single gateway in general - there's some technically incompetent talk about it and absolutely no action.

Word is that the single gateway is moving forward toward implementation. They just stopped talking about it.

My guess is that they will attempt to do what is being talked about. If it breaks the internet in Thailand they don't care. The junta and their masters don't really understand and don't use it. It's just a toy to them and a place that is used to spread speech they don't like. The royalist elites that the junta are focused on protecting have their private bankers and underlings to take care of things so they don't care if internet banking is broken or if social media breaks. All that matters to the junta is protecting their core interest group of royalists.

Is there a way to leverage such access into secure browsing? Some kind of "secure https" over "mitm https", where they only see the encrypted layer even with their mitm access?

You can go over a VPN. I use the VPN my corporation provides as I deem them trustworthy. Before this I used an AWS EC2 instance and did a poor man's VPN using sshuttle[1] . I've also done it using sshuttle to a NAS I have sitting in my living room.

[1] http://www.unixmen.com/sshuttle-poor-mans-vpn-ssh/

When you connect to a VPN doesn't it do key exchange in the same way as making a https connection to a website? They would just MITM that as well, right?

You can easily do double tunneling, sure. Or even tunnel over DNS. Or over ping packets.

It would also break software updates from Microsoft, Apple, Google, etc.

And like one bazillion apps that unlike browsers will not have any UI to ask the user to confirm if falling back to unencrypted channels is okay.

I really don't see this working without Thai people revolting...

They can try to force local computer retailers to install a root CA before systems are sold.

They could try that. They might be able to get the small number of phone carriers to do it on handsets they sell. Of course, they'd have to ask their handset partners who control the firmware to do that for them.

Android dominates in Thailand. I wonder if Google's licensing allows vendors to make such modifications for carriers? The leaked agreement between Google and Samsung explicitly forbids tampering with any of Google's software.

> I see no reason why Google, Mozilla, Facebook, etc would cooperate.

Because they are for-profit businesses who would want an economic edge over competitors in the Thai market and aren't vanguards for classical/social liberal ideals?

Mozilla once was