I somehow feel this is good for any of those countries in between the western capital based democracies and the extreme of North Korea: it will backfire sooner or later, but without any of this silly measures trigging public awareness, people would keep believing in their leaders and brainwashed culture.
Maybe it is what it takes to move forward from a dictatorship to a (fake) democracy these days.
In order to successfully pull off the MITM attack against TLS connections they will need a rogue CA or cooperation from browsers. Fortunately Thailand is completely dependent on foreign software and services, and I see no reason why Google, Mozilla, Facebook, etc would cooperate.
The government will still be left with two options: Severely cripple themselves by blocking entire services or remain unable to decrypt traffic. Unlike China, Thailand is in no position to create their own search engines, social media and messaging systems.
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!
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.
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.
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.
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.
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).
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.
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?
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.
> 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.
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.
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.
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.
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.
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.
> 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?
I live in Thailand; I'm extremely skeptical that it's going to happen. The most likely explanation is that a few powerful generals feel like this must happen and proudly announce their plans, and technical teams responsible for actually doing it feel too intimidated to explain to the generals why it's impossible, so they just agree to it hoping that the dictatorship will be out of power before the implementation could happen.
As someone from /r/Thailand put it, "I'm hoping incompetence and indifference would save the day once again, as it has many times in the past." They can't withdraw it now without losing face, but they can let it just wither and become forgotten over a few years.
I also live in Thailand and I hope you are correct. But the fact that they can now easily buy the equipment and consulting to do this sort of thing means they might very well try it. And like I said in another comment, they don't care if it breaks the internet because they and the people they are serving don't use it like everyone else. To them the internet is little more than a major annoyance because it allows dissidents to communicate and engage in speech they don't like.
FUD is enough to control the rabble. Projects here are about funnelling money to family members. Lots of money will be spent, kickbacks will be received, and nothing will change significantly. Certainly nothing that would stop all the iPhone 6 status symbols from working or the elite will stomp all over it.
I spent two years in Thailand doing the digital nomad thing, but I've relocated to Belize for the last 3.5 years. You can stay here indefinitely on a tourist visa and the islands are beautiful, with a very laid back lifestyle. My email is in my profile if you have any questions about life here.
You do realise don't you that the US, UK, Canada, Australia, and New Zealand have been doing much the same thing for many years, and on a global level, right? Go and read the articles from Snowden's revelations about mass surveillance three years ago.
The only difference is that the Thai government is being honest about what it wants to do. The "democracies" in the five eyes implemented mass surveillance in complete secrecy.
We begin therefore where they are determined not to end, with the question whether any form of democratic self-government, anywhere, is consistent with the kind of massive, pervasive, surveillance into which the Unites States government has led not only us but the world.
This should not actually be a complicated inquiry.
We need general, automatic MITM detection in HTTP.
It's quite possible. An MITM attack has a basic quality that makes it detectable - each end is seeing different crypto bits for the same plaintext. All they have to do is compare notes.
There are out-of-band ways to do this, such as certificate pinning and certificate repositories. But these haven't achieved much traction.
Doing it in-band is difficult, but possible. An early system, for one of the Secure Telephone Units (STU), displayed a 2-digit number to the user at each end, based on the crypto bits. The users were supposed to compare these numbers by voice, and if they matched, they were probably not having a MITM attack. An MITM attacker would need to fake the voices of the participants to break that.
This is the insight that makes MITM detection possible. You can force the MITM to have to tell a lie to convince the endpoints. More than that, if you work at it, you can force the MITM to have to tell an arbitrarily complex lie. You can even force the MITM to have to tell a lie about the future traffic on the connection. That means they have to take over the entire conversation and fake the other end.
As an example, suppose a server sending a page sends, at the beginning of the page, a hash value which is based on the contents of the page about to be sent, and also based on the first 64 bytes of the crypto bits of the connection. The browser checks this. The MITM attacker now has a problem. If they don't know about this, the MITM attack immediately sounds an alarm at the browser. If the attacker does know about this, they can compute their own hash. But they haven't seen the content the hash covers, because the page hasn't been transmitted yet.
So the attacker either has to buffer up the entire page before they can send any of it, or fake the page based on some source like a cache. Buffering up the entire page adds delay. The server can add to that delay by deliberately stalling for some seconds before sending the last few bytes of the page. If the MITM attack adds 10 seconds before every page begins to load, it's obvious what's happening. The browser could even check this; if the first byte of the page doesn't appear within N seconds, don't display it.
Faking the page is a lot of work, especially if it's customized. A cache won't be enough. Users will notice if they get a generic page instead of their personal social network page.
This would be a good feature to add to HTTP2, because it has one persistent connection which, once validated, is good for many pages.
Nobody seems to be doing enough with in-band MITM detection. There's [1], but that requires "previously established user authentication credentials." Facebook has a scheme which relies on MITM attackers not knowing how to MITM Flash content.[2] That's a form of security through obscurity, but it does detect most attacks at the proxy and hostile WiFi level.
So unrelated to this, what are the best couple resources out there for understanding the PKI system? I understand it in vague terms and I can use it. I just don't know enough of the details of it to be comfortable with it.
It may be that I would be even less comfortable with it if I knew the details.
61 comments
[ 3.4 ms ] story [ 124 ms ] threadhttps://thainetizen.org/2016/05/single-gateway-back-ssl-cens...
the https everywhere movement was a pain-in-the-ass when I was in China, because many websites would redirect me from http to blocked https.
I switched from Gmail while I was there (and back) and just watched youku instead of youtube, so I mostly didn't bother paying for a VPN.
Maybe it is what it takes to move forward from a dictatorship to a (fake) democracy these days.
The government will still be left with two options: Severely cripple themselves by blocking entire services or remain unable to decrypt traffic. Unlike China, Thailand is in no position to create their own search engines, social media and messaging systems.
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.
Though I don't see how they will manage that for mobile browsers.
[1] http://www.unixmen.com/sshuttle-poor-mans-vpn-ssh/
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.
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.
They would have to give their private key to their clients to achieve a MITM attack, right?
[0] https://crt.sh/?id=19538258
Others have suggested they could provide a cloud-type service to achieve the same result.
[0]: https://blog.cloudflare.com/keyless-ssl-the-nitty-gritty-tec...
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...
Thats literally the one thing you aren't allowed to do as a CA.
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.
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...
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?
As someone from /r/Thailand put it, "I'm hoping incompetence and indifference would save the day once again, as it has many times in the past." They can't withdraw it now without losing face, but they can let it just wither and become forgotten over a few years.
firstname dot lastname at gmail
The only difference is that the Thai government is being honest about what it wants to do. The "democracies" in the five eyes implemented mass surveillance in complete secrecy.
We begin therefore where they are determined not to end, with the question whether any form of democratic self-government, anywhere, is consistent with the kind of massive, pervasive, surveillance into which the Unites States government has led not only us but the world.
This should not actually be a complicated inquiry.
https://archive.org/details/EbenMoglen-WhyFreedomOfThoughtRe...
Surveillance is not an end toward totalitarianism, it is totalitarianism itself.
https://www.washingtonpost.com/world/national-security/nsa-i...
It's quite possible. An MITM attack has a basic quality that makes it detectable - each end is seeing different crypto bits for the same plaintext. All they have to do is compare notes.
There are out-of-band ways to do this, such as certificate pinning and certificate repositories. But these haven't achieved much traction.
Doing it in-band is difficult, but possible. An early system, for one of the Secure Telephone Units (STU), displayed a 2-digit number to the user at each end, based on the crypto bits. The users were supposed to compare these numbers by voice, and if they matched, they were probably not having a MITM attack. An MITM attacker would need to fake the voices of the participants to break that.
This is the insight that makes MITM detection possible. You can force the MITM to have to tell a lie to convince the endpoints. More than that, if you work at it, you can force the MITM to have to tell an arbitrarily complex lie. You can even force the MITM to have to tell a lie about the future traffic on the connection. That means they have to take over the entire conversation and fake the other end.
As an example, suppose a server sending a page sends, at the beginning of the page, a hash value which is based on the contents of the page about to be sent, and also based on the first 64 bytes of the crypto bits of the connection. The browser checks this. The MITM attacker now has a problem. If they don't know about this, the MITM attack immediately sounds an alarm at the browser. If the attacker does know about this, they can compute their own hash. But they haven't seen the content the hash covers, because the page hasn't been transmitted yet.
So the attacker either has to buffer up the entire page before they can send any of it, or fake the page based on some source like a cache. Buffering up the entire page adds delay. The server can add to that delay by deliberately stalling for some seconds before sending the last few bytes of the page. If the MITM attack adds 10 seconds before every page begins to load, it's obvious what's happening. The browser could even check this; if the first byte of the page doesn't appear within N seconds, don't display it.
Faking the page is a lot of work, especially if it's customized. A cache won't be enough. Users will notice if they get a generic page instead of their personal social network page.
This would be a good feature to add to HTTP2, because it has one persistent connection which, once validated, is good for many pages.
Nobody seems to be doing enough with in-band MITM detection. There's [1], but that requires "previously established user authentication credentials." Facebook has a scheme which relies on MITM attackers not knowing how to MITM Flash content.[2] That's a form of security through obscurity, but it does detect most attacks at the proxy and hostile WiFi level.
[1] http://www.cc.gatech.edu/~traynor/papers/dacosta-esorics12.p... [2] http://www.scmagazine.com/researchers-detect-ssl-mitm-attack...
It may be that I would be even less comfortable with it if I knew the details.