Closed Bug 140837 Opened 22 years ago Closed 8 years ago

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

Categories

(Core Graveyard :: Security: UI, defect)

Product:
Core Graveyard
Component:
Security: UI
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: KaiE, Unassigned)

References

(Blocks 1 open bug,
URL
)

Details

(Whiteboard: [psm-padlock])

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.
Blocks: lockicon
kai.
Assignee: ssaux → kaie
Keywords: nsbeta1+
Priority: -- → P2
Whiteboard: [atd2 RTM]
Target Milestone: --- → 2.3
In-house test page added above with secure and insecure pages and links.
URL: https://pki.mcom.com/frames.html
adt3. This is an edge case.
Whiteboard: [atd2 RTM] → [atd3 RTM]
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.
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.
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.
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.
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.
Blocks: 149207
Target Milestone: 2.3 → 2.4
Whiteboard: [atd3 RTM]
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>
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
Version: unspecified → 2.4
Verified WFM.
Status: RESOLVED → VERIFIED
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.
Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---
Summary: https surfing: Pages with frames will not reset lock icon from broken to mixed → https surfing: Pages with frames will not reset lock icon from broken to secure
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)
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.
Product: PSM → Core
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.
See bug 246448 comment 6 if you're wondering what I'm talking about.
Thanks for your comment Jesse. Your suggestion, to never switch that frame back, when changing subframe documents only, sounds reasonable to me. Marking WONTFIX.
Status: REOPENED → RESOLVED
Closed: 22 years ago → 19 years ago
Resolution: --- → WONTFIX
Version: psm2.4 → 1.0 Branch
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.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Summary: https surfing: Pages with frames will not reset lock icon from broken to secure → https surfing: Pages with frames will not reset lock icon from mixed to secure
Assignee: kaie → nobody
Whiteboard: [psm-padlock]
QA Contact: junruh → ui
Priority: P2 → --
Target Milestone: psm2.4 → ---
Version: 1.0 Branch → Trunk
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 :)
I agree with Jesse.
Status: REOPENED → RESOLVED
Closed: 19 years ago → 8 years ago
Resolution: --- → WONTFIX
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.