Last Comment Bug 257308 - Visual indicators of site security appear for the wrong site (lock icon)
: Visual indicators of site security appear for the wrong site (lock icon)
: fixed-aviary1.0, fixed1.4.4, fixed1.7.5
Product: Core
Classification: Components
Component: Networking (show other bugs)
: Trunk
: All All
: -- critical (vote)
: mozilla1.8beta1
Assigned To: Darin Fisher
: benc
: Patrick McManus [:mcmanus]
Depends on:
Blocks: lockicon
  Show dependency treegraph
Reported: 2004-08-29 05:06 PDT by Ben Sizer
Modified: 2008-06-11 01:00 PDT (History)
9 users (show)
dveditz: blocking1.7.5+
chofmann: blocking‑aviary1.0PR+
chofmann: blocking‑aviary1.0+
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

sample binary attachment (6 bytes, application/octet-stream)
2004-09-08 15:47 PDT, Darin Fisher
no flags Details
sample test case (view on non-secure server) (119 bytes, text/html)
2004-09-08 15:51 PDT, Darin Fisher
no flags Details
v1 patch (3.03 KB, patch)
2004-09-08 18:03 PDT, Darin Fisher
cbiesinger: review+
bzbarsky: superreview+
Details | Diff | Splinter Review
v1.1 patch - with similar nsDocShell changes (4.37 KB, patch)
2004-09-08 23:48 PDT, Darin Fisher
mozilla: approval‑aviary+
mozilla: approval1.7.5+
Details | Diff | Splinter Review
30kb mp3 (30.00 KB, text/plain)
2004-09-12 17:45 PDT, logan
no flags Details
v2 patch (7.14 KB, patch)
2004-09-17 11:34 PDT, Darin Fisher
bzbarsky: superreview+
Details | Diff | Splinter Review
v2.1 patch - revised per bz's comments (7.79 KB, patch)
2004-09-17 12:08 PDT, Darin Fisher
cbiesinger: review+
asa: approval‑aviary+
dveditz: approval1.7.5+
Details | Diff | Splinter Review
Complete patch, backported to 1.4 (9.10 KB, patch)
2005-01-24 14:27 PST, Christopher Aillon (sabbatical, not receiving bugmail)
darin.moz: review-
Details | Diff | Splinter Review
Backport for 1.4 take 2 (11.44 KB, patch)
2005-02-14 14:23 PST, Christopher Aillon (sabbatical, not receiving bugmail)
darin.moz: review+
Details | Diff | Splinter Review

Description Ben Sizer 2004-08-29 05:06:28 PDT
User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.2) Gecko/20040819 Firefox/0.8 StumbleUpon/1.9 (MOOX M2)
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.2) Gecko/20040819 Firefox/0.8 (MOOX M2)

If I'm on an http site, then I click a link on that site to a totally unrelated
https server which provides a downloadable file - not a file that can be viewed
in Firefox, and not where the link target is a new window - then the address bar
for the currently viewed HTTP site goes yellow, and the security box on the
status bar shows the http site with a padlock. In other words, the HTTP site is
reported as taking on the security characteristics of the HTTPS server that is
supplying the file rather than the currently-viewed page.

Further discussion here:

Reproducible: Always
Steps to Reproduce:
1.Find or create a link on a HTML page hosted on a HTTP server that points to a
downloadable file on an unrelated HTTPS server.
2.Click that link.
3.Accept the file or cancel (the visual indications change before you make the
choice anyway.)

Actual Results:  
Address bar background changes yellow.
Status bar security field displays the HTTP server name with a padlock, and
changes the tool-tip to mention the HTTPS's certificate issuing authority.

Expected Results:  
Made none of the above changes in the UI.

Perhaps the relevant section of the download manager window should go yellow
instead, but I'm sure that's a separate issue...

The linked-to discussion leads me to believe that the yellow-bar feature may
only be visible in more recent builds.
Comment 1 kstahl 2004-08-29 08:25:57 PDT
Confirming. Using the link in that thread to download a file from a secure
server gives me the padlock on the page I'm currently on.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040803 Firefox/0.9.3
Comment 2 logan 2004-08-29 09:24:01 PDT
This appears to be quite old. I've been able to duplicate this with Firefox
branch, 0.9.3, 0.9.1, 0.8 and Mozilla 1.7.2. It's possible this is a dupe of
another bug with the security flag.

Marking NEW, requesting blocking.

Thanks for filing man. :)
Comment 3 logan 2004-08-29 09:25:33 PDT
HW/OS -> All, Severity -> critical

Well, it's pretty serious anyway heh..
Comment 4 Mike Connor [:mconnor] 2004-08-29 09:30:49 PDT
If we've been shipping with this behaviour for a while, I doubt we'll block on this.
Comment 5 chris hofmann 2004-09-01 16:12:35 PDT
darin will take a look to see what we can do here.
Comment 6 chris hofmann 2004-09-01 16:15:10 PDT
if this can make PR it would be good.
Comment 7 Boris Zbarsky [:bz] (still a bit busy) 2004-09-01 17:06:41 PDT
This is a dup.
Comment 8 Christian :Biesinger (don't email me, ping me on IRC) 2004-09-02 04:39:21 PDT
happens in mozilla 2004090105/winxp too, -> browser
Comment 9 Daniel Veditz [:dveditz] 2004-09-07 16:23:45 PDT
On the surface this is sort of the opposite of bug 258048
Comment 10 Daniel Veditz [:dveditz] 2004-09-07 16:24:27 PDT
*** Bug 238566 has been marked as a duplicate of this bug. ***
Comment 11 Daniel Veditz [:dveditz] 2004-09-07 16:45:12 PDT
Are you sure this is a dupe? We've fixed similar bugs, but I can't find one
currently like this.

bug 240053 was fixed in Moz1.7 / ff0.9 (redirects)
bug 253121 was fixed in Moz1.7.2 / ff0.9.3 (onunload document.write)

bug 258048 describes an opposite situation, security indicators for the current
site stick around too long.
Comment 12 Darin Fisher 2004-09-08 15:47:50 PDT
Created attachment 158249 [details]
sample binary attachment
Comment 13 Darin Fisher 2004-09-08 15:51:33 PDT
Created attachment 158251 [details]
sample test case (view on non-secure server)

Load this attachment over plaintext HTTP.  Then, click the link named "click
me".  Notice that you get a download dialog and the lock icon is present on the
browser window, but the original page contents are still showing.
Comment 14 Darin Fisher 2004-09-08 17:30:18 PDT
I can reproduce this bug using Mozilla 1.0 and 1.4, so this has been around for
a long time.  I also don't see any evidence in the code that there was ever a
design intended to handle this case :-(
Comment 15 Darin Fisher 2004-09-08 18:03:59 PDT
Created attachment 158258 [details] [diff] [review]
v1 patch

OK, this seems like a safe patch.  The solution is to basically make retargeted
loads behave more like redirected loads as far as the webprogresslistener
notifications are concerned.

With this patch, we pass NS_BINDING_RETARGETED as the status code when calling
RemoveRequest from inside nsExternalAppHandler::RetargetLoadNotifications.  It
makes sense to pass an error code here because the load is actually not
successful with respect to loading inside the load group.  It is really pretty
wrong to say that the request has completed normally, which is what the current
code does.

The other change this patch makes is to cause the DocLoader to not synthesize a
STATE_TRANSFERRING event when the loadgroup calls its OnStopRequest method
(triggered from RemoveRequest).  This is what we currently do for redirected
requests, and it makes sense to do the same for retargeted requests.

One more thing to note: NS_BINDING_RETARGETED is not used anywhere else.  I
recall back in the day that it was used.  Used by code in uriloader land if I'm
not mistaken.  The fact that it is not used is good from the point of view of
this patch, since it means that we aren't co-opting an existing meaning for
this error code.
Comment 16 Boris Zbarsky [:bz] (still a bit busy) 2004-09-08 22:51:49 PDT
Comment on attachment 158258 [details] [diff] [review]
v1 patch

sr=bzbarsky if you also fix the similar code at
(which is retargeting from one docshell to another, but the effect is the
Comment 17 Darin Fisher 2004-09-08 23:48:54 PDT
Created attachment 158283 [details] [diff] [review]
v1.1 patch - with similar nsDocShell changes

thanks bz!
Comment 18 Darin Fisher 2004-09-08 23:55:00 PDT
Comment 19 Daniel Veditz [:dveditz] 2004-09-09 00:45:05 PDT
Needed on 1.7 also
Comment 20 Mike Kaply [:mkaply] 2004-09-09 05:36:28 PDT
Comment on attachment 158283 [details] [diff] [review]
v1.1 patch - with similar nsDocShell changes

a=mkaply for both
Comment 21 Bill Gianopoulos [:WG9s] 2004-09-09 09:36:33 PDT
Needed on Aviary also.
Comment 22 Darin Fisher 2004-09-09 10:43:48 PDT
fixed1.7.x, fixed-aviary1.0
Comment 23 Ben Sizer 2004-09-12 17:31:25 PDT
This isn't totally fixed, assuming it's supposed to be on my build (Firefox
branch, 20040912). I can't give out the test URL I see this on for copyright and
practicality reasons, but clicking a link hosted on
leading to an mp3 file hosted at still makes
livejournal's location bar go yellow and padlocked, and the status bar shows as being a secure site.

It seems possibly dependent on mime type as the behaviour seems fixed for zip
files on the secure server but still broken for mp3s.
Comment 24 logan 2004-09-12 17:45:25 PDT
Created attachment 158694 [details]
30kb mp3
Comment 25 logan 2004-09-12 17:49:05 PDT
Hrm, ok I'm not sure that worked right heh.. I was trying to make a testcase
with test.mp3, but the file is displaying in the browser.

Thought maybe if the content-type was being sent as text/plain, Firefox would
start out wanting to view the file, but once it sees binary data it'd change to
download instead.

I setup a test at work and didn't have any problems with content-type bits.
Comment 26 Ben Sizer 2004-09-12 18:46:30 PDT
Ok, that one worked fine for me too. Maybe it's something Comcast-specific.
Comment 27 Robert Parenton 2004-09-12 18:57:41 PDT
The testcase should work now.  A mimetype of application/octet-stream should
force Firefox to always ask to download.
Comment 28 Darin Fisher 2004-09-13 00:39:33 PDT
Hmm... I just downloaded the latest aviary branch build from
(Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20040910 Firefox/0.10), and I
couldn't reproduce the bug using the testcases at
Comment 29 logan 2004-09-13 07:15:32 PDT
(In reply to comment #26)
> Ok, that one worked fine for me too. Maybe it's something Comcast-specific.

Since you can't put up the urls, could you get the headers for the file that's
causing this?
Comment 30 Ben Sizer 2004-09-13 15:22:16 PDT
I don't know how to get the headers for an mp3 download. Page Info and the Web
Developer extension's 'view response headers' function don't work because the
page stays blank while it downloads in the download manager. Any suggestions?
Comment 31 logan 2004-09-13 15:44:57 PDT
There's lotsa ways to do this..

wget -sqO-

-(~) telnet 80
Connected to
Escape character is '^]'.
HEAD /some.mp3 HTTP/1.0

HTTP/1.1 200 OK

telnet won't work on an ssl-enabled server, so...

openssl s_client -connect
<send http request>

Or, you could even make a small libcurl or perl client. :P
Comment 32 Ben Sizer 2004-09-13 18:37:25 PDT
Interesting... :

HTTP/1.1 200 OK
Server: Netscape-Enterprise/4.1
Date: Tue, 14 Sep 2004 01:29:16 GMT
Content-type: text/plain
Last-modified: Mon, 13 Sep 2004 20:15:51 GMT
Content-length: 2740429
Accept-ranges: bytes
Connection: close

It's sending text/plain, yet it's definitely an mp3 file, and Firefox correctly
identifies it as such (giving me the save/open dialog) when I download it.
Comment 33 Ben Sizer 2004-09-16 08:04:11 PDT
Ok! I have a new testcase for you to try:
Click the mp3 link there, which leads to an mp3 file hosted on a Comcast server,
accessed with https. The actual/expected results are as I originally reported at
the start of this bug. I have just tested with a 20040916 branch build of
Firefox. Can anyone confirm this?
Comment 34 logan 2004-09-16 08:55:53 PDT
Man, I feel like a dumbass - Content-Type: test/plain

I've fixed my testcase and am able to see it now, must be due to the text/plain
[oh it's binary] stuff (bug 220807).

Comment 35 logan 2004-09-16 09:02:03 PDT
Ok, I can't get my bugzilla test.mp3 attachment to work right, I think it's
content-disposition: inline header, so we'll just have to rely on the external
Comment 36 Darin Fisher 2004-09-16 10:58:57 PDT
> Can anyone confirm this?

Yes, I can reproduce the problem too using the 9/14 aviary branch build w/ your
testcase.  Investigating...
Comment 37 Darin Fisher 2004-09-16 13:37:29 PDT
It looks like we are getting an OnProgress event prior to OnStartRequest when
loading  I think
that would explain the lock icon bug because the nsSecureBrowserUI uses the
OnProgress event to determine that secure content is being shown to the user. 

It looks like nsHttpChannel does not ensure that OnProgress occur only after
OnStartRequest.  There's a side issue since we use OnProgress to report upload
progress as well as download progress.  Clearly, nsSecureBrowserUI should only
apply its OnProgress logic to downloads, so we should verify that.
Comment 38 Darin Fisher 2004-09-16 15:07:48 PDT
ok, after further analysis i understand the problem.  the channel cannot solve
this problem.  it is in fact delaying OnProgress until after OnStartRequest, but
that is not enough.  in this case, the content-type from the server is
text/plain.    in this case we invoke a content sniffer to determine if the
content is really text because it is often the case that servers such as this
one are misconfigured.  the content sniffer requires data to be read from the
channel, which triggers the OnProgress notification.

to solve this problem i think we need to suppress sending
OnStateChange(STATE_TRANSFERRING) until after a load has been targetted.  this
only applies to toplevel loads with the LOAD_DOCUMENT_URI load flag.  one way to
do that would be to invent a new load flag that gets set by the
nsDocumentOpenInfo once it has targetted a load.  nsDocLoader::OnProgress would
then check for that load flag and suppress the OnStateChange call if the load
flag is not set (for the case in which LOAD_DOCUMENT_URI is set).

i discussed this plan with biesi over IRC and he agrees.  this seems like a more
robust fix that should help minimize the chance of this bug ever coming up again.

patch coming up...
Comment 39 Darin Fisher 2004-09-17 11:34:34 PDT
Created attachment 159229 [details] [diff] [review]
v2 patch

Here's a patch for the solution I mentioned.  I still need to document the load
flags used by the URILoader, DocLoader, and DocShell better.  That
documentation probably doesn't belong in nsIChannel.idl ;-)
Comment 40 Boris Zbarsky [:bz] (still a bit busy) 2004-09-17 11:51:58 PDT
Comment on attachment 159229 [details] [diff] [review]
v2 patch

>Index: uriloader/base/nsDocLoader.cpp
>-  nsLoadFlags loadFlags = 0;
>+  PRUint32 loadFlags = 0;

Why?  The loadFlags attribute of nsIRequest is of type "nsLoadFlags"...

>+    newLoadFlags = nsIChannel::LOAD_RETARGETED_DOCUMENT_URI;

This should be an |=, no?

sr=bzbarsky with those fixed (and perhaps the other GetLoadFlags callers also
using nsLoadFlags?)
Comment 41 Darin Fisher 2004-09-17 12:08:24 PDT
Created attachment 159235 [details] [diff] [review]
v2.1 patch - revised per bz's comments

nsLoadFlags vs. PRUint32 ... no good reason really.  much of necko uses
PRUint32 (despite nsIRequest.idl), and so I went with that here too.  But, I
don't care much either way, so I changed all of uriloader/base over to

Thanks for catching the |= mistake.  That's corrected in this patch too.
Comment 42 Christian :Biesinger (don't email me, ping me on IRC) 2004-09-17 12:33:03 PDT
Comment on attachment 159235 [details] [diff] [review]
v2.1 patch - revised per bz's comments

looks good
Comment 43 Darin Fisher 2004-09-17 13:33:39 PDT
Comment 44 Daniel Veditz [:dveditz] 2004-09-17 18:20:04 PDT
Comment on attachment 159235 [details] [diff] [review]
v2.1 patch - revised per bz's comments

a=dveditz for 1.7x contingent on aviary approval. Would like some trunk baking
Comment 45 Asa Dotzler [:asa] 2004-09-24 12:59:33 PDT
Comment on attachment 159235 [details] [diff] [review]
v2.1 patch - revised per bz's comments

a=asa for aviary checkin.
Comment 46 Darin Fisher 2004-09-24 16:13:12 PDT
fixed-aviary1.0 and fixed1.7.x for v2.1 patch
Comment 47 Christopher Aillon (sabbatical, not receiving bugmail) 2005-01-24 14:27:45 PST
Created attachment 172289 [details] [diff] [review]
Complete patch, backported to 1.4
Comment 48 Darin Fisher 2005-01-27 14:10:48 PST
Comment on attachment 172289 [details] [diff] [review]
Complete patch, backported to 1.4

>Index: uriloader/base/nsURILoader.cpp

>     }
>+    aChannel->SetLoadFlags(loadFlags | newLoadFlags);
>     const char* contentTypeToUse;

nit: no need for extra newline

>     if (helperAppService)
>     {
>+      // Set these flags to indicate that the channel has been targeted and that
>+      // we are not using the original consumer.
>+      nsLoadFlags loadFlags = 0;
>+      request->GetLoadFlags(&loadFlags);
>+      request->SetLoadFlags(loadFlags | nsIChannel::LOAD_RETARGETED_DOCUMENT_URI
>+                                    | nsIChannel::LOAD_TARGETED);
>       rv = helperAppService->DoContent(contentType.get(),
>                                        request,
>                                        m_originalContext,
>                                        getter_AddRefs(contentStreamListener));
>       if (NS_SUCCEEDED(rv) && contentStreamListener) {
>         m_targetStreamListener = contentStreamListener;
>+        request->SetLoadFlags(loadFlags);
>         return NS_OK;
>       }

I think it is wrong to call SetLoadFlags in the success case here.
The trunk does so in the failure case.
Comment 49 Darin Fisher 2005-01-27 14:24:51 PST
also, the last patch didn't include the definition of nsIChannel::LOAD_TARGETED.
Comment 50 Christopher Aillon (sabbatical, not receiving bugmail) 2005-02-14 14:23:42 PST
Created attachment 174321 [details] [diff] [review]
Backport for 1.4 take 2

addressing darin's comments.  I also think we need to null out
m_targetStreamListener (if DoContent() fails) looking at the current trunk.  It
seems like the correct thing to do here, what do you think darin?
Comment 51 Darin Fisher 2005-02-21 14:05:47 PST
Comment on attachment 174321 [details] [diff] [review]
Backport for 1.4 take 2

sure, this looks fine to me.  r=darin

Note You need to log in before you can comment on or make changes to this bug.