Closed Bug 106865 Opened 23 years ago Closed 22 years ago

Blank page instead of SSL error dialog visiting https server

Categories

(Core Graveyard :: Security: UI, defect, P2)

Product:
Core Graveyard
Component:
Security: UI
Version:
1.0 Branch
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
psm2.4

People

(Reporter: nelson, Assigned: KaiE)

References

(
URL
)

Details

Attachments

(4 files, 3 obsolete files)

cert database for use with selfserv
(deleted), application/octet-stream
Details
key database for use with selfserv
(deleted), application/octet-stream
Details
Patch v4
(deleted), patch
rpotts
: review+
KaiE
: superreview+
asa
: approval+
Details | Diff | Splinter Review
Patch as checked in
(deleted), patch
Details | Diff | Splinter Review
I'm running N6.x BuildID: 2001091703 I'm attempting to reproduce a problem reported by a user with an older version of Mozilla. I should be getting SSL error dialogs, (like the ones he reported) but instead I'm getting the infamous blank page, whose contents are: <html><body></body?</html> That blank page phenomenon is EVIL! Here's how I reproduced it. 1. Visit http://ca.in-berlin.de/cgi-bin/rootca and download the root CA cert, but do not check any of the trust check boxes. 2. Visit http://ca.in-berlin.de/cgi-bin/serverca and download the intermediate CA cert, but do not check any of the trust check boxes.3. Visit https://me.in-berlin.de/ or https://me.in-berlin.de/asdfkjh You should get an error message about an untrusted CA cert. Instead, I get a blank page. 4. Then use the Certificate Manager and edit the trust flags for the root CA, trusting it to issue SSL server certs. 5. Visit https://me.in-berlin.de/ or https://me.in-berlin.de/asdfkjh You should get an error message about some other problem with the CA cert. Instead, I get a blank page. I think that A) we should never see blank pages when there are SSL problems, and b) if we ever DO get this page, IT SHOULD NOT BE BLANK. I propose that the page be changed to something like this: <html><body>If you can see this, PSM needs more work.</body?</html>
This was taken care of by the fix to bug 97997 *** This bug has been marked as a duplicate of 97997 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Priority: -- → P2
Resolution: --- → DUPLICATE
Target Milestone: --- → 2.2
Verified dupe.
Status: RESOLVED → VERIFIED
I've got news for ya. I downloaded the 10-22 build from sweetlou, which identifies itself as Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 (note it says 10-19) And I get the same blank pages from it. So this bug is NOT fixed.
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---
Here is an update. I see that what's actually happening is that no new page is being loaded at all. It's not a new blank page being loaded. Whatever page was being shown before is left showing. So, with this bugzilla page in my window, I visit the URL cited above, and when the throbber stops, it says "document done", and no error dialogs appeared, but I'm still looking at the same mozilla bug page.
With the 10/26 Win98 trunk build, I get "You cannot connect because of an unknown SSL error (-8101)"
Using nelsonb's TLS tests, I get: /u/junruh/tls >./tstclnt -h me.in-berlin.de -d . < stdin.txt tstclnt: connecting to me.in-berlin.de:443 (address=213.61.118.14) tstclnt: connect: Operation is still in progress (probably a non-blocking connect). tstclnt: about to call PR_Poll for connect completion! tstclnt: PR_Poll returned 0x02 for socket out_flags. tstclnt: ready... tstclnt: about to call PR_Poll ! tstclnt: PR_Poll returned! tstclnt: PR_Poll returned 0x01 for stdin out_flags. tstclnt: stdin read 16 bytes tstclnt: Writing 16 bytes to server tstclnt: about to call PR_Poll on writable socket ! tstclnt: PR_Poll returned with writable socket ! tstclnt: about to call PR_Poll on writable socket ! tstclnt: PR_Poll returned with writable socket ! tstclnt: write to SSL socket failed: Certificate type not approved for application.
How 'bout a dialog box saying that in PSM?
Confirmed for 2001110703 on Win98SE. This bug is very annoying (severity should be major) because no https site can be browsed.
rangan
Assignee: ssaux → rangansen
Status: REOPENED → NEW
Status: NEW → ASSIGNED
Something darn similar to this is happening in release 0.9.6, though it did not happen in 0.9.5, on Linux. With the 095 release, I was able to do my secure banking and shopping with no problem at all. With 096, hitting https:// pages do nothing at all, or load a blank page if they were to open a new window (either by javascript or by hitting the middle mouse button). I reported it as bug #111323, which will likely be marked a duplicate of this one.
This bug is really annoying. In fact, it's a "showstop" bug for any HTTPS user. Please, update the "severity" field to reflect this important fact. Mozilla is my only browser since last summer. Excellent work, guys. Merry Christmas and happy 2002.
Blocks: 126944
Works for me. I cannot reproduce, and also haven't seen a blank page for a long time now.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → WORKSFORME
Verified works for me.
Status: RESOLVED → VERIFIED
I got some bad news for you guys, this bug is still in 0.9.9, and it's still as much of a showstopper. Except now I have a test case. It involves a bad SSL server configuration, but nonetheless mozilla should report an error, not a blank page . See the attached cert and key databases. They are for the server. Run selfserver from NSS the following way : (strange)/u/jpierre/nss/34/mozilla/dist/SunOS5.8_DBG.OBJ/bin{72} !68 ./selfserv -n Server-Cert -p 2000 -m -r -r -w enterprise Then connect with Mozilla to the machine, in this case https://strange:2000 . Then, mozilla will display the infamous blank page ! Meanwhile, selfserv will also report an error below : selfserv: HDX PR_Read returned error -12199: No certificate authority is trusted for SSL client authentication. This is normal and is expected for this invalid SSL server configuration. But mozilla must deal with it. This is a showstopper.
Attached file cert database for use with selfserv (deleted) —
Reproduced, reopening
Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---
Attached file key database for use with selfserv (deleted) —
You may want to take a look at http://bugzilla.mozilla.org/show_bug.cgi?id=134125 for other investigations about what led me to create this testcase . Apparently the client side just gets an "end of file" right away from the misconfigured server, there is no SSL error reported. So there may also be a libssl bug at stake here. Even if there is no SSL error reportd, mozilla should still report a problem with the site if it submits an HTTPS request and gets nothing back from the server. I discussed the HTTP/HTTPS aspects of this in another very similar bug, http://bugzilla.mozilla.org/show_bug.cgi?id=126944 .
OS: Windows NT → All
Hardware: PC → All
kai
Assignee: rangansen → kaie
Status: REOPENED → NEW
Target Milestone: 2.2 → Future
This problem seems related to "proxy" usage and SSL2+SSL3+TLS support. If you have a proxy, TLS support and the remote server doesn´t support TLS but SSL3, you see the problem. I haven't bug IDs at hand, but the problem seems reported also in this context. Search the bugzilla database. Since I can only navigate thru a proxy (squid), this is a showstop for me and a big NO-NO for a inminent 1.0 release.
I believe that this bug and bug 126944 are duplicates. I'll leave it to the assignee to decide which one to mark as a dup. I believe that neither bug has anything to do with proxy handling. This bug and bug 126944 appear to have the same cause, namely, a flaw in the logic that attempts to decide whether a given error should be displayed to the user by PSM or not. Esentially, the error is that the code only displays errors for error codes that begin with SSL_, not ones that begin with PR_ or SEC_. The explanation for this bug is given in http://bugzilla.mozilla.org/show_bug.cgi?id=126944#c6
I have seen a similar problem. The feature I realized is that https:// pages work only if disk cache is enabled. If the disk cache size is set to 0 (or left blank) a https:// page doesn't show up at all. Really strange.
My comment was wrong. I meant memory cache instead of disk cache.
Keywords: nsbeta1
Keywords: nsbeta1 → nsbeta1+
Here's my findings: - The original problem is no longer reproducable as it has been said already. Trying steps 1-3 in the original report, I indeed see the error message. After steps 4-5 the connection works, probably as the server configuration is meanwhile correct. - I can reproduce the problem that Julien reports in comment 14, using the approach he suggested. However, the symptoms are different. I don't see a blank page any longer. However, when the failure occurs, no warning is shown at all. The connection silently fails. The content currently shown in the browser continues to be shown, and the user has no idea what happened.
Status: NEW → ASSIGNED
Michael, I can not reproduce your problem. But it sounds different. If you still can reproduce, please file a separate bug.
Attached patch Patch v1 (obsolete) (deleted) — — Splinter Review
When the connection fails in the given scenario, NSS does not return a specific failure code. Instead we receive PR_END_OF_FILE_ERROR. Julien, Nelson, do you think NSS should return a better error code? Or is it reasonable to always inform the user if a connection to a remote site fails with this error? The attached patch will always show an error message to the user, if an attempt is being made to load a top level document, and the socket transport thread detects an EOF while expecting to be able to read or write to the socket. Darin, do you think this makes sense? If yes, is it ok to Mozilla's error code NS_ERROR_ABORT or should we define a new one, like NS_ERROR_END_OF_FILE?
NS_ERROR_ABORT is probably too generic for this. would it be useful to have necko retry the connection? if so, then you should map PR_END_OF_FILE_ERROR to NS_ERROR_NET_RESET. if 10 unsuccessful attempts go by, necko will finally error out to docshell with NS_ERROR_NET_RESET, which will cause docshell to put up the error message saying "the document contains no data."
Would an automatic retry have the chance to retransmit high level application data, like the user's command to submit an order? I wonder what happens if a buggy server accepts the order and sends us an EOF. If you prefer an automatic retry and the same handling as in connection reset, could we limit the automatic retry on EOF to those situations, where no high level protocol data has yet been exchanged?
> Would an automatic retry have the chance to retransmit high level application > data, like the user's command to submit an order? yes, provided we have not yet read any data to satisfy the transaction. i.e., necko already assumes that if there is no response from the server, then there was never a complete transaction. this is actually required given the way TCP/IP works. that is, writing may appear to succeed even though the other end has closed the socket. you'll only find out that it is closed after you get done writing and try to read. > I wonder what happens if a buggy server accepts the order and sends us an EOF. ooh.. that'd be very bad. > If you prefer an automatic retry and the same handling as in connection reset, > could we limit the automatic retry on EOF to those situations, where no high > level protocol data has yet been exchanged? there's no way to determine if high level data has been exchanged. sure, we could say that we won't do this when issuing a HTTP POST, but what about a HTTP GET? it can have side-effects even though the standard says it should not. when does the EOF occur? were we able to successfully complete the SSL handshake? is it just that the server closed the connection after we issued the HTTP request?
1) In this particular situation reported within this bug, the SSL handshake will have failed, and no application data will have been exchanged. I would like to find a way to report this failure to the user. 2) All we see is an EOF error code. This is a generic error that might occur in many other situations, like generic networking for other protocols. Currently, this error code is not specifically handled in necko. 3) When we try to do 1), I would like to avoid introducing new risks for 2), like the "order submit example" for the http protocol. I was asking about how Necko behaves, because I want to be careful. I think we should do 1) without having to care for individual protocols like http. The question is: Will a general new rule in Necko, that makes it retry on EOF, have the risk to introduce new risks for 2)? If there is the risk, I'd prefer to avoid it, and just display an error to the user immediately.
This whole discussion might be obsolete, if Nelson thinks that NSS should give us a better error message than just EOF, like SSL_HANDSHAKE_FAILED. Nelson, what do you think?
The SSL protocol demands that an SSL "close notify alert" record be sent before a connection is closed. If an SSL connection reads an EOF from the underlying socket without having already received a "close notify alert", this is a violation of the SSL protocol. In this case, the EOF is an error, a protocol violation, rather than merely being an indication of the normal end of the server's data stream. So, libSSl returns -1 with PR_END_OF_FILE_ERROR rather than returning zero (EOF) in this case. AFAIK, this is the only circumstance under which PR_END_OF_FILE_ERROR is generated (in libSSL). So, PR_END_OF_FILE_ERROR means that the remote server (or an attacker) closed the connection without properly terminating the SSL protocol. The application may wish to take a different action than it would for the normal EOF case when it sees this error. How the application deals with this error is application dependent. Off the top of my head, I might suggest that the application could treat this error the same as an ordinary EOF if it has not received any response to its https request prior to the receipt of this error, and treat it as a security error if some portion of the http response has been received prior to the occurance of this error.
On second thought, I think the interpretation of the PR_END_OF_FILE_ERROR has to depend on whether or not the http request was sent prior to the error occurance. If the request was completely sent before the error occurs, then this error has to be regarded as a security violation, a "truncation attack". This invalid-EOF-detection facility in SSL/TLS is there precisely to deal with situations like the one where the server receives the request, honors it, and then the client is disconnected (e.g. by an attacker inserting a TCP FIN segment) before the client receive's the server's response. In this situation, the user should be notified that the connection was terminated in an insecure way, and perhaps the user should be advised to check to see if the transaction was completed before resubmitting the transaction.
Let me summarize: I conclude that Nelson - does not think NSS should send us a better error, but PR_END_OF_FILE_ERROR is sufficient. - suggests we should NOT automatically retry if there is the chance the remote site has already received our request. - implicitly allows us to retry in certain situations, like knowing that we have not yet sent any application data. (I'm generalizing from the http protocol situation to a generic application protocol, since we probably don't want to add http protocol dependent logic to the generic socket transport logic.) In addition I see there is no other code in Mozilla which sets the PR_END_OF_FILE_ERROR code, so our new behaviour is not likely to introduce side effects. To avoid risks and find a general solution I keep up my suggestion to: - never retry - always warn As a result, we are back at comment 26/27, where I ask whether NS_ERROR_ABORT is fine, or whether we should introduce a new one. As Darin thinks the abort error code is too generic, I suggest to introduce a new error code. If nobody objects, I will attach a new patch, that is very similar to the previous patch, but defines and uses the new error code NS_ERROR_END_OF_FILE (directly defined in xpcom/base/nsError.h since this code sounds to be generic enough).
1. Yes, I think PR_END_OF_FILE_ERROR is sufficient. I see no need to create another new error code (e.g. NS_END_OF_FILE_ERROR) with a 1:1 mapping. 2. The logic that decides whether or not to retry an http request should be the same with or without SSL. It seems to me that the http client should not silently reissue the http request if/when it receives EOF __AFTER__ it has completely sent the request. 3. PR_END_OF_FILE_ERROR is different from a ZERO return (ordinary end of file) in that the latter signifies an SSL protocol violation, a potential security attack. I think that never retry & always warn is appropriate for this.
if you don't want the HTTP module to silently retry the request, then mapping PR_END_OF_FILE_ERROR to NS_ERROR_NET_RESET is wrong. if you map it to some error like NS_ERROR_ABORT, then the user will see nothing but a blank page. what you probably want to do is map the error to some other error (perhaps defined in netCore.h) and modify nsWebShell::EndPageLoad to check for that error and display a message to the user indicating why they are seeing a blank page.
Nelson, > 1. Yes, I think PR_END_OF_FILE_ERROR is sufficient. I see no need to create > another new error code (e.g. NS_END_OF_FILE_ERROR) with a 1:1 mapping. My question was only related to what NSS gives out. Thanks, I'll react to that code then. The suggested 1:1 mapping to a new NS_END_OF_FILE_ERROR code has a different reason: In Mozilla, the error code needs to transported through XPCom components, which has a different error code namespace, and I can't pass the PR code through as is, so I would like to introduce that new code. > 2. The logic that decides whether or not to retry an http request should be the > same with or without SSL. It seems to me that the http client should not > silently reissue the http request if/when it receives EOF __AFTER__ it has > completely sent the request. I assume, in this paragraph, when you say EOF, you mean ordinary EOF, i.e. zero byte return. Agreed. I would even go one step further and not limit this proposal to HTTP, but to any protocol. With the new error code PR_END_OF_FILE_ERROR / NS_END_OF_FILE_ERROR, I think we already agree to not retry. However, for error codes PR_CONNECT_ABORTED_ERROR and PR_CONNECT_RESET_ERROR I think we should move that handling to a separate bug. I would like to leave that decision to Darin, whether to change the existing behaviour for those error codes (which is unrelated to this bug). > 3. PR_END_OF_FILE_ERROR is different from a ZERO return (ordinary end of file) > in that the latter signifies an SSL protocol violation, a potential security > attack. I think that never retry & always warn is appropriate for this. Good. I think we all agree here. This is what this bug is about.
Darin, > if you don't want the HTTP module to silently retry the request, then mapping > PR_END_OF_FILE_ERROR to NS_ERROR_NET_RESET is wrong. Agreed. We don't want that. > if you map it to some > error like NS_ERROR_ABORT, then the user will see nothing but a blank page. Only because we don't handle that error code currently, but in my patch I suggest to do so. However, as you said, NS_ERROR_ABORT is generic, and I suggest to introduce NS_END_OF_FILE_ERROR, and use that error code instead in my patch. Besides that change, the patch should still be what we seem to agree on. > what you probably want to do is map the error to some other error (perhaps > defined in netCore.h) I suggested a global NS_END_OF_FILE_ERROR, but if you prefer a network code local error code, that's fine with me, too. > and modify nsWebShell::EndPageLoad to check for that error > and display a message to the user indicating why they are seeing a blank page. I believe that is what the attached patch is doing already?
I discussed with Sean Cotter, explaining the problem. He suggested the following wording (where %S is the hostname). I like the wording. "The connection to %S has terminated unexpectedly. Some data may have been transferred."
Attached patch Patch v2 (obsolete) (deleted) — — Splinter Review
This new patch has the following changes: - uses new XPCom error code NS_ERROR_SOCKET_EOF defined in netCore.h (instead of NS_ERROR_ABORT) - maps PR_END_OF_FILE_ERROR to the new error code, no automatic retry - extends nsWebShell::EndPageLoad to detect the error and calls an extended version of nsDocShell::DisplayLoadError which will display the new error message suggested by Sean Darin, if you agree, can you please review?
Attachment #95348 - Attachment is obsolete: true
this message: "The connection to %S has terminated unexpectedly. Some data may have been transferred." should almost be the default error message when a document fails to load completely (not as a result of user action). i've tried to introduce such a dialog, but there are unfortunately some cases in which it erroneously fires. iirc, imagelib terminates some otherwise valid image loads with NS_ERROR_FAILURE, and javascript: URLs may even signal an error in some cases. this is why we use a white-list to determine which errors should map to error dialogs. in this case, i think you could safely use NS_BASE_STREAM_CLOSED instead of introducing a new error code.
If I understand you correctly, you want to use that generic code for this specific situation in this bug, and are willing to accept that as a result, this message will be shown in many situations, whenever the BASE_STREAM_CLOSED error appears (at least for the top level document)? New patch coming up.
Attached patch Patch v3 (obsolete) (deleted) — — Splinter Review
Same patch as v2, using NS_BASE_STREAM_CLOSED instead
Attachment #97228 - Attachment is obsolete: true
Comment on attachment 97234 [details] [diff] [review] Patch v3 sr=darin
Attachment #97234 - Flags: superreview+
Comment on attachment 97234 [details] [diff] [review] Patch v3 I should have tested this latest version of the patch, it does not work, and I have already discussed with Darin. The problem is that we can't really use NS_BASE_STREAM_CLOSED, as this code is occurring in standard situations and will be mapped to NS_OK.
Attachment #97234 - Attachment is obsolete: true
I have discussed with Darin, the new error code should be named NS_ERROR_NET_INTERRUPT. The following is a summary of what I have discussed with Darin, and what I believe is true for the PR_END_OF_FILE_ERROR. This paragraph is actually long, and you might not want to read it completely. It is rather the result of me trying to sort my thoughts and trying to understand it better. After having written it, I'm more confident what we are doing here is correct. Assumption: When writing bytes over TCP/IP, it is not immediately known whether the write succeeded or not. When doing the next read, and the read fails, it is unknown how many bytes (none, some, all) were received by the remote site. Desired Mozilla network behaviour (already in place): (1) If not even a single byte has been received from the remote site, and a read error is detected, an automatic retry should happen. This is currently done when PR_CONNECT_ABORTED_ERROR or PR_CONNECT_RESET_ERROR is seen (and communicated using NS_ERROR_NET_RESET). Suggested additional behaviour: (2) If the application is sure that at least one single byte has already been received from the remote site, and an unexpected read error is detected, then we don't want to retry. This is communicated with the new proposed code NS_ERROR_NET_INTERRUPT. Nelson said, if PR_END_OF_FILE_ERROR is set, it means the remote site did not follow the protocol rules. I assume SSL is a "client writes first" protocol. There are two possibilites: a) We have started with sending the initial handshake bytes, but the remote site did not answer, we did not receive any bytes. I assume this is NOT treated as the PR_END_OF_FILE_ERROR case. It probably does not make sense. If we are not yet sure the other site is speaking our protocol, since we have not yet received any bytes, we can't really assume it's a protocol violation. b) We have not yet exchanged application data, but we are still in the SSL negotiation phase. We have already exchanged at least some SSL handshake bytes, so we are assuming the remote site speaks SSL, and we are negotiating details. Once we have arrived in that state, we assume the protocols must be followed. If in that situation the remote site terminates the connection, without having followed the fule to say "good bye", the situation is treated as a protocol violation, and PR_END_OF_FILE_ERROR is reported. c) We have completely finished the SSL handshake phase. We are now in the phase terminating the connection with sending "good bye" messages first is a protocol violation. Therefore, any unexpected connection termination is communicated with PR_END_OF_FILE_ERROR. My assumption a) is probably correct. In this case, SSL is not different from any other network logic. An automatic retry would be reasonable and can not cause problems. But even if my assumption were wrong, and PR_END_OF_FILE_ERROR is set anyway, this isn't much of a problem. The only consequence is: No automatic retry on initial SSL connection failure. If PR_END_OF_FILE_ERROR is seen in b) or c), it is reasonable not to retry. If we don't want to retry, we need to communicate that using NS_ERROR_NET_INTERRUPT. By setting NS_ERROR_NET_INTERRUPT for both b) and c), the application code can't distinguish whether application data was exchanged or not. However, since it is known for sure that at least some bytes were exchanged, a general connection was possible, and it is known for sure the actual transaction has been started. If that is known for sure, it is reasonable to not automatically retry / repeat the transaction.
Attached patch Patch v4 (deleted) — — Splinter Review
This patch introduces the new error code as suggested. Besides that I have made one additional change: The previous patch only showed the error when the top level frame produced that error. However, I think it is reasonable to show that error even if the error occurs in a sub frame.
This time I have actually tested the patch. It works for me. Besides Julien's test case, it also fixes another behaviour. Try to open https://www.mozilla.org:80/ It shows the same wrong behaviour (blank page, or rather, unchanged display, without error message). That's another situation this patch fixes. Darin, are you ok with the numerical error code I assigned? It seems to fit into the "net range", but that range was already full...
Target Milestone: Future → 2.4
Comment on attachment 97274 [details] [diff] [review] Patch v4 Since you did not object to my previous comment, carrying forward sr=darin
Attachment #97274 - Flags: superreview+
Rick, could you please review, too?
Comment on attachment 97274 [details] [diff] [review] Patch v4 a=asa for checkin to 1.2beta (on behalf of drivers)
Attachment #97274 - Flags: approval+
fixed on trunk
Attached patch Patch as checked in (deleted) — — Splinter Review
This is identical to patch v4 with two differences: - previous patch did no longer apply because of context changes, fixed - I did not check in the added PR_LOG statements, to save me some merging trouble with other patches I'm working on
marking fixed
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 22 years ago
Resolution: --- → FIXED
verified.
Status: RESOLVED → VERIFIED
Product: PSM → Core
Version: psm2.1 → 1.0 Branch
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: