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".
2 replies 2 retweets 47 likesShow 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.
5 replies 4 retweets 52 likesShow 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.
1 reply 0 retweets 16 likesShow 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.
1 reply 0 retweets 28 likesShow 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".
1 reply 2 retweets 22 likesShow 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 ....
1 reply 0 retweets 27 likesShow 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!!!
2 replies 0 retweets 27 likesShow this thread -
Replying to @colmmacc
Can you expand on this point? Which key is only used once, and how do you get 0rtt on future requests if the key is deleted? Got a good article that dives into this?
1 reply 0 retweets 1 like -
Replying to @jboeshart
Sure thing. So every TLS connection also mints a nice shiny resumption key, and there's an early data key. These can be used by the client to resume new connections, and encrypt 0-RTT data, respectively. Cont ...
1 reply 0 retweets 1 like
Rather than remembering these keys, it's common for TLS servers to envelope encrypt these keys with a Session Ticket Encryption Key (STEK) and then give it all to the client as an encrypted ticket. The client does most of the remembering, the server only remembers the STEK.
-
-
Replying to @colmmacc @jboeshart
This works, but isn't forward secret, anyone with the STEK can resume a session or decrypt or forge early data. We can fix this in TLS1.3 by having the server store the resumption and early data keys, and delete them as they are used. Also gives anti-replay.
1 reply 0 retweets 1 like -
Replying to @colmmacc @jboeshart
The cost is that the server has to spend the memory to store and retrieve the keys. But it's the only way we've found to do anti-replay and forward secrecy.
1 reply 0 retweets 1 like - 3 more replies
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.