Closed Bug 28848 Opened 25 years ago Closed 24 years ago

Insecure gifs appear on secure page.

Categories

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

Product:
Core Graveyard
Component:
Security: UI
Version:
1.0 Branch
Platform:
x86
Windows NT
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED DUPLICATE of bug 47496

People

(Reporter: junruh, Assigned: javi)

References

Details

(Whiteboard: [nsbeta3+][pdtp1])

Icons from an insecure source appear on a https page. 1)With 4.7X, visit https://junruh.mcom.com/mix.html. 2)Notice that the gif file in the middle of the page does not appear. The gif file is from an http site, not an https site. 3)Start Netscape 6 and visit the site again. What happens: The gif file appears. What is expected: That the gif file would not appear, and would be a broken lock icon. Platforms tested: 2/18 WinNT and Linux.
This is the mix content test. Is hiding/not loading the gif required?
Summary: Insecure icons appear on secure page. → Insecure gifs appear on secure page.
targeting m16. If you reported this bug, and you would like to have it fixed sooner, please send me email. I will see what I can do. :-)
Target Milestone: M16
Someone asked if there is still a requirement to prevent insecure content from appearing on secure pages (where the lock is locked). I believe this bug is still fundamental - that non-secure content should not be displayed on a page where the lock appears locked. I think MOST of the folks in the security group agree with this. Someone in our group proposed that we drop this requirement, and there was much discussion about it, but AFAIK no resolution ever came to that discussion. So, in the absence of a conscious and deliberate decision to drop this requirement, I believe this requirement must still be met in Mozilla and especially in Communicator 6.
BTW, for frames we handle mixed content differently. If an https page contains multiple frames, and one or more of those frames came from an http (not https) URL, then we display the whole page, but with the lock unlocked. In effect, we downgrade the entire page, and treat it all like it was http content, not https content.
Yes, I suggested that we be a little more user friendly in displaying pages with images that come from non-secure sources. We already display a warning that the page has mixed content, and once the user has acknowledged this, I believe we should display the image. IE does this already. I won't revisit the whole discussion, but I don't think there is any reason to disturb the display of the page after issuing the warning.
Blocks: 13785
I agree that this is no big deal. If someone goes to the trouble of setting up an https site, and then puts http icon content in it, that is just bad security (if the icon is signifcant to the security of the page). We don't stop folks from posting the credit cards and user info that they "securely" acquire via https. They have to be good about security beyond the https link. IMO, there is much more of a chance that we'll be given negative points for not (as terry describes it) being user friendly. Broken gifs look like we messed up, as most folks can't distinguish browser, from server, from content. IMO, tracking IE on this is just fine.
Jim, If we allow insecure content to be displayed while the lock is locked, then what does the lock mean? I say it means nothing. The typical user has no way of knowing what content was received securely and which wasn't. Perhaps the user's sensitive security info was sent insecurely. The lock would no longer assure that it wasn't. I predict that if we allow it, users will find themselves looking at http pages whose content is almost entirely insecurely sent. Most merchants don't really want seecurity, they want the users trust. We've trained the users to see the lock and trust the security. If the lock isn't actually tied to secure content, then it might as well become a new html tag <lock>.
nelson, in the case of a gif from a insecure site, our proposal is to (a) Warn the user, (b) set the lock to the 'broken' state, and (c) display the image unadulterated.
based on Jar's comment --> m20
Target Milestone: M16 → M20
Reassigning to javi during dougt's absence for the next three weeks.
Assignee: dougt → javi
Blocks: 48444
Can this not be closed INVALID?
If the lock icon appears as a mixed content icon at mixed content sites, and insecure gif files appear displayed on screen, that's OK with me. More comments, jar and nelsonb?
This bug is most certainly not invalid. SHeesh.
Adding nsbeta3 keyword.
Keywords: nsbeta3
Q: Is this bug going to get fixed for Beta 3? or not?
It's not marked nsbeta3+ and not a P1 or P2, so the answer is no it won't be fixed for PR3
Since it is marked beta3, but no beta3-plus or minus, it has not yet been triaged by a manager, and also probably not yet been given a proposed priority (P3 is default). IMO, when it is triaged, it will get P3 or lower, and will probably not be fixed for beta3, or probably RTM. Sites with "poor security" can put non-HTTPS gifs on their HTTPS pages, and "weaken" their security. Such sites can also do other things poorly from a security perspective, such as echo back your credit card numbers via email, etc. etc. We really can't diagnose all the bad ways that comercial sites can destroy privacy, and I've always argued that good sites would not mix insecure gifs if they had any security impact (but it sure is nice to be able to put non-SSL gifs in when they have no security impact!) Botom line: IMO, this is not a stopper bug... but I'm certainly willing to hear what I'm missing (yes, I know that in 4.x there is a warning, courtesy of the unlock icon). Thanks, Jim
If we're not going to fix this bug, then the lock icon is completely ambiguous. It means only that "some part of this page used SSL", but provides no clues about what parts. I predict people will start having https framesets that include only http frames. The lock will appear locked and they won't have to suffer any SSL-related performance penalty. Somewhere there's a P1 bug about the lock icon not appearing to be locked/unlocked at the right times. IMO, that bug has no higher priority than this one.
I like Doug T's suggestion from last March. I think this bug can be viewed as yet another case where the lock icon appears locked when it shouldn't.
Blocks: 31344
There is another bug just like this. It's 47496. Both deal with the lock icon showing locked on mixed content sites. While I agree with Jar that we can't protect users from sloppy sites, we can give them good information where we have it. I think that this bug should be plussed with a priority of P1 (for security reasons) to not show a locked icon when there is mixed content on the page. Making it so. Now I know that I'm probably missing something, so let the comments fly.
Priority: P3 → P1
Whiteboard: [nsbeta3+][pdtp1]
This bug is for the exact same thing as 47496 *** This bug has been marked as a duplicate of 47496 ***
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
Verified dupe.
Status: RESOLVED → VERIFIED
Mass changing Security:Crypto to PSM
Component: Security: Crypto → Client Library
Product: Browser → PSM
Version: other → 2.1
Mass changing Security:Crypto to PSM
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.