Closed Bug 707397 Opened 14 years ago Closed 2 years ago

Add libssl callback that is called after the peer's hello message has been processed

Categories

(NSS :: Libraries, defect, P5)

Tracking

(Not tracked)

RESOLVED INACTIVE
Future

People

(Reporter: briansmith, Unassigned)

Details

(Keywords: perf)

Mozilla needs a way to determine, as early in the handshake as possible, that the NPN extension has been or has not been negotiated. Also, I suspect that we will need to know early on in the handshake whether other extensions have been negotiated in the future. Because of the issues mentioned in bug 707394 and bug 681839, the best way to ensure this would be to create a new callback that is called when the peer's hello message (ServerHello for clients; ClientHello for servers) has been processed. I propose the following API: typedef SECstatus (PR_CALLBACK *SSLHandshakeCallback) (PRFileDesc *fd, void *client_data); SECStatus SSL_HelloCallback((PRFileDesc *fd, SSLHelloCallback cb, void * client_data); The registered callback would be called at/near the end of ssl3_HandleClientHello and at/near the end of ssl3_HandleServerHello. No implementation for SSL 2 would be provided. If the callback returns SECSuccess, everything would continue as normal. If the callback returns SECFailure, then the handshake would stop. if the callback returns SECWouldBlock, then the handshake would stop with a SSL_FEATURE_NOT_IMPLEMENTED_FOR_SERVERS/SSL_FEATURE_NOT_IMPLEMENTED_FOR_CLIENTS error code, as I don't think an asynchronous restart mechanism is needed for this. I think that Mozilla will need this functionality because of the SPDY connection coalescing feature; it seems like we need to determine, as early as possible, that a connection is NOT a candidate for connection coalescing (e.g. because SPDY was not negotiated), so that we don't wait around until one of the later callbacks is called to decide to open a new connection. Without this, I fear our SPDY connection coalescing feature might regress non-SPDY HTTPS performance, especially for sites that use wildcard certificates.
Assignee: bsmith → nobody
Component: Documentation → Libraries
QA Contact: documentation → libraries
I was wrong. Mozilla may not need this now.
Priority: P1 → --
Target Milestone: 3.13.2 → Future
Severity: normal → S3
Severity: S3 → S4
Status: NEW → RESOLVED
Closed: 2 years ago
Priority: -- → P5
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.