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
Show 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.
Show this thread -
The other benefit is that all means we get something called forward secrecy. WHAT IS FORWARD SECRECY? It just means that if someone is listening in to our encrypted conversation, they can't decrypt it later even if they break into the client or server and get their keys.
Show this thread -
That's because of DIFFIE and HELLMAN, and it is insane and magic and a cool use of math. Anyway it works. O.k., the next thing that TLS1.3 does though is something called 0-RTT and it looks like this ... Client: Hey server, we've talked before, so I'm just going to talk again
Show this thread -
This is also cool, and magical, and it SAVES US FROM MORE SMALLTALK. But ... it's a little controversial. Why? Well I wrote a long thing, it's here; https://github.com/tlswg/tls13-spec/issues/1001 … , but this tweet thread is to save you from that ...
Show this thread -
It boils down to two things; the server has to know how to decrypt the client's conversation, which means it really needs to have the conversation key that's being used. Most servers do this by encrypting the conversation key with another key and asking the client to remember it.
Show this thread -
This blows, because it means that if the server is compromised, well now A LISTENER CAN DECRYPT THAT CONVERSATION. "Oh but only the very early part of the conversation" some people say ... well what's in that part of the conversation? Passwords, cookies, credit card numbers, Oh.
Show this thread -
"BUT THE SPEED IS WORTH IT!", well make your own mind up. Spoiler: it's not. Anyway, next problem: a listener can also repeat the encrypted conversation, and guess what? The server might just be ok with that and hear the same thing twice.
Show this thread -
So what? Well, what if that request you know ... cost money? Or what if a few hundreds of those requests lock you out of your account? TLS people have the answer ... WHAT WE NEED ARE SAFETY RULES. Let's only use 0-RTT for SAFE CONVERSATIONS.
Show this thread -
What makes a conversation safe? Well it has to be IDEMPOTENT. What does that mean? It means if you hear an order twice, that's safe, you only do it once. "Let x = 1" is idempotent. "x += 1" is not. O.k. easy, right?
Show this thread -
Well, not really, because LOTS AND LOTS of requests do things like "x += 1". Let's look at one ... suppose I call it https://myservice.me/x/add/1 . O.k. first problem: THIS IS AN ILLEGAL "GET" REQUEST AND THE HTTP POLICE ARE COMING TO MAKING ME USE "POST".
Show this thread -
Actually there are no HTTP POLICE, they don't exist, but "curl" does and people like using it, and so ordinary GET requests that make non-idempotent actions are super-super common. People even avoid query strings because bash screws them up. THERE ARE NO BASH POLICE EITHER.
Show this thread -
So I make this request, and it times out ... well fuck. Did it time out before or after adding one? Shit, what do I do? Oh I know, I'm going to query for the current value, and it's not what I expect, I'm going to go again.
Show this thread -
Welcome to basically how every distributed TRANSACTION PROTOCOL works, even things like PAXOS and RAFT and MULTI-PHASE COMMIT use waiting and polling sometimes. What they don't assume is that ... AT ANY MOMENT A MISCREANT ON THE NETWORK MIGHT JUST RESEND THE ORIGINAL MESSAGE.
Show this thread -
That would be CRAZY, because they USE TLS, and the S in TLS stands for "SECURITY" and that includes things like "THOU SHALT NOT MAKE MESSAGES REPLAYABLE".
Show this thread -
Now the TLS1.3 people are still like BUT WE WANT SPEED, SO JUST DEAL WITH IT. And the distributed systems people are like IDEMPOTENCY IS REALLY HARD, WE MEAN IT. But wait, it turns out that we can actually get anti-replay and forward secrecy back, and keep 0-RTT, how ....
Show this thread -
The answer is for the server not to use key-in-a-key BS. Instead if the server just remembers the key, let's a client use it ONCE, and deletes it when it's done ... we get FORWARD SECRECY and ANTI-REPLAY. REJOICE!!!
Show this thread -
.... except it costs the server money. It has to cache more keys, and it's not easy to distribute across wide geographic areas, and comes with its own distributed systems challenges. But guess what? THAT'S ALL THE TLS SERVER'S PROBLEM.
Show this thread -
... no need to modify thousands of applications, no need to teach PHP and RubyOnRails developers the intricacies of idempotency edge cases. Nope, just one slightly costly change within the TLS1.3 servers. So that's my plan, and REJOICE again, because TLS1.3 can have secure 0-RTT
Show this thread -
.... unless some TLS servers would cut corners, and just want the fast benchmarks, and you know .... deploy TLS1.3 0-RTT without built-in SAFETY mechanisms. That would be INSANE, I mean, why risk bugs and side-channels, right?
Show this thread -
Oh right, no that's exactly what's happening. So here's my advice: if you see a server supporting 0-RTT and that server doesn't give you an iron-clad guarantee that when the key is used, it's deleted, and that your EARLY CONVERSATION can't be repeated ... don't use it.
Show this thread -
Last message in the thread: no 0-RTT is not some NSA backdoor (Dear HN: grow up), there are no intentional back doors in TLS1.3, and it is still overall AWESOME AND EXCITING and we'll be adding it to s2n ... VERY SOON. EOF.
Show this thread
End of conversation
New conversation -
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.