TLS 1.3 Is an Opportunity for Amazon, Google and Microsoft to End Censorship
privateinternetaccess.com
privateinternetaccess.com
I will say I haven't heard of Amazon censoring anything yet, at least not at a level I would consider massively inappropriate for a cloud services provider. Not selling something on their normal store is one thing, but pulling the plug on an AWS account for website behavior would be something entirely different.
https://freebeacon.com/issues/gun-rights-activists-posted-gu...
I'm a journalist and have seen a screencap of the takedown that Amazon issued to the Firearms Policy Coalition, which started and maintains the censored site (CodeIsFreeSpeech.com). The takedown erroneously cited a temporary restraining order issued against an entirely different site (defcad.com) as the reason for the sudden, no-warning booting of the site from AWS.
And as you mentioned, Azure just now threatened to pull Gab.ai off its platform over a pair of anti-Semitic posts.
https://www.businessinsider.com/microsoft-gab-azure-cloud-an...
So these infrastructure providers are absolutely involved in censorship right now.
https://fightthefuture.org/article/the-new-era-of-corporate-...
It's easy to side with CloudFlair when they go against a site like The Daily Stormer (Which is so out there it might just fall into Poe's Law).
The fact is that most decent hosting is only available in a handful of industries. Even the CF CEO has had misgivings of his decision and it gets us into a really questionable space.
Platforms should be free to do what they want right? They should be able to deny customers .. just like an airplane company should be allowed to keep people who crazy political opinions from boarding plans right? .. oh and black people too. Oh wait..what?
The freedom of speech in the US is pretty limited to government censorship. But we don't let businesses do whatever they want. They can't keep a certain ethnic group from eating at their restaurant, and in many states they can't choose if their venue allows smoking. The big question is, does speech need to fit into this same framework?
With the recent child protection act that gutted craigslist and took down backpage (an act that is leading to more violence against sex workers in the US and an act that the EFF and ACLU are actively fighting as being unconstitutional), we see the US government holding content hosting companies liable for the criminal actions of their user base. That is disturbing and already a form of government control over what customers a business is allowed to have.
It'd be one thing if censored sites could just go to another provider, but there are only a couple of big providers and their mass has the ability to crush anything they find questionable.
The problem is that the same sort of people who are trying to shut down sites through legal pressure tactics against Amazon, Google etc are absolutely happy to use illegal tactics too. In particular once sites are booted off large providers onto smaller ones or self hosted sites, that's when the DDoS attacks start. Infowars already saw one, for instance. How many firms can sink large DDoS attacks without needing to kick out the target? Not many.
If a pressure group or activist employee base can get content off CloudFlare, Google, Amazon and Microsoft then DDoS-wielding ideological zealots will do the rest and then the site is gone for good.
Where does speech go then?
It's a very dangerous game for the people at these content platforms to play. I don't see Republicans sitting back doing nothing as their worldview and voter base is systematically wiped off the internet. Legislation seems likely.
Moreover how do you measure "public outcry"? The very point of censorship is to stop public outcry. If the media aren't writing stories and anyone who expresses concern is deemed to be supporting hate speech and banned, then it will look a lot like nobody cares even if many people do.
Federated / p2p systems like Mastodon? Non-Web-proper sites based on Dat and IPFS?
/*
If I were an adviser to the conspiracy theorists' insidious world government, I would suggest that pressure on non-consenting opinions be put carefully, to securely remove them form the normal mass Web, but not too strong as to push the normal users away from the (controlled) Web, to harder-to-control media. One way to achieve this is to allow some mild fringe content, and actively demonize any serious non-consenters, so that they'd look way off the chart to general public, thus "worthy" of being censored out.
*/
But more to the point, being forced onto Dat or IPFS is equivalent to being erased, given that nobody would know how to find or access the new location (Google doesn't index such net spaces).
> being forced onto Dat or IPFS is equivalent to being erased
Yes, for now it is! It's a wild frontier without amenities for a normal netizen, such as a decent search engine. So the point of censorship is to force every important non-consenter to that wilderness without having enough other people to go there and civilize it, as they civilized the web, the online music access, etc.
What you're talking about is the service providers themselves deciding what form of speech is allowed on platforms they own. Some may feel that it's inappropriate for Microsoft not extend their platform to white supremacists. Others may think it's inappropriate for service providers not to provide extend their platform to ISIS or Al Qaeda. You may feel that service providers should provide a voice to any possible opinion, but the organizations actually providing the service don't feel this way.
AWS is a private hosting company, and they may be exposed to legal or authority action based on what their clients host. It seems a lot like the Facebook arguments to me.
If you want to obligate them to support free speech, I think they need to be regulated as carriers otherwise it's not a reasonable standard to hold a private entity to. At least there is more competition in the hosting space than there is for Facebook.
Maybe this is an argument for regulation, but I don't think it's an argument for finger wagging. Either there is some sort of enforcement, or we acknowledge there are alternatives.
I'm not sure that I would conflate running a business with loving censorship.
> I can't believe the tech press isn't picking up on a supposed cloud provider threatening to shut down someone's account unless they make their website behave in a particular way.
What would the headline be exactly? "Business drops client for violating agreement and bringing negative attention to their service."
Why does everyone assume that businesses have a moral obligation or imperative? When a company goes around saying "We value..." they're really saying "By uttering the magic phrase we hope to make more money off you".
? It was widely reported.
One mistake we make frequently as tech people is trying to solve human relationship problems with a technology fixes. Censorship has existed for 10,000+ years; encrypted s night isn't going to magically fix it. There isn't an easy answer, just the hard path educate everyone.
Requiring encrypted sni will only mean the little influence thought leaders have in censored countries will be blotted our and replaced with state-run companies.
MITM proxies are a necessary evil, unfortunately, but the internet giants aren't doing a good job letting clients know when their TLS is being intercepted, so we're failing hard on education right now.
Also the makers of the commercial MITM proxies do a terrible job of staying current on TLS specs. This is likely in part due to customers being unwilling to install patches that cause a service interruption, so that should be taken into the design of said devices.
Regimes are completely willing to block large chunks of the internet if they can't do targeted blocks. And cloud providers aren't particularly interested in using their customers as collateral.
I expect surveillance prone regimes to just block anything with encrypted SNI.
They are too scared of their main website being blocked at ISP's just because your small site uses their servers as a domain front.
Some people were working on encrypted SNI during TLS 1.3's development, so that TLS could encrypt server names sort of like how it encrypts all later traffic. Encrypted SNI didn't make it into TLS 1.3.
1. Have a big SAN cert with lots of names.
2. Use SNI to select the correct certificate for that client and route to the correct customer config (and therefore correct origin)
If SNI didn't exist we'd be back to the bad old days of every TLS site requiring a dedicated IP. As ipv4 exhaustion has gotten worse this has gotten more expensive. However if we're using ipv6 then hosting N listeners for N ip addresses, each with their own dedicated cert, is much more scalable.
https://www.gov.uk/government/uploads/system/uploads/attachm...
That's the UK government explaining how it's going to enforce a worldwide requirement for Age Verification on all sites with (what it considers to be) pornographic material.
Now regardless of whether you think this policy goal makes any actual sense, or whether a potential regulator would even try to do more than clamp down on UK porn companies that don't do age verification, the mechanism described has two halves to it:
1. UK ISPs voluntarily block non-complaint sites in DNS
2. Hopefully everybody uses their ISP's DNS servers
Why doesn't it say the UK government will make every ISP run all connections through a government-owned proxy to enforce these rules regardless of DNS? Because that would cost an eye-watering amount of money and "We had to raise taxes by 10% for our anti-pornography law" is a guaranteed vote loser. It would also be ineffective but let's see them spend that money first.
The reason is that the law is only a political battle. Once the battle and the marketing are over non of this law or how it is or is not implemented. At best you get a bunch of bureaucrats in place that monitor these things and write a report every so often. Those will be ignored until some politician is again interested in fighting this battle.
It is nothing to do with censorship where the actual source is removed, as with the right to be forgotten and DMCA takedowns.
At the moment it is possible to MITM proxy (without the possibility decryption) to inspect the SNI and determine if the host is allowed, and if so the proxy does its own IP resolution and transparently proxies/forwards the TCP traffic. Ie it never engages in the TLS session. This is useful for restricting access from a LAN to services hosted on large cloud provides like AWS, GCP, etc where fixed IPs are not available (well, the third party service/website elects to use a CDN/load balancer/etc without regard to the full security impact).
A good example is PCI DSS and the payment card LAN. You should firewall and lock down so devices can only communicate with necessary services. Along with actual payment services, these LANs often need to allow access out to third party loyalty systems, digital receipt systems, etc that are cloud based.
With Encrypted SNI this won’t be possible to do securely anymore. A full MITM TLS decrypting proxy with explicitly configure clients will be required to ensure the encrypted SNI isn’t changed to a malicous host to eg upload captured payment data to. That’s a lot more overhead both in:
1. Configuring clients to use a proxy and custom CA (let’s hope all the various third parties apps support proxy setup and custom CAs, and no cert pinning!) 2. Running a proxy that now it has to do full decryption and encryption (to make sure you aren’t messing with the SNI and going to a host you shouldn’t).
Of course I don’t expect businesses to these lengths until there has been a serious breach exploiting encrypted SNI. Even then I don’t know which side will take action (or if neither side will)— merchants installing MITM proxies (unlikely), or third party service providers ditching load balancers and sticking to fixed IPs on their cloud hosts (less unlikely).
Given a malicious actor can register any old domain and get a cert for it very easily, I'm not sure what particular threat blocking TLS connections based just on the SNI is actually protecting you from.
The previous iteration of backside covering pondered the unencrypted server certificate, on the rationale that if this is a bad guy why do they have a good guy's certificate.
If you know any cryptography, you are now thinking "But, wait, how does that secure anything?" but you aren't the target customer. The target customer verifies that this blocks them from accessing a "Bad" site in Internet Explorer and they're happy to part with $$ instead of the $$$ it would cost to do full blown HTTPS proxy for every connection.
In TLS 1.3 this server certificate is encrypted. So the (perhaps slightly more untrustworthy) client SNI is pondered instead.
What middlebox vendors would prefer not to mention is that in many cases they also figured TLS re-connections are always safe and can be allowed through. After all, if they didn't let bad guys make the original connection, how could those bad guys re-connect? TLS 1.3 exploited this to be "backward compatible" with such crapware, it says all its connections are "reconnections" so they pass through unmolested...
You can’t tell all these small businesses they can’t take card payments, and you can’t make an already tough job harder, more complex and more expensive without an associated drop in compliance.
There may be some mildly masochistic tiny businesses that choose to process / store payment details on their own networks and try to manage all the controls needed for that, but in the presence of so many options for outsourcing the problem, this doesn't seem like a particularly rational decision.
> You can’t tell all these small businesses they can’t take card payments, and you can’t make an already tough job harder, more complex and more expensive without an associated drop in compliance.
This is only true if there are no sane alternatives.
[1] https://www.pcisecuritystandards.org/documents/PCI-DSS-v3_2_...
Square on the other hand does let you outsource the entire problem of physical card payments to them, at the cost of much higher fees, as they are the merchant of record so you don’t need to be PCI compliant at all. Which is a real worry as that doesn’t give me much confidence when buying from a square “seller”.
Their card reader originally didn’t encrypt data, and at least one model that did encrypt could be bypassed via tampering https://www.zdnet.com/article/square-reader-to-card-skimmer-... and while their current hardware may or may not have issues, they display a distinct lack of concern for local device security. Defense in depth is the way to go, but with Square you can put your Android/iOS device onto any WiFi network and without any security on who else is on it. Likewise you can download any random app that may look innocent enough but is full of exploits (eg an app that claims to help you manage a customer mailing list so you can grab signups on the same device as you take payments, or an app that claims to help with inventory levels, etc).
Only services necessary for the business should be allowed in/out. If the service can’t be firewalled by simple IP:port then you are left with having to use a proxy to enforce the access control.
The "full MITM proxy" you mention is, and always has been, the only defined way to make this work. The cheaper, half-arsed solutions you describe earlier cause everybody else pain (socialising costs while privatizing profit) and often don't actually deliver any meaningful security, they're just theatre.
Corporate TLS Middleboxes are the TSA screening of the Internet's security. Everybody knows they're there, everybody complains at the inconvenience, everybody ends up paying the price indirectly, and they claim they're very effective. But independent measures suggest they're basically entirely pointless.
Inspecting SNI is ineffective against the majority of threats including blocking botnet traffic.
I'll base my response on your description of how you think this device would work rather than your confusing term "MITM (non-decrypting) proxy".
A1. Alice sends a TCP SYN to 1.2.3.4 port 443 Presumably you intercept this, and synthesise the appropriate SYN-ACK pretending to be from 1.2.3.4 port 443 which Alice ACKs
A2. Alice sends an SSL/TLS ClientHello. It has some parameters you may not understand, and a SNI which says good.example which is on your whitelist
A3. You DNS lookup good.example, the response suggests 5.6.7.8, so you TCP connect to port 443 of 5.6.7.8 and play back Alice's ClientHello and try to stitch things together in your NAT layer.
Meanwhile
B1. Bob sends a TCP SYN to 9.8.7.6 port 443 Presumably you intercept this, and synthesise the appropriate SYN-ACK pretending to be from 9.8.7.6 port 443 which Bob ACKs
B2. Bob sends an SSL/TLS ClientHello. It has some parameters you may not understand, and a SNI which says bad.example which is NOT on your whitelist
B3. You drop or reset Bob's connection, he cannot connect.
Commentary #1: With the imagined comprehensive whitelist AND a following tail wind this doesn't give you anything better than just whitelisting the IPs in a conventional Firewall. Why spend all this extra money? Why involve TLS at all? It's complicated, but what for?
Commentary #2: This ClientHello may not work when redirected to some other IP address. In reality there's a good chance you just cause a fallback and things are pointlessly slower, but in principle it may just not work at all.
I’ve also looked at other options, like dns based firewall rules that are populated by the firewall also being the local dns server and so is able to see the resolved IP(s), but if those IPs are to CloudFront etc then it would be granting access to everything else also hosted by CloudFront etc.
TLS SNI is the only way of knowing where the client is trying to reach — short of the expensive and difficult to deploy explicit/non-transparent HTTPS proxy.
Re commentary #2, since all the TLS traffic is going through the proxy, the original request and any subsequent requests would go to the same IP each time.
TLS SNI does NOT tell you where the client was trying to reach, you've made a classic security mistake of assuming bad guys are honest. Honest people will truthfully write good.example and be allowed past, bad guys will dishonestly write good.example, and thereby connect to bad.example on the same IP address and laugh at your ridiculous "security".
Caching all DNS answers for some indeterminate amount of time makes your security story worse, but even if you do this the worst case stands, ClientHello isn't required to work if you do this. It may work today, in fact it probably does, but it may break with no notice, and it'll be your fault.
For other services that use dedicated IPs but spin up/down machines based on load etc it is still much more useful and secure than running a proxy with a CA that generates fake certificates, especially when you can’t update the trust root of the client device (often the case with embedded devices and those that are managed by the third party service provider)
You're back to seeing SNI requests for cdn12345.catpics.com which happens to be the same as command-and-control.suspicious-site.kp
Also, botnets uses legitimate services to rely C&C traffic. Forums, pastebins, github gits, IRC and email gateways, VMs on AWS and other cloud services...
That mechanism is well established, if only by these governments previously being unable to just ban internet access outright, even though it was universally perceived as a threat to their control on the flow of information.
This sounds inaccurate to me. If encrypted SNI is applied, the middleman should not be able to figure out which domain you are connecting to, without interrupting the connection. Domain fronting is a technique for prior TLS which you had to disguise the hostname.
It was a desirable feature, but it wasn't delivered even for the final drafts at the top of this year, let alone back in 2016 when TLS 1.3 was originally thought to be finished.
The TLS Working Group is going to adopt it (consensus at IETF 102 and on the mailing list was to adopt) but there's a LOT of work needed before Rescorla's rough sketch turns into something you'd want to actually deploy to millions of users.
Here's the email about adopting (Joe is one of the WG chairs) Rescorla's draft.
https://www.ietf.org/mail-archive/web/tls/current/msg26842.h...
Note that this is nowhere close to a finished feature. They're not sure whether to do DNS TXT records, whether this should live in a SRV record, some new DNS record (DNS Ops doesn't like TXT, but real world DNS services often don't have fancy new records for years because they're crap). They're not even sure if this should be two documents (one about DNS, one about how you use the keys which you presumably got from DNS) or just one.
Because TLS 1.3 doesn't always (today never) encrypt SNI, a middleman could just insist on refusing connections with encrypted SNI. This becomes a staring contest - do the browsers deploy this anyway, and risk losing customers in places where governments have deployed a technology to prohibit it, or do they blink and hide it in some "Privacy" feature no ordinary users will ever enable.
Is there an official word from Microsoft that they allow it or just "they didn't ban it yet"?
There is no technical solution that can prevent censorship. Censorship is a social issue. If a government policy, or the policy of a privately held corporation, insists on censoring something, it will do so.
Literally the only way a transport protocol could end censorship is if a law were enacted that specifically stated "This protocol may not be circumvented or obstructed by any party, private or public, by any means, for the purpose of censorship.".
Isn't this (Encrypted SNI) was the one been extensively discussed here: https://news.ycombinator.com/item?id=17538390 ?
This is great. I hope CDNs like Cloudflare etc deploy it ASAP. Also, deprecate previous TLS versions as ASAP so it can be more effective.
This article is premature?
Why is the assumption that when given a "binary choice", entities like China, EU, etc would give in to tech companies? Especially when these companies so easily succumbed to US government/media pressure at home where we have a strong tradition of free speech? When a binary choice is created, it's the companies that have given in, not the state.
Why are these tech companies being portrayed as being on the side of "good", while nations are portrayed as being on the side of "bad". The idea that AMZN, GOOG and MSFT have chinese, european or anyone else's best interest at heart while the PRC, EU or any other state doesn't. Did the british east india company have india's best interest at heart compared to mughal india? Considering how suspiciously we view foreign companies ( especially chinese tech companies ), it's odd that we view our own so highly.
But I don't think Google is evil, in the sense of doing bad things because they're bad. At a low resolution, I think it responds to incentives and tries to make as much money as it can get away with. At a higher resolution, it's made up of a lot of people and smaller groups that each have their own incentives to follow, and whose goals don't exactly line up with Google's.
Fighting censorship is nice for PR, supporting censorship is bad for PR. Some (not all!) ways of supporting censorship might help make more money, but good PR also helps make more money, so it's a trade-off. Drawing attention to Google's ability to fight censorship slightly shifts that trade-off.
But not all of Google's decisions are made centrally. Many (almost all, I would guess) people in Google are well-meaning, and I expect they can get away with making good decisions a lot of the time. The people working on TLS probably aren't individually pro-censorship just because they work for Google, which means they may not make pro-censorship decisions unless specifically pressured to.