O.k., so here's the deal; TLS1.3 is coming, very very soon now, A SHINY NEW RFC, and we can BEHOLD ITS GREATNESS, because it is AWESOME. Even with all its flaws, it is AWESOME and BETTER than TLS1.2 and everything before.
-
Show this thread
-
TLS1.3 fixes a really dumb mistake that we made in prior versions. Basically it used to work like this ... Client: How're you doing Mr Server? Server: I'm good, here's my key so that we can talk Client: Oh yeah, here's my key, let's talk
1 reply 3 retweets 29 likesShow this thread -
TLS1.3 now does this: Client: How're you doing Mr Server? Btw, here's my key so that we can talk Server: I'm good, here's my key, let's talk Look at that, ONE WHOLE PIECE OF SMALLTALK SAVED. That's the biggest benefit, basically, it's faster.
2 replies 11 retweets 82 likesShow this thread -
Replying to @colmmacc
I’m not terribly familiar with TLS, but my understanding was in 1.2 the client wanted the server’s key before it sent its own so it could validate the server before sending anything to guard against MITM In 1.3, if there is a MITM we sent our info w/o knowing
1 reply 0 retweets 0 likes -
Replying to @OkYouGotMe80 @colmmacc
My question, have we reached a point where clients are generating per-server TLS keys? Possibly per-connection keys? Otherwise the handshake optimization has reduced the security of the protocol in the sense we’re now giving away some information we guarded before.
1 reply 0 retweets 0 likes -
Replying to @OkYouGotMe80
In TLS1.3 every connection gets its own ephemeral key, even resumed one. The only data key re-use is for 0-RTT early data, if you do it the bad way. Sadly that’s also where the url, cookie, password, and other info goes.
1 reply 0 retweets 0 likes -
Replying to @colmmacc
And the ephemeral key is the key you are referencing in the conversation between server and client? Sorry if this is a stupid question
1 reply 0 retweets 0 likes -
Replying to @OkYouGotMe80
Definitely NOT A STUPID QUESTION :) There's a lot of keys floating around so it's confusing. I'll do my best be breaking down the 3 main session types ...
1 reply 0 retweets 0 likes -
Replying to @colmmacc @OkYouGotMe80
O.k., a "normal" session: 1. Client says hello, and includes a Diffie-Hellman keyshare 2. Server says hello back, with its own DH keyshare, signed by its RSA key. 3. Through the magic of DIFFIE and HELLMAN and MERKLE, the client and server derive an ephemeral conversation key.
2 replies 0 retweets 1 like -
Replying to @colmmacc @OkYouGotMe80
A "resumed" session is the same, but there's no RSA. Instead the server/client stashed away a resumption key. The client shows up and says "I HAVE THIS, CAN I USE IT?" and if the server agrees, it uses that key to authenticate itself. No RSA means it's faster, but we keep DH.
1 reply 0 retweets 0 likes
We keep DH because that means we keep Forward Secrecy. O.k., now 0-RTT, same as resumption, but the client/server also stashed away an early data key. The client shows up and just sends data encrypted with that key. No DH for that part of the conversation ...
-
-
Replying to @colmmacc @OkYouGotMe80
... but then once the DH is done, we transition to that key, so we get forward secrecy again. In practice it means that the first few KB of a 0-RTT session might be replay-able and might not have forward secrecy. This is the .... KEY POINT. *groan*.
0 replies 0 retweets 0 likesThanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.