Comment 35 for bug 1854363

I didn't expect that fixing this bug would require digging deeply into the C/C++ network code. And I wasn't aware how special our ldap network code is.

My explanations from comment 16 and comment 17 weren't a suggestion how to fix this bug. I only wanted to give you more background information, because you were wondering about some of this details in your comment before it.

Your latest patch does very little, and only changes that socket provider detail. That will be insufficient to fix this bug.

You noticed how the socket code uses layers of functions. Yes, it makes use of NSPR file descriptor layering. It allows to implement a wrapped connection, where an outer protocol and an innner protocol is spoken. One layer represents the plain socket that is accessed by the application protocol code (here: LDAP). When using SSL/TLS, this isn't the usual plain implementation of a socket. Instead, it uses a socket implementation from mozilla/security/manager, that provides special implementations for the I/O functions. That's implemented in nsNSSIOLayer.cpp, and that code module is called "PSM".

That application level layer glues the I/O functions to the raw underlying implementation of SSL/TLS, which is provided by the NSS library.

If the application code wants to connect/read/write, the call is sent to a function from nsNSSIOLayer (e.g. PSMSend), which in turn redirects to ssl_* functions. Ldap code -> PSM code -> NSS code.

The NSS socket layer keep tracks of the additional handshaking and other stuff that needs to be exchanged on the raw socket, in order to make the socket secure.

The first part of that is to initiate a handshake between the server and the client. That is, the first time you read or write to the socket, the NSS layer will detect that. It will start communicating with the other side to exchange a few message in both directions, until both sides are happy with the connection. Only after this has happened, the NSS layer will accept the raw application data (LDAP) and encapsulate it into encrypted packages for secure transport.

The first read/write activity by the application should trigger the handshake. Because that initial handshake can take some time, the usual approach is to use async network code. The LDAP application should use async reading and writing on the socket, until it succeeds.