----- Original Message -----
> [...]
> 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.
Ah, OK, got it. It could (would have to) be done as a PDU_FLAG_SECURE_ACK
extension, perhaps? Alongside the existing PDU_FLAG_SECURE - so existing
clients using secure connections would get ECONNRESET, but all newer ones
would get the clean error handling extension.
IOW, pmcd would set both flags in the initial exchange, old clients would
be oblivious, and new clients would be able to wait on ACK/error PDU before
entering into the full SSL exchange... ?
> > 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*
Yeah, if the above sounds feasible to you I think we'd then be able to see
the detailed SSL/NSPR/NSS error reporting on both ends of the connection.
cheers.
--
Nathan
|