More Privacy, Less Latency – Improved Handshakes in TLS v1.3 • Hacker News Board

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

#21

Post by quesera » Thu, Nov 19, 2015, 1:33 AM UTC

jimktrains2 wrote: post #20

quesera wrote: post #17

Earlier quoted context omitted.

> 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 a…

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

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

#22

Post by keeperofdakeys » Thu, Nov 19, 2015, 8:32 AM UTC

stingraycharles wrote: post #14

keeperofdakeys wrote: post #10

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.

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

#23

Post by jimktrains2 » Thu, Nov 19, 2015, 7:21 PM UTC

quesera wrote: post #21

jimktrains2 wrote: post #20

Earlier quoted context omitted.

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