Possible data race in qtls.clientSessionCache about quic-go HOT 2 CLOSED

Interesting. The crypto/tls code is accessing a session ticket that (presumably) has been retrieved from the session cache, while the session cache is modifying the ticket.

I suspect this is happening because you're concurrently dialing two connections that are both trying to resume using the same session ticket. We probably need to protect the session cache with a mutex.

from quic-go.

However, I think this can only happen if the underlying ClientSessionCache actually returns the same session ticket multiple times. If the underlying ClientSessionCache was well-behaved and only returned every ticket once, there'd be no way that two Go routines would access the same session ticket and create the race condition you're observing.

See RFC 8446 and RFC 9001 regarding the reuse of session tickets.

Strictly speaking, it's not forbidden to reuse the session ticket though (it's just a "SHOULD NOT"), so maybe we should introduce the mutex anyway. That would make it safer for our users to shoot themselves in the foot.

from quic-go.