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.
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 -
.... 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.
1 reply 0 retweets 24 likesShow 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
1 reply 0 retweets 28 likesShow 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?
2 replies 4 retweets 31 likesShow 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.
7 replies 24 retweets 81 likesShow this thread
Here's my advice: Just don't use 0-RTT, ever. As a client, pretend it doesn't exist. Always perform stateless connection opening. Bonus: you get to skip implementing it, don't have to worry about that bug surface.
-
-
Replying to @RichFelker
That's a "Security First, Performance Never" kind of position though. We can do both if we push for it! At the speed of light it's 130ms RTT between Madrid and Wellington. Why should it take 260ms just to say hello? That's very noticeable delay.
1 reply 0 retweets 0 likes -
Replying to @colmmacc
You realizes these sites have delays longer than that in their internal APIs due to misconfigured search & ndots in their resolv.confs, right? ;-)
0 replies 0 retweets 0 likes
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.