Implementing TLS Encrypted Client Hello [Nov 2021] | Hacker News Reader

Implementing TLS Encrypted Client Hello [Nov 2021]

guardianproject.info

40 pointsxrisk18 comments

So, to summarize, one of the remaining issues on the Web is that when you browse to an HTTPS site the name of the site you are connecting to is still in cleartext. The reason for this is that you regularly have 1 IP address with multiple Web sites on it. The server needs to know which Web site to forward your request to. Once it has forwarded your request the SSL cert of that site takes over and all future requests are encrypted.

Encrypted Client Hello would install a server-wide certificate that would encrypt the data from the first connection so that the handshake wouldn't be visible to the outside.

The best a MITM could do is determine that you are connecting to a specific IP but would not be able to determine which site on that IP you are browsing.

DNS is still a thing but there are at least decent widely deployed solutions.

And the two most popular ways to encrypt DNS queries rely on TLS (DNS over TLS and DNS over HTTPS).

Encrypted DNS just resolves a name to an IP. My browser still has to connect to the IP of the web server.

I am looking forward to this being supported officially in the mentioned daemons. The authors should also work with Qualys [1a][1b] development site and open source developers [2] that test TLS configurations to add additional tests early on.

[1a] - https://www.ssllabs.com/ssltest/

[1b] - https://dev.ssllabs.com/ssltest/

[2] - https://github.com/drwetter/testssl.sh.git

Am I correct in assuming that this is going to be mostly impactful on the server side for at-risk services that are at risk of getting blocked using SNI fingerprinting?

Since browsers will get adoption easily, but servers will need to make changes, wondering which operators will have the right incentives to upgrade to ECH, especially since it’s much more involved than usual TLS upgrades.

The incentive could be as simple as ssllabs not handing out an A or A+ score if your site doesn't support encrypted hello. I've heard of several huge companies that base the security rating of their websites in part in getting a good score on the ssllabs test, so they and their vendors would need to move once the test changes.

I don't think it's healthy to rely on an arbitrary test like that for your company contracts, but it's what's happening. Once the feature is stable in server and client software, I'm sure it'll become part of the test and many big companies with complicated contracts will rush to implement it.

There are some companies that I expect will be early adopters, namely companies that are sensitive in nature. Porn, specific medical websites, you name it. With proxied DoH and encrypted SNI you can set up a connection to a website privately and securely without ever naming it in plain text. If that website runs behind a big cloud host like Cloudflare, there's no way for your ISP or any other passively spying company to know what you're up to.

As with TLS 1.3 itself, a big benefit is that the Inner encrypted Hello can't be inspected by whatever (inevitably poorly made and never updated) middleboxes are on the route between client and server.

It isn't important to the Internet whether these middle boxes are put there by the Government of the People's Republic of China to promote Harmony, by your daughters $1000 per month private school to prevent her looking at "inappropriate" material (whether that's the 1619 project, TikTok, or porn) or your employer to dissuade employees from uploading PDFs of company secrets, the problem and the solution is the same from the Internet's point of view.

Did you know that TLS certificate compression is an obvious, trivial improvement to the rapidity of secured connections that could not be deployed for over a decade because until TLS 1.3 the Certificate message is cleartext and so if you send one that looks "wrong" to some dodgy middlebox firmware written in 2006 your web site doesn't work?

Whenever the purpose of bypassing middleboxes is explained, there are people who are outraged. How dare we fix the Internet? They were relying on FaultySoft CrapSecurity 0.0.1 from 2006 and now we've ruined everything by bypassing it. No we didn't, by definition if what we did worked, your middlebox already wasn't protecting you. We've shattered your illusion and that's all. Santa Claus isn't real either.

Isn't DNS filter easier than SNI-based blocking?

Only until all devices are using DoH. Your TV manufacturer isn’t going to give you an opt out switch for the modern network protocols that guarantee users can’t block ads and tracking.

yes it is, but it is also less effective, since users can easily use DNS over TLS to get around these measures. With SNI based blocking their only choice is proxying/VPNing which is much harder and less accessible.

You mean quad nine? How difficult it is to block? That's literally one rule in the firewall.

> How dare we fix the Internet?

Fix it for who? We’re not far off from completely locked down devices, at least on mobile, where the last few options for ad (and tracking) blocking are being “fixed” in the sense they’re being removed.

Everything will eventually use DoH, ECH, and CDN IPs and it’ll be impossible to distinguish content from ads and tracking. I wouldn’t be surprised if browsers eventually stop letting addons see hostnames due to “privacy concerns”. At that point we’ll have unstoppable ads and tracking everywhere.

Other than leaking IP addresses, is this the final step in not requiring a VPN?

No. This is the final step in preventing blocking ads and tracking in mobile apps. If anything it makes the use of a VPN more appealing IMO.

I'm confused, how would this make blocking ads harder? You can still make domains not resolve by changing your DNS resolver (which you control), but it stop my pesky ISP from blocking my access to a site.

Yup, don't see any downsides either. I bet many technical people don't even know that https does actually leak domains via SNI, great that they finally patch it up!

Regarding parent's comment: is ad blocking based on domains listed in SNI really a thing?

I think apps on mobile will start using DoH instead of respecting local network settings. The next logical step would be to sniff SNI on a proxy, but this will remove that ability too.

Unless Google/Apple ban apps from ignoring system DNS settings, I think it's reasonable to assume most apps will start querying DoH servers directly.

Reply on news.ycombinator.com