Opened 6 years ago

Last modified 3 years ago

#3777 accepted defect

Should not generate mixed-content warnings if rewriting all http to https

Reported by: josh Owned by: pde
Priority: Medium Milestone:
Component: HTTPS Everywhere/EFF-HTTPS Everywhere Version:
Severity: Keywords: AffectsTails
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

As far as I can tell, Firefox produces mixed-content warnings on an https page that references resources (images, scripts, etc) via http, even if HTTPS Everywhere can rewrite all of those http URLs to use https. (HTTPS Everywhere does rewrite resource requests, right?)

Ideally, if HTTPS Everywhere successfully rewrites every http request from a page to an https request, the page should not generate a mixed content warning. (Though I'd still like to see some indication that the page was only secure due to HTTPS Everywhere, so I know to report the insecure resources to the site owner.)

Child Tickets

TicketStatusOwnerSummaryComponent
#7575newpdeWebAssign site produces litany of "Security Warning" alertsHTTPS Everywhere/EFF-HTTPS Everywhere

Change History (4)

comment:1 Changed 6 years ago by pde

Status: newaccepted

We will need a patch (or at least help from people who know about the XPCOM structure of the mixed content warnings) to deal with this.

In terms of the indication that HTTPS Everywhere kept the site secure, that is theoretically the difference between the two shades of green you see for rulesets in the HTTPS Everywhere toolbar button. In the current implementation, sometimes rulesets are downgraded from the strong green "kept this page secure/prevented mixed content" to the pale green "would have secured this page if necessary" because of changes in the page's top-level URL. Typing www.google.com into the URLbar gives an example of this problem.

Ideally we should get a better implementation of these indications in the toolbar menu, and we should change the colour of the icon for the toolbar menu according to what's going on with the rulesets inside it.

comment:2 Changed 4 years ago by MB

This is causing security.mixed_content.block_active_content to block all 'active' resources that are secured by us, but would not otherwise be fetched via https. Needlessly to say, this could be a problem for Firefox 23.

comment:3 Changed 3 years ago by cypherpunks

Keywords: AffectTails added

comment:4 Changed 3 years ago by cypherpunks

Keywords: AffectsTails added; AffectTails removed
Note: See TracTickets for help on using tickets.