On 08/19/2014 03:20 AM, Nathan Scott wrote:
The problem is that client has connected and the server
has responded with an extended error pdu claiming that it supports
secure sockets. The client the sends its credentials including its
intention to connect securely. At this point, both side attempt to
upgrade their sockets to secure ones, each expecting the other to
succeed and both initiate the SSL handshake. It is at this point that
the server fails to initialize NSS and drops its side of the connection.
Ah, does the NSS code swallow whatever error pmcd sends back? At the
point where NSS_Init (or subsequent SSL calls) fail, I was thinking we
would have an opportunity to capture that error and propogate it to
the client via an error PDU (when the client next read()s it'll get it
even if its slightly later in the exchange) before we close the socket.
But if NSS eats that error code and always does a connection reset (?),
we are in strife... is that what happens? - there's no opportunity to
send an error PDU before we close the connection?
Right. The server does attempt to send an error pdu but, because NSS
init failed, it sends it over the existing insecure socket connection.
Meanwhile, the client has already upgraded to a secure socket and is
expecting the SSL handshake. I think that this is why the connection
ends up getting dropped by NSS.
Note that the error pdu is only sent in the case that there is an error.
Perhaps what needs to happen is that something should be sent back to
the client on the insecure connection in all cases, essentially saying,
"yes, go ahead and upgrade" or "no, there's been an error". Only then
would the client and server be able to stay in sync in the event that
the server cannot upgrade. Unfortunately that would be a protocol change.
Note that this is not a new problem, just one exposed by the late
initialization of NSS. There are many other opportunities for things to
fail during the upgrade on both sides, many of which would leave the two
sides out of sync.
BTW, I notice there's a bunch of SSL_ERROR_* (incl NO_CERTIFICATE which
was your example situation IIRC?) over in <nss3/sslerr.h> - those would
seem like ideal things to be sending back, instead of new PMAPI error
codes ... (pmErrStr_r supports these already) - just need to find a way
to get pmcd to send that pesky error PDU.
*nod*
I don't see an opportunity for the server to indicate that it was unable
to upgrade to a secure socket.
I thought pmcd would be able to send an error PDU before it closes the
socket ... (and a non-connection-reset code should appear on next read)
- that didn't work?
Nope -- see above.
Dave
|