286418 - non-responsive https server leaves SSL lock locked showing previous site's DNSname

Status: RESOLVED WORKSFORME

(Firefox :: Security, defect)

Description

[Adam Hupp]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050223 Firefox/1.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050223 Firefox/1.0.1

I have an F5 SSL accelerator (SSL proxy).  It is misconfigured so that it will
accept incoming SSL connections but the server it is proxying to is inacessable.
 I open FireFox to any non-SSL page, say http://google.com.  In the title bar I
enter the URL for the proxy.  It waits for a while and then title bar goes
yellow (to indicate a secure connection), and the lock icon appears for the page
I'm currently on ("www.google.com"), even though I never loaded that page via
SSL.  If I double-click the lock icon I get a "Page Info" dialog that says "The
web site www.google.com supports authentication...".  If I view the security
certificate it is the certificate from the SSL accelerator however. 
Unfortunitely I cannot give public access to the SSL proxy used here since it is
being used for internal testing at my company.  I was able to reproduce this
many times in a row, but after closing the browser window I was no longer able
to reproduce.

See screenshot at http://hupp.org/google_secure.png


Reproducible: Couldn't Reproduce

Steps to Reproduce:
1. Setup SSL proxy as described in the details
2. Open a non-ssl page
3. Connect to the SSL proxy and see the described results.

Actual Results:  
I closed the browser window I had been doing this in, but not all browser
windows.  After doing this I was unable to reproduce the problem.

Expected Results:  
Given a timeout message and not shown the lock icon.  This is what it did once I
was no longer able to reproduce the problem.

Comment 1

[Daniel Veditz [:dveditz]]

Darin, jst: this sounds suspiciously like the same class of lock icon bugs fixed
in 1.0.1 (http://www.mozilla.org/security/announce/mfsa2005-14.html), the one
Dougt found in particular. But this bug was reported against that fixed version,
and then was not reproduceable.

Any ideas?

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

For purposes of browser analysis, the fact that this server is an "accelerator"
(reverse proxy, a.k.a. server-side proxy) is probably immaterial.  We can think
of it simply as an https server that has a problem and either 
(a) completes the SSL handshake and receives the https request but then does 
not complete the https transaction, or possibly
(b) begins but does not complete the transaction.

Either way, eventually the browser times out, and (as shown in the image) 
leaves the lock locked but next to the lock it shows the name of the http 
server being used before the https URL was entered.  Also, the name of 
the http site is erroneously shown in the dialog displayed in the security 
tab of the page into dialog.

Adam, if you are able to reproduce this, we can show you how to run ssltap, a
program that itself acts like a reverse proxy and logs all the traffic passing
through.  That might help FF developers with the analysis.  (ssltap doesn't
decrypt any traffic, but merely records the traffic,  Nonetheless it is very
helpful.)

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

above I wrote:
> (b) begins but does not complete the transaction.
I meant
(b) begins but does not complete the SSL Handshake.

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

Changing bug summary to better describe problem

Comment 5

[Adam Hupp]

I can't reproduce it at the moment but if it happens again I'll try the ssltap.
 Is there win32 binary?

Comment 6

[Daniel Veditz [:dveditz]]

Yes, ftp://ftp.mozilla.org/pub/mozilla.org/security/nss/releases/NSS_3_9_2_RTM/

You'll also need the NSPR .dll's (why are required libraries not included in the
nss packages?) from ftp://ftp.mozilla.org/pub/mozilla.org/nspr/releases/v4.4.1/

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

Attachment: Reporter's PNG screenshot

I attached the screen shot to this bug so that the reporter needn't 
keep his copy online.

Comment 8

[Daniel Veditz [:dveditz]]

Haven't been able to reproduce, not blocking 1.0.5

Comment 9

[Asa Dotzler [:asa]]

if we can get a reproducible case and a patch, we'd consider for the upcoming
release but we're not going to block on this without more info.

Comment 10

[Daniel Veditz [:dveditz]]

Closing WFM for lack of progress at finding a way to reproduce this, hope it was a dupe of one of the other bugs we fixed.