On 08/14/2014 03:37 AM, Nathan Scott wrote:
There is one qa issue which affects tests 712 and 966. In the old
implementation, servers would initialize NSS right away and, should that
fail, were able to report that secure connections are not supported
during the connection handshake with the first client to connect. With
the new implementation, NSS initialization is not attempted until the
first secure connection is actually requested (after the first
connection handshake). Thus, when the first client connects, a server
built --with-secure-sockets will report that secure connections are
supported, even though that may ultimately turn out not to be true (e.g.
NSS init fails because there is no server certificate). Once NSS init
has failed, the server is then able to report that secure connections
are not supported during subsequent connection handshakes.
The visible result is that the first client to connect may be told that
secure connections are supported, only to get "connection reset by peer"
when a secure connection is actually requested. With the old
implementation, the first client to connect would be told during the
handshake that secure connections are not supported and would be able to
correctly report that to the user.
I'm not quite sure how to handle this. Suggestions please! One possible
solution is to have clients try to connect a second time when they
receive "connection reset by peer" the first time. During the second
handshake, the server will correctly report that secure sockets are not
supported. Another related solution might be to have the server report
that the status of secure connection support is unknown. This could then
be used as the trigger for a second connection attempt by the client
should an initial secure connection attempt fail.
Perhaps a new error code (as in "pmerr -l") could be introduced to give a
more meaningful message than ECONNRESET on that first failure? ISTR we
end up with ECONNRESET in alot of cases via NSS/SSL which made debugging
quite tricky ... so distinguishing more cases would be good. Relatively
simple then - no need for retries, protocol tweaking, etc.
That would be great, but I'm not quite sure how to accomplish this.
Please correct me if I'm misunderstanding the way the client/pmcd
handshake works. 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.
I don't see an opportunity for the server to indicate that it was unable
to upgrade to a secure socket.
Dave
|