Closed Bug 552286 Opened 15 years ago Closed 8 years ago

SSL indicator is only disabled when an external unsecured object is completely loaded

Categories

(Core Graveyard :: Security: UI, defect)

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

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: jordi.chancel, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: sec-low, Whiteboard: [sg:low] [psm-padlock])

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; fr; rv:1.9.2) Gecko/20100115 Firefox/3.6 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; fr; rv:1.9.2) Gecko/20100115 Firefox/3.6 Firefox disables SSL indicator when an external object is loaded (Object on an other HTTP_website ). But when an external object(like flash) is loaded , SSL indicator is only broken after its complete loading. It 's possible to stop the complete loading of this external Object and so to keep a valid SSL indicator. Reproducible: Always Steps to Reproduce: 1.Create an html file on a HTTPS_Adress with a external Adobe_Flash(HTTP://xxx/flash.swf) object on the <body>. 2.use Stop(); before its complete loading Actual Results: it is possible to send data to another HTTP_Adress and keep a valid SSL certificate.
Summary: SSL indicator is only disables when an external unsecured object is completely loaded → SSL indicator is only disabled when an external unsecured object is completely loaded
Blocks: lockicon
Group: core-security
Whiteboard: [sg:low]
Mass change owner of unconfirmed "Core:Security UI/PSM/SMime" bugs to nobody. Search for kaie-20100607-unconfirmed-nobody
Assignee: kaie → nobody
Whiteboard: [sg:low] → [sg:low] [psm-padlock]
Assignee: nobody → jwein
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
I have confirmed this bug exists by visiting the file located at this URL: https://people.mozilla.org/~jwein/bugs/552286.html and using Fiddler2 to block the response from www.eastlansingrentals.com. The site identity block stays valid until the response is allowed to pass through.
It looks like the SSL status is set to broken after the handshake callback here: http://mxr.mozilla.org/mozilla-central/source/security/manager/ssl/src/nsNSSCallbacks.cpp#848 but does HTTP have a handshake callback? It should probably be set to broken when it sends out the request to an HTTP server (non-HTTPS). bsmith: Can you give me some tips on where these changes would need to be made?
(In reply to Jared Wein [:jwein and :jaws] from comment #3) > It looks like the SSL status is set to broken after the handshake callback > here: > http://mxr.mozilla.org/mozilla-central/source/security/manager/ssl/src/ > nsNSSCallbacks.cpp#848 > > but does HTTP have a handshake callback? It should probably be set to broken > when it sends out the request to an HTTP server (non-HTTPS). > > bsmith: Can you give me some tips on where these changes would need to be > made? (IMO,) the path here is to block all insecure requests, until allowed by consent from a user. There is already bug 62178, quit old, that is being worked on currently.
Assignee: jAwS → nobody
Status: ASSIGNED → NEW
I can't reproduce this - loading the page in comment 2 results in the mixed content treatment, even if the resource that is served over http is never actually loaded.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.