Race in session ID cache with quickly reconnecting SSL/TLS client

NEW
Unassigned

Status

P3
normal
a year ago
6 months ago

People

(Reporter: kaie, Unassigned)

Tracking

3.32

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

a year ago
gnutls-cli --resume can be used to test session resumption with the session ID. It connects to a server, obtains a session ID, then disonnects, then connects again with the previous session ID, and reports if resumption was successfull.

On some platforms, when using gnutls-cli --resume to connect to selfserv, the NSS server code *sometimes* fails to find the session ID, despite the client sending the correct session ID.

There might be a race. NSS might not yet have fully setup the session ID of the first session, at the time the client performs the second connection.
(Reporter)

Comment 1

a year ago
Created attachment 8904304 [details] [diff] [review]
trace patch

I've used this patch to enhance SSL library tracing, to print the session IDs that are sent and received.

used with SSLTRACE=7
(Reporter)

Comment 2

a year ago
Created attachment 8904305 [details]
ssl-trace-sid-not-found.txt

This is a trace output from the ppc64le platform, where I was able to reproduce the issue more reliably.

Originally reported with NSS 3.28, I've used today's NSS trunk snapshot (pre-3.33) to confirm the issue is still present.
(Reporter)

Comment 3

a year ago
(In reply to Kai Engert (:kaie:) from comment #0)
> There might be a race. NSS might not yet have fully setup the session ID of
> the first session, at the time the client performs the second connection.

I meant, the ID might not yet have been added to the cache.
Hmm.. I note that selfserv is multithreaded, so if the logging functions are buffered, that would still be consistent with this trace.
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.