Patrick McManus wrote: > instead of modifiying nsisocketprovider, which non-http and non-ssl > things use, I modified nsISSLSocketControl to take a new setNPNList > method. The HTTP code uses this during init if the SPDY pref is set > and we are on SSL. The implementation of setNPNList is in > nsNSSIOLayer, which calls into nsSSLThread to safely use the new > SSL_SetNextProtocol NSS function there.
The NPN extension is a useful security feature for preventing cross-protocol attacks. We should be using it for all SSL connections, even when there is a single choice. That is, eventually every user of the SSL/TLS socket transports should pass in a (often singleton) list of possible protocols when constructing the transport. > The trickiest thing is that http connection needs to wait for the > handshake to be complete before writing any data into nss - indeed it > needs to know whether to send http or spdy syntax afterall. The trick > was that the nss state machine doesn't start the handshake (much less > complete it) without the write taking place. I added a harmless > asynchronous read request when this happens (because the recv also > kicks off the handshake) even though this is a write-before-read > protocol. There is a function SSL_ForceHandshake that does this. I would avoid trying to emulate it outside of libssl if possible, as there are a lot of subtleties. See https://bugzilla.mozilla.org/buglist.cgi?quicksearch=SSL_ForceHandshake for examples. /* Try to make progress on an SSL handshake by attempting to read the ** next handshake from the peer, and sending any responses. ** For non-blocking sockets, returns PR_ERROR_WOULD_BLOCK if it cannot ** read the next handshake from the underlying socket. ** For SSLv2, returns when handshake is complete or fatal error occurs. ** For SSLv3, returns when handshake is complete, or application data has ** arrived that must be taken by application before handshake can continue, ** or a fatal error occurs. ** Application should use handshake completion callback to tell which. */ I believe the "or application data has arrived that must be taken by the application before the handshake can continue" case only occurs during renegotiations, which shouldn't be relevant to your changes. - Brian _______________________________________________ dev-tech-network mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-network
