703032 - Provide an option to have libssl put sessions in the client session cache before they have been authenticated

Status: RESOLVED INVALID

(NSS :: Libraries, enhancement, P1)

Description

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

+++ This bug was initially created as a clone of Bug #542832 +++

In the patch for bug 542832, I wait to cache a session until after the certificate has been authenticated, because when we resume sessions, we don't call the auth certificate callback to authenticate the certificate. However, this is sub-optimal, because it means that a second connection to a server must either wait for an entire full handshake to be completed (to resume it) or it must be a full handshake (if we don't wait). 

Instead, the application should be able to tell libssl to put unauthenticated sessions in the cache as early as possible (i.e. in ssl3_HandleServerHello). When libssl finds a session in the cache, it should resume the session like it normally does. However, it must check in ssl3_SendFinished to ensure that the session has the master secret (because the master secret cannot be computed until well after ssl3_HandleServerHello), and libssl must check in ssl3_FinishHandshake that the peer certificate for that session has been authenticated.

The result would be that subsequent connections to a server would be able to be started (client hello sent) before the original connection has even received the server's Certificate message.

Note that the placement of the NewSessionTicket message in the handshake is unfortunate with respect to this kind of optimization.

Comment 1

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Generally, a server will not resume any session that hasn't gone through a complete handshake first. So, this type of optimization is not generally possible unless the server also implements part of the optimization on its end. That seems unlikely to be worth the effort, especially when SPDY discourages the use of multiple connections anyway.