When an NSPR socket has SSL "imported" into it, and then is connected, either by a call to PR_Connect or a call to PR_Accept, the SSL state machine variables are initialized. But if an NSPR socket is connected first (either by connect or accept) and THEN has SSL "imported" into it, it is necessary to call SSL_ResetHandshake() to properly initialize all the SSL variables, and to tell it whether to handshake as an SSL client or an SSL server. If an application imports SSL into an already-connected NSPR socket, and fails to call SSL_ResetHandshake() before attempting to do I/O on the socket, a crash will occur. This is undesirable. Although the application has made an error, it would be better if an error code was returned instead of the crash. For one thing, application programmers usually assume that a crash in NSS is no fault of their own, and do not tend to examine their own code for error before blaming the NSS libraries. Presently, the SSL socket options "SSL_HANDSHAKE_AS_CLIENT" and "SSL_HANDSHAKE_AS_SERVER" only affect the initialization done by the PR_Accept and PR_Connect calls, respectively, and do not affect the behavior of a socket that had SSL "imported" after it was connected. Although this is exactly as documented in http://www.mozilla.org/projects/security/pki/nss/ref/ssl/sslfnc.html#1086543 most users of the SSL API tend to assume these options DO affect sockets that were "imported" after being connected. So, it might be better if these options also affected the behavior of sockets that had SSL "imported" after they were connected. Setting either the "SSL_HANDSHAKE_AS_CLIENT" or "SSL_HANDSHAKE_AS_SERVER" options should suffice, obviating SSL_ResetHandshake.
Target Milestone: --- → Future
Great idea ... will never happen.
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.