140837 - https surfing: Pages with frames will not reset lock icon from mixed to secure

Status: RESOLVED WONTFIX

(Core Graveyard :: Security: UI, defect)

Description

[Kai Engert [:KaiE:]]

Go to a page loaded over https that uses frames.
Make sure the site uses links, where clicking on a link does not cause a new
toplevel document to become loaded, but only the content of one frame to change.

If during surfing, you ever encounter a page that has a broken security, or no
security at all, this will lead the overall page security status to go to
"mixed" and a broken lock icon will be shown. This is expected behaviour to my
understanding.

However, suppose only one of the displayed frames is insecure, and you navigate
that frame to a secure page.

Expected behaviour: The page security status should return to "secure", because
all content is secure again.

Actual behaviour: The page security status remains to be shown as mixed/broken.

Because of bug 140836, it is currently possible to see this state, even if all
content was transfered securely.

Technical explanation for this behaviour: The current implementation does not
track the state of all displayed frames independently. Instead, it uses global
count variables to count the number of insecure subpart items. These counts are
not being reset while a user navigates from frame to frame, but only when the
toplevel frameset document changes.

Comment 1

[Stephane Saux]

kai.

Comment 2

[John Unruh]

In-house test page added above with secure and insecure pages and links.

Comment 3

[Stephane Saux]

adt3. This is an edge case.

Comment 4

[Katsuhiko Momoi]

Why is this an edge case? If I am not mistaken, one of the major banks
I deal with in Japan has this problem with many of their pages. 

According to them, it is very common for users to get imaptient and
start clicking on load buttons which may produce unmatched frames:

A & B -- matched frames
C & D -- matched frames
E & F -- matched frames

Waiting for B to load, the user impatiently clicks on a button for C, which 
loads D but the frame is still A. 

I am wondering if my understanding of this case is different from
yours.

Comment 5

[Stephane Saux]

We don't get a log of duplicate of this bug. So yes, it can happen, and yes, if
we had infinite resources, we'd fix it.  Is it a stop ship?

From the security standpoint, it's also a false negative. We don't say that the
site is secure when it isn't (which would be a stop ship).  We occasionally say
we're mixed, when we may not be (we don't know, and in order to know we'd need a
fix for 130949).

So, we have to allocate our resources to other bugs that we've estimated to be
more important.

Comment 6

[Kai Engert [:KaiE:]]

Katsuhiko: From what I understand from your emails to me, the "impatience" issue
should be bug 140836 (not this one).

This bug only tracks the problem, where the website actually really uses
non-secure http URLs.

I think, what you described to me are websites, where all pages and links are
https. I think you only see a mixed lock icon on those sites because of bug 140836.

Comment 7

[Katsuhiko Momoi]

Additional info: all frames use https protocol in this problem.

One frame (upperone typically) may be using low-grade encryption
while the lower frame (content) uses high-grade encryption.

Upper frames contain buttoned links to various lower frame contents.
Each content frame has matching upper buttoned links page. (i.e. typical
bank page with a menu at the top for navigation and content loading at 
the lower frame).
Each content frame loads the mtaching buttoned links frame using onLoad.

The problem seems to happen when the user seeing that the content is
not loading clicks on another button at the upperframe thus loading
another lower content frame but somehow slow network connection
prevents reloading the upper button links frame. In this case,
you end up with an umtached content (lower frame) and buttoned links
(upper frame).

Apparently the problem is observed in this case.

Hopefully this problem is fixed by the change in lock icon behvaior. 
I am sking the customer to re-test with the new lock icon behvaior
fix in it.

Comment 8

[Kai Engert [:KaiE:]]

momoi: I'm very hopeful that in your described problem you will not see a broken
lock icon, because both bug 140836 and bug 150863 have been fixed.

Comment 9

[John Unruh]

Marking works for me with the above in-house URL. The lock icon appears mixed.
Try creating an html file on a secure server with this code:
<html>
 <head>
    <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
    <meta name="GENERATOR" content="Mozilla/4.5 [en] (Win95; U) [Netscape]">
    <title>Frame Test</title>
 <frameset COLS="50%,50%">
 <frame SRC="https://www.verisign.com">
 <frame SRC="http://www.verisign.com" NAME="home">

 </frameset>
 </head>
 <body>
 &nbsp;
 </body>
 </html>

Comment 10

[John Unruh]

Verified WFM.

Comment 11

[Kai Engert [:KaiE:]]

I'm sorry, the bug summary is misleading. Please look at the initial bug
description. That is what I meant to say. I'm changing the summary.

I believe this bug is not yet fixed. When you surf a page with multiple frames,
when you had temporarily viewed an insecure page in one frame, but you go back
to a secure page in that frame, resulting in a situation where all shown frames
are again secure: The lock icon should go to secure again.

Comment 12

[Greg May]

I have a problem with this site https://www.encrypt.standardbank.co.za/jb2/ (top
South African Banking Site)

I believe the main frame does not get updated because of this bug. 
The left (menu) , top and bottom frames are displayed, while the main frame does
not get updated.
(Main frame displays "Loading menu, please wait...")


The site has the following comments about IE (yuk).

Is the connection secure if you click the padlock icon to view the certificate
when connected to a secure site, and receive the following error message: "This
certificate has failed to verify for all of its intended purposes."
Yes the connection is secure and Microsoft has the following comments about the
error message:

Cause

This can occur if Internet Explorer interprets a specific object ID in the
contents of some Server Gated Cryptography (SGC) certificates.

Resolution

This affects only the user interface; Internet Explorer still communicates by
using the secure connection. If you click the Certificate Path tab in the dialog
box, you see the message "This certificate is OK" in the Certificate Status box.

For more information visit the Microsoft or VeriSign site:
http://support.microsoft.com/support/kb/articles/Q233/4/79.ASP
http://www.verisign.com/support/tlc/known_issues.htm#ie5


Hope this helps
Mozilla rules but this one little problems is forcing me to use M$ (urgh)

Comment 13

[Kai Engert [:KaiE:]]

Greg, I believe what you report is a different problem and should be tracked in
a separate bug. The effects that are described in this bug should not prevent
anything from getting loaded, as you report it happening with your banking site.

Comment 14

[Jesse Ruderman]

This is not a bug.  If you have ever opened an http URL in one of the frames, an attacker can control the URLs of all frames (and can choose https URLs), so the page should still be indicated as only partially encrypted.

Comment 15

[Jesse Ruderman]

See bug 246448 comment 6 if you're wondering what I'm talking about.

Comment 16

[Kai Engert [:KaiE:]]

Thanks for your comment Jesse. Your suggestion, to never switch that frame back, when changing subframe documents only, sounds reasonable to me. Marking WONTFIX.

Comment 17

[Jesse Ruderman]

Comment 14 is wrong now, thanks to the frame navigation restrictions adopted in bug 408052.

In general, it might be sensible to allow going from "mixed-display" to "secure". That means images and iframes, mostly.

Comment 18

[Jesse Ruderman]

The one frame that loaded the http URL is still under attacker control, though.  So the attacker could choose which https URL is loaded in that frame.  I think the "mixed display" state should be permanent in this case.

But I also think "mixed display" should not carry as extreme a warning as it does today :)

Comment 19

[Dana Keeler (she/her) (use needinfo) [:keeler]]

I agree with Jesse.