More Privacy, Less Latency – Improved Handshakes in TLS v1.3 | Hacker News Reader

More Privacy, Less Latency – Improved Handshakes in TLS v1.3

timtaubert.de

81 pointsttaubert18 comments

0rtt is going to make a huge perceived difference on high latency (mobile) links. Don't forget however that the syn/ack tcp connection setup also still has an additional 1rtt overhead. For this reason, I'm still rooting for Google's QUIC to get towards standardization and mainstream adoption.

QUIC is indeed nice. As a Chinese who frequently browses Google with a VPN and therefore high latency, the difference between loading Google in Chrome and in other browsers is palpable.

But I have not seen any adoption of QUIC either in clients or servers, outside the Google's circle.

I'm hoping once QUIC matures that Google will release some open source Apache / nginx modules to support it. Development without any commercial incentive seems to happen very slowly otherwise.

Regarding more privacy: have they found a way to keep the SNI information private?

SNI is the "server_name" extension in the ClientHello message, which is not encrypted. So no, looks like there are no changes to this in TLS 1.3.

Theoretically it could be possible to encrypt it (using DHE) before server validation occurs (i.e. before the server's RSA certificate is needed). However, it would rigorously change the protocol and I can imagine it would make some load balancing applications a lot more complicated as well.

Not to mention not compatible with TLS 1.2 and older.

I don't think this is possible. I can have different TLS configs for each vhost I set up on a single HTTP instance. And until the SNI is sent the server has no way of knowing which vhost to use.

Also SNI needs to match the hostname specified in the X.509 part of the cert. Certs are issued based on DNS names which need to correspond to SNI.

I'm not sure how much hiding the SNI would get you in terms of privacy. You could always just look at the destination IP address of the packet.

> I'm not sure how much hiding the SNI would get you in terms of privacy. You could always just look at the destination IP address of the packet.

Destination IP will be the same for all sites on the server, SNI tells you exactly which site was asked for. Not meaning to be pedantic, sometimes the distinction isn't clear.

But in order to encrypt the SNI name, you'd first need to verify a certificate tied to a bare IP address. You'd also need to trust DNS completely. RTT would inflate significantly.

The CA system is a mess, but DNS is worse. Tying certs to bare IPs would create a deployment nightmare as well.

SNI is imperfect, but it is a big improvement over the previous status quo, which was single-IP per https host, which obviously did nothing to obscure the site hostname either.

> But in order to encrypt the SNI name, you'd first need to verify a certificate tied to a bare IP address.

Why wouldn't a DH exchange be enough?

You're right, DH might be enough, depending on goals.

The DH exchange would be MITMable, but not passively collectable. TLS is (ideally) neither, so DH wouldn't provide an equal level of privacy.

Still, it would be a beneficial extension of the protocol. At the cost of an additional TCP RT.

Right, however, the MITM attack would also come at the cost of causing the rest of the connection to fail. You could also do fun stuff like sending the sha256-mac of the hostname using the DH key as the MAC key. There are lots of fun ideas!

> You could always just look at the destination IP address of the packet.

For CDN services like cloudflare I'd imagine that it would make more of an impact, since in that case an IP address could potentially match many host names. Of course that has its own downsides - most notably the fact that you'd need to trust them with the server's private key.

I'm wondering if the 0-RTT mode brings any issues with DDoS attacks. Since the request is sent in the initial TLS request, the server must buffer it, or create a response before it finishes the handshake. Admittedly it's not UDP, so you still need to successfully perform a TCP handshake (ie: verify the reverse path).

Wouldn't proper application design just wait to read the actual content / request from the socket? As in, this will most likely be buffered somewhere in the kernel TCP stack, and not in the application, making the situation comparable to 1rtt from a DoS perspective.

Where is "somewhere", the kernel only has a finite amount of memory. It's still a denial of service, whether it occurs in the kernel, or a user-space program. The point is that in order to service legitimate clients, the initial request must be buffered somewhere.

For the 1rtt case, the request isn't sent till the TLS connection has been established. The attackers would have to keep track of these TLS connections, so this doesn't seem like a DoS vector.

For 0rtt the attackers might not need to keep track of state, allowing them to simply send TLS 1.3 requests, and overload the server's memory. My question is whether this is a legitimate concern.

Reply on news.ycombinator.com