-
Notifications
You must be signed in to change notification settings - Fork 4
Description
Specification
There is an odd delay when cleaning up the QUICConnection
after a tls handshake error. After the client checks the server's certs and fails it, it sends the CC
frame to close the connection. for a RSA
cert the server enters draining and then the close state very quickly. But for a ed25519
cert the server processes the CC
frame, waits an odd 3-ish seconds using the timeout()
, onTimeout()
timing mechanism and then enters the close state.
I don't see a reason why this would behave differently for an ed25519
cert compared to an RSA
one. I've been over the internal logic and I think I'm handling all the events when and as intended. This 3 second delay is clearly being set after processing the CC
frame with recv()
on the server side AND doing processing a send()
. This is also after both sides have entered the draining state, so no new packets are going to be sent between them.
Unless this is intended behaviour for handshakes with ed25519
certs, I can only assume this is some kind of bug. I've posed an upstream issue for this at cloudflare/quiche#1488.
Additional context
- Related Handshake failure waits 3 seconds before connection closes. cloudflare/quiche#1488
- Related Graceful connection failure for failed TLS handshake #9
Tasks
- Determine the cause of this delay.
- Fix the problem.