Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TLS 1.3 Is an Opportunity for Amazon, Google and Microsoft to End Censorship

privateinternetaccess.com

Post reply on HN
Print view View original

11–20 of 102 posts

Re: TLS 1.3 Is an Opportunity for Amazon, Google and Microsoft to End Censorship

#11

Post by tialaramex »

ishitatsuyuki wrote: post #8

> If Google Cloud, Amazon Web Services, and Microsoft Azure allow domain fronting with TLS 1.3, censorship countries like China are faced with a binary choice. 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 hostna…

Encrypted SNI isn't a feature of TLS 1.3. The article never outright says that it is, but it manages to give that impression.

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.

Re: TLS 1.3 Is an Opportunity for Amazon, Google and Microsoft to End Censorship

#12

Post by yardstick »

Encrypted SNI is great for individual privacy but terrible for business/corporate security.

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

Re: TLS 1.3 Is an Opportunity for Amazon, Google and Microsoft to End Censorship

#13

Post by DanielGee »

Why is the assumption always that AMZN, GOOG and MSFT doesn't want censorship? Especially when they have taken to censorship like duck to water.

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.

Re: TLS 1.3 Is an Opportunity for Amazon, Google and Microsoft to End Censorship

#14

Post by growse »

yardstick wrote: post #12

Encrypted SNI is great for individual privacy but terrible for business/corporate security. 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…

Aren't businesses that are serious about meeting their legal/regulatory obligations for controlling internet access already using full MITM TLS interception with their own CAs?

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.

Re: TLS 1.3 Is an Opportunity for Amazon, Google and Microsoft to End Censorship

#16

Post by pimmen »

vbezhenar wrote: post #2

I'm sure that many countries will block Amazon, Google and whatever else if needed. It won't end censorship, it would make life of ordinary people there even harder.

But, if they do, they have a tougher sell. They might get away with ”we’re just protecting you from certain sites we deem harmful, and we’re thorough with your best interests in mind” when they block specific sites. It requires a far more gullible public to pull that off if it’s more than half the Internet.

Re: TLS 1.3 Is an Opportunity for Amazon, Google and Microsoft to End Censorship

#17

Post by tialaramex »

yardstick wrote: post #12

Encrypted SNI is great for individual privacy but terrible for business/corporate security. 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…

No, it makes no practical difference to "business/corporate security" but it's terrible for lazy and incompetent people who wanted to look as though they were effective.

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.

Re: TLS 1.3 Is an Opportunity for Amazon, Google and Microsoft to End Censorship

#18

Post by gnode »

Crontab wrote: post #10

Seeing how search results are being censored in “free countries” due to things like the DMCA and The Right To Be Forgotten, maybe we shouldn’t look to private companies to fix this issue.

As far as I know, there is no law in Western countries prohibiting domain fronting, so it's not really comparable. What's probably more relevant is Google changing its mind, and deciding it wants to run a censored mainland Chinese service.

Re: TLS 1.3 Is an Opportunity for Amazon, Google and Microsoft to End Censorship

#19

Post by eeZah7Ux »

yardstick wrote: post #12

Encrypted SNI is great for individual privacy but terrible for business/corporate security. 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…

Absolutely not. Full MITM proxies are required to inspect traffic.

Inspecting SNI is ineffective against the majority of threats including blocking botnet traffic.

Re: TLS 1.3 Is an Opportunity for Amazon, Google and Microsoft to End Censorship

#20

Post by tialaramex »

growse wrote: post #14
yardstick wrote: post #12

Encrypted SNI is great for individual privacy but terrible for business/corporate security. 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…

Aren't businesses that are serious about meeting their legal/regulatory obligations for controlling internet access already using full MITM TLS interception with their own CAs? 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.

Backside covering at the cheapest possible price is the goal. It's not about whether it achieves the regulatory goal, just whether it gets a check on the list.

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

Post reply on HN