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)
NSS
Libraries
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.
| Reporter | ||
Updated•14 years ago
|
Assignee: bsmith → nobody
Component: Documentation → Libraries
QA Contact: documentation → libraries
| Reporter | ||
Comment 1•14 years ago
|
||
I was wrong. Mozilla may not need this now.
Priority: P1 → --
Target Milestone: 3.13.2 → Future
Updated•3 years ago
|
Severity: normal → S3
Updated•2 years ago
|
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.
Description
•