4 ms·

Introducing TLS 1.3

40 points by samber 10y ago

colmmacc 10y ago
TLS 1.3 is still an evolving draft, and who knows what may change before it is standardized, but so far it does have some long-overdue simplifications to TLS. My favorite is that session resumption has been merged with pre-shared-key (PSK) mode, since really they are the same thing; that's a genius idea that is a good example of reducing the surface area for mistakes or attacks. But (of course there was a but coming) ... the new 0-RTT mode seems like a bad idea, and I think it will come to be a really weak spot, and where many practical attacks will show up; which is unfortunate. Quick primer: 0-RTT data is where the client can send data to the sever from the get-go, as long as the client and server have communicated before. The data is sent by the client effectively /while/ the handshake is happening. The server might discard that data, because it might not have the decryption key used any more, and the client would have to resend it in this case. But the real idea is that the client can send the requests it wants and the server can get a head-start on building the responses while the handshake is happening. It speeds things up. For most cases this mode will actually be "1 RTT", because a TCP connection still needs to be established and that costs 1-RTT without fast-open, but TLS won't be adding a round trip. One problem is that a mixed mode handshake where data can come in while the handshake is happening complicates already brittle state machines in the TLS libraries, and I bet we'll see vulnerabilities there similar to the change_cipher_spec vulns that hit some TLS implementations, but the real issue is more fundamental and is mentioned in the draft itself ... IMPORTANT NOTE: The security properties for 0-RTT data (regardless of the cipher suite) are weaker than those for other kinds of TLS data. Specifically. The short of it is that the 0-RTT data doesn't get Forward Secrecy, and it isn't protected against replay. Losing forward secrecy seems like a big loss, because 0-RTT is where passwords, authentication tokens, and credit card numbers are likely to be; many real-world requests need these things and developers will put them there. So the most sensitive data ends up with the weakest secrecy. But replay-ability is a bigger concern. Making a request pattern truly idempotent is very very hard; even the smartest developers often mess it up. So if an attacker, and I mean someone using the same wifi hotspot, can grab your request data and replay it who knows what's happening; simple attacks are things like exhausting your server-side throttle limits and creating a DoS that locks the client out, or causing you to be charged multiple times if the request is something you pay for. Slightly more complicated attacks may be observing side-effects of what happens when a request is replayed to derive information about that request. For example if the server primes a cache based your request, I could replay it and probe what items have now been cached. Now I can determine what your request was for. Servers can put mitigations in place; like they can keep a log of all 0-RTT data and make sure it's never duplicated, but to do this robustly requires transactions (distributed ones if it's a distributed system, like a CDN) and it's the kind of thing many will punt on. There are other ideas like time-windowing, similar to the kind of windowing DTLS permits, but those too have a history of error and vulnerability, and may not be practical. All while leaving 0-RTT there as a very tempting way to save some speed.

40 points by samber 10y ago

TLS 1.3 is still an evolving draft, and who knows what may change before it is standardized, but so far it does have some long-overdue simplifications to TLS. My favorite is that session resumption has been merged with pre-shared-key (PSK) mode, since really they are the same thing; that's a genius idea that is a good example of reducing the surface area for mistakes or attacks. But (of course there was a but coming) ... the new 0-RTT mode seems like a bad idea, and I think it will come to be a really weak spot, and where many practical attacks will show up; which is unfortunate. Quick primer: 0-RTT data is where the client can send data to the sever from the get-go, as long as the client and server have communicated before. The data is sent by the client effectively /while/ the handshake is happening. The server might discard that data, because it might not have the decryption key used any more, and the client would have to resend it in this case. But the real idea is that the client can send the requests it wants and the server can get a head-start on building the responses while the handshake is happening. It speeds things up. For most cases this mode will actually be "1 RTT", because a TCP connection still needs to be established and that costs 1-RTT without fast-open, but TLS won't be adding a round trip. One problem is that a mixed mode handshake where data can come in while the handshake is happening complicates already brittle state machines in the TLS libraries, and I bet we'll see vulnerabilities there similar to the change_cipher_spec vulns that hit some TLS implementations, but the real issue is more fundamental and is mentioned in the draft itself ... IMPORTANT NOTE: The security properties for 0-RTT data (regardless of the cipher suite) are weaker than those for other kinds of TLS data. Specifically. The short of it is that the 0-RTT data doesn't get Forward Secrecy, and it isn't protected against replay. Losing forward secrecy seems like a big loss, because 0-RTT is where passwords, authentication tokens, and credit card numbers are likely to be; many real-world requests need these things and developers will put them there. So the most sensitive data ends up with the weakest secrecy. But replay-ability is a bigger concern. Making a request pattern truly idempotent is very very hard; even the smartest developers often mess it up. So if an attacker, and I mean someone using the same wifi hotspot, can grab your request data and replay it who knows what's happening; simple attacks are things like exhausting your server-side throttle limits and creating a DoS that locks the client out, or causing you to be charged multiple times if the request is something you pay for. Slightly more complicated attacks may be observing side-effects of what happens when a request is replayed to derive information about that request. For example if the server primes a cache based your request, I could replay it and probe what items have now been cached. Now I can determine what your request was for. Servers can put mitigations in place; like they can keep a log of all 0-RTT data and make sure it's never duplicated, but to do this robustly requires transactions (distributed ones if it's a distributed system, like a CDN) and it's the kind of thing many will punt on. There are other ideas like time-windowing, similar to the kind of windowing DTLS permits, but those too have a history of error and vulnerability, and may not be practical. All while leaving 0-RTT there as a very tempting way to save some speed.