2 ms·
The author states: >"Eight years later, everyone in the business seems keen to point out that TLS version 1.3 will finally address this issue by encrypting ses
by bogomipz 8y ago
The author states:
>"Eight years later, everyone in the business seems keen to point out that TLS version 1.3 will finally address this issue by encrypting session data, although it isn't obvious if the measures taken by IETF actually work."
Can someone say why it not yet if the measure taken by the IETF in TLS 1.3 work? Is it simply that this part of the spec hasn't been finalized yet? Or does the author mean something else?
- toast0 8y agoSo, TLS 1.2 servers offer session identifiers in cleartext and client resumption sends them in cleartext also. Which probably means someone watching lots of traffic to Google can correlate users even as they move across ips. TLS 1.3 servers send the session identifiers encrypted to the client, and then the client sends it back in cleartext, but each successful handshake will generate a new identifier; a passive observer will not be able to correlate sessions -- except for retries, but the service owner still could. In TLS 1.3, the server can establish a session ticket any time after the handshake is complete, so conceivably, the server could wait until it had some idea of who you are, and establish a token then which contains your userid. (Anyway, it could always associate a random session id with your userid later)
- bogomipz 8y agoThanks for the clear explanation. Would it not have been more accurate for the author to have stated then that "the measures taken by the IETF in TLS 1.3 will work, although with some caveats"?
- toast0 8y agoI must admit that I had only skimmed the article, and hadn't read the bit about TLS 1.3, until after it was edited. I agree with what it says now :D