This is Bugzilla: the Mozilla bug system. For more information about what Bugzilla is and what it can do, see mozilla.org's bug pages.

Bugzilla Bug 126944

No error or pop-up when connecting to bad HTTPS server

Bug List: (0 of 149) First Last Prev Next   Show list      Query page      Enter new bug

In some situations, an SSL HTTP server can be in a "bad" state and the SSL
handshake will fail. See bug 125149 for more info about the specific situation
we were running into with the server.

When the SSL server was in that bad state, I observed that Netscape 6.2.1 and
Mozilla were just displaying a blank page when connecting to that bad server,
without displaying any kind of error or pop-up. Communicator was displaying a
pop-up error message about being unable to connect.

A command-line HTTPS test client revealed that on the client side, an NSPR "end
of file" error was being returned. Apparently Mozilla/Netscape6 ignore that
error and just don't display anything. This is wrong.

<speculation>
I suspect this is a bug in the HTTP engine implementation in Mozilla. The HTTP
spec says that the servers are allowed to close the connection between requests
at any time, so an end-of-file may not be viewed by the client as an error. I
think it is fine to treat it that way for keep-alive/pipeline connections, and
reopen a new connection. Still, the browser would have to reopen a new
connection with the server, and eventually display an error if it can't get a
response and keeps getting end-of-file.

I would also argue that for the first request/response after a connection,
getting end-of-file immediately should be treated as an error.
</speculation>

FYI, I didn't think of trying any other SSL URI protocol handler and connecting
to that bad server. It would take some effort (small patch to break something in
NSS and run that with selfserv) to recreate the bad server environment to test
this, but it can be done.

I suspect that this bug is a duplicate of bug 106865.
If you concur, please mark this bug as a duplicate.

Nelson, yes, the symptoms look very similar. I'm not truly sure if this is the
same problem because the error that ends up being passed down to the top-level
here is not a security error but a plain NSPR error. It's possible that they are
all being treated the same way in the HTTP parser in Mozilla, though, at the
stage where no bytes have been received from the server. I'd like someone from
the client to examine my comments above about the HTTP code. I don't have to
look at the code myself. For now I want to keep this bug open.

The word "time" was missing from my last sentence, as in, "I don't have time to 
look at the [browser HTTP networking] code myself".

Err ... Is anybody looking at this bug in mozilla ?

This bug appears to be assigned to an inappropriate assignee.  
It is assigned to a mailing list.  Mailing lists do not fix bugs.

With help from Rangansen, I looked at function nsHandleSSLError() in 
http://lxr.mozilla.org/security/source/security/manager/ssl/src/nsNSSIOLayer.cpp
#431

This is the one function that displays error messages for all errors related to 
the use of SSL.  This function is able to display messages for errors generated 
by libSSL (e.g. errors named SSL_*) and by libNSS (named SEC_*), and any errors 
not recognized are displayed with a generic error message.

The problem is not in that function, but rather in the 3 calls to that function, 
one in nsSSLIOLayerRead and two in nsSSLIOLayerWrite, see lines 966, 1048 and 
1053.  Each of those 3 calls is preceeded by a test which is 
     if (IS_SSL_ERROR(err))

That test is wrong.  It is only true for the SSL_* errors.  It is not true
for any of the SEC_* errors, nor for any PR_* errors.  So, any SEC_* errors 
and PR_* errors will lead to the infamous blank page, UNLESS they are errors
that necko itself knows how to handle.

I submit that the proper test here is not (IS_SSL_ERROR(), but rather is
to test for the error codes that necko knows how to handle.  Only errors
that necko handles (other than with a blank page) should bypass the call
to nsHandleSSLError().  All others should go through nsHandleSSLError().

While I was reviewing nsSSLIOLayerWrite(), I noticed another issue, at 
http://lxr.mozilla.org/security/source/security/manager/ssl/src/nsNSSIOLayer.cpp
#1027
If the first SSL connection fails for ANY reason, and TLS was enabled, 
the code simply turns off TLS and gets necko to try again without TLS.
This is intended to recover from "TLS intolerant" servers.  But it retries
even on errors that are not due to a TLS intolerant server.  So, even when
the error is one that we KNOW will fail with both TLS and with SSL3, we
retry it with SSL3 anyway.  This is just wasteful, and doubles the number of 
error hits on most https servers.  For example, an error such as an invalid 
server cert, which is _never_ an indication of TLS intolerance, and which 
will always recur if we retry without TLS, gets tried twice anway.  

This really needs to get fixed.  The test at line 1030 that reads
    if (tlsOn) {
needs to be 
    if (tlsOn && errIndicatesTLSIntolerance(err)) {

and a new function errIndicatesTLSIntolerance(err) needs to be written to 
distinguish among the various cases.  It is probably safest for this 
function to simply detect the errors that are known to NOT be indicators
of TLS intolerance, and return false for them and true for all others.

Changing product to PSM.  The bug is in 
mozilla/security/manager/ssl/src/nsNSSIOLayer.cpp

Reassign bug to owner and QA contact of selected component

re: mailing list.

There is supposed to be an engineer on this mailing list. I'll work on that some
more. 

I think the real problem here was that the bug was filed in the wrong component,
and lacked a reproducible test case. We get a lot of bugs in this component that
eventually leave, so we do our best with the traffic.

Just checking Build 2002041903 on Win98... The problem continues.

Try to login to http://www.sourceforge.net/ using SSL. I used to use Mozilla,
but since Summer i've had to downgrade to MS Internet Explorer just to check my
projects ans post patches and bugs in Sourceforge :-(.