News for hackers. Stuff that matters.
Re:GlobalSign: RSA-1024 leaf certificate issued after 2013-1... by londons_explore on Wednesday February 10, 2021 @11:38AM (#26091402)
> TLS 1.3's zero round trip resumption by its nature can't be bullet proof against repetition

The server side can easily keep track of which nonces have been used, and not allow any re-used nonces to have any side effects.

This can be implemented in something like spanner by keeping a database of valid nonces, and tying the marking a nonce as used to the other effects of the HTTP request in the same transaction. Spanners global-consistency will ensure only one transaction will commit. In most cases, the data can be sent back to the user without waiting for commit, preventing any cross-ocean latency penalty too.

It's a shame that I don't see a single HTTP/3 server which has any support for a scheme like this.

Re:GlobalSign: RSA-1024 leaf certificate issued after 2013-1... by tialaramex on Wednesday February 10, 2021 @09:15PM (#26097480)
Congratulations, you have joined many excellent engineers in designing a toy solution to this problem. Some of the others were documented in RFC 8446 (with TLS 1.3 itself) but if you didn't cheat by looking there yours was an independent invention.

Sadly this doesn't scale, as you almost seemed to realise by saying you'd just respond without waiting for the commit step to complete. Next I'll respond to your dismissal of this huge problem in the other thread.

Re:GlobalSign: RSA-1024 leaf certificate issued after 2013-1... by toast0 on Wednesday February 10, 2021 @11:54AM (#26091644)
That's possible, but not really easy. If you don't wait for the commit, you may process the request before getting the notification that it was a duplicate nonce; if you do wait for the commit, there goes your performance boost.

The right thing to do in my mind is to only send requests in 0-rtt if they're specifically flagged as eligible.

Re:GlobalSign: RSA-1024 leaf certificate issued after 2013-1... by londons_explore on Wednesday February 10, 2021 @04:43PM (#26095214)
> If you don't wait for the commit, you may process the request before getting the notification that it was a duplicate nonce.

Yes, do this. Processing the request isn't bad as long as it doesn't commit.

Most evil attackers won't come back to you complaining that your server gave back an HTTP200 response when it should have returned an HTTP400 because they'd reused a nonce.

Re:GlobalSign: RSA-1024 leaf certificate issued after 2013-1... by tialaramex on Wednesday February 10, 2021 @09:28PM (#26097543)
The evil attackers don't necessarily care whether in some sense your system "doesn't commit" one of the duplicates. Especially if they can manipulate it to choose whether the "not committed" one is the one they created or one emitted by a real user.

I know it was intended flippantly but the attackers do not get the HTTP response code - they're obliged to conduct this attack blind, if they can decrypt the messages then your problem isn't a replay attack but some previously unimagined TLS flaw.

So, suppose your system sees three versions of a transaction to transfer $1M to Dr Evil. You're not worried because two of them "won't commit" but do your end users understand that? (hint: they do not). Let's call these versions A, B and C. The real user's web browser believes transaction A succeeded, and is unaware of B and C.

Dr Evil complains that the money never arrived, and our user checks, alas they see that eventually transaction A failed (it was judged a duplicate of B, and so was C) and this explains the problem. They initiate a new transfer, let's call that Z. This succeeds and Dr Evil is satisfied.

Unfortunately now Dr Evil has $2M instead of $1M.