Opened 9 years ago

Closed 6 years ago

#3971 closed defect (wontfix)

HTTPS-Everywhere does not encrypt all traffic from web site

Reported by: joyton Owned by: pde
Priority: Low Milestone:
Component: HTTPS Everywhere/EFF-HTTPS Everywhere Version:
Severity: Keywords:
Cc: jcrimby@… Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

To whom it may concern,

I wrote a few rule sets for HTTPS-Everywhere (I'd rather not list which rule sets I wrote) and one of the sites I wrote rules for is not wholly encrypted. The problem is adds on the web site, which are hosted elsewhere (I think) and are not using SSL.

Ex: I visit site XYZ.com with TBB and while site XYZ.com is on HTTPS, I get a dialog box warning that not all traffic is encrypted. This is due to adds running on site XYZ.com, I assume.

I wrote AdBlock Plus filters for site XYZ.com, to block the loading of all off-site adds, which appear on site XYZ.com. While the adds no longer load, I still get the warning about unencrypted traffic.

Can HTTPS-Everywhere be made to block all non-HTTPS traffic on a site for which there are HTTPS-Everywhere rules sets?

Child Tickets

Change History (8)

comment:1 Changed 9 years ago by pde

Theoretically you could write a ruleset that covered the advertising domain, that rewrites http:// requests to some place that is non-existant/harmless.

Perhaps you would only want that ruleset to trigger in the context of XYZ.com pages, which would require new ruleset semantics.

Initially I'm more inclined to recommend that people use AdBlock Plus alongside HTTPS Everywhere, than to try to start adding ABP-like functionality to our codebase. But I'm open to arguments about why we should.

comment:2 Changed 9 years ago by pde

Priority: majorminor

comment:3 Changed 9 years ago by joyton

Good day pde,

It didn't dawn on me to break the ad requests like that, I'll give it a try. After I wrote the AdBlock Plus rules I found ABP does not really block the connection with the ad, it merely blocks the loading of the ad by Firefox. The way the ABP main dev explained it to me, is that ABP is a 'cosmetic' add-on, not a security add-on, per se. ABP is meant to block loading of annoying ads by Firefox, not block connection to said annoying ad by Firefox. I can probably find the thread where he and I discussed this topic some months ago, if you're interested.

So it seems like ABP is a no-go with respect to this ticket. That is, even with ABP filters in place HTTP (to ads host) is not blocked, the ads are merely not shown by Firefox, even though they are really still there. At least that is my understanding after contacting the ABP main dev. I could be ignorant though ... if so, please enlighten me.

I'm not sure if it's even possible, but I think it would be useful to have some type of setting in HTTPS-Everywhere akin to "block any traffic that is not HTTPS for sites with rulesets". Such a global action would probably make HTTPS-Everywhere more secure, but may also break some sites by blocking connection to off-site hosted ads and images and such. Maybe a more fine grained approach would be better, that is, site-by-site setting, but there are so many sites in HTTPS-Everywhere a site-by-site setting may be a non-starter.

These are just my (slightly) incoherent ramblings, those of someone who is not a computer whiz. Thus, please correct me where you see fit. Thanks.

comment:4 Changed 9 years ago by joyton

Talk about funny timing ...

I just downloaded and unpacked the most current version of TBB for Windows with Tor v0.2.2.32. I went to the AdBlock Plus home page () to search for the thread I wrote about in my previous post, and low and behold I got a warning that the web page is loading unencrypted traffic(!). So it seems HTTPS-Everywhere ruleset for ABP web site has the same limits as the rulesets I wrote ...

(I'm unsure how to post screenshots with this trac software)

comment:5 Changed 9 years ago by joyton

Edit:

ABP homepage = https://adblockplus.org/en/

comment:6 Changed 9 years ago by joyton

pde,

While logging into a Yahoo! Mail account today (https://login.yahoo.com/config/login?), with a fresh Tor Browser (v2.2.32-4) and AdBlock Plus*, I again got the same HTTP warning from Tor Browser (Firefox-Aurora).

I'm not computer whiz, but to me if HTTP is used on a web page/site with HTTPS-Everywhere rulesets then something is not kosher. Especially because use of AdBlock Plus does not fix the problem, and the problem is on major sites like Yahoo! Mail.

Are you still of the mind this isn't a problem HTTPS-Everywhere should be concerned with? That is, this isn't under HTTPS-Everywhere's 'domain'? If not, do you think this ticket (bug) deserves a higher priority then minor? I wonder type of data is on HTTP, ex., passing through my exit node while I'm trying to log into Yahoo! Mail via HTTPS ...

So far I have found three sites that use HTTP when HTTPS-Everywhere rulesets are in place. And I didn't go looking for such sites, all three sites are very popular (the site for which I wrote rulesets ranks in the top 10 web forums in the world, in terms of members and traffic):

  1. Yahoo! Mail [ https://login.yahoo.com/config/login? ]
  2. AdBlock Plus [ https://adblockplus.org/en/ ]
  3. Web site for which I wrote rulesets
  • I use the following AdBlock Plus custom filters and filter subscriptions:
EasyPrivacy+EasyList
Antisocial
Malware Domains
Custom filters:
google-analytics.com^$third-party
filters for the site for which I wrote HTTPS-Everywhere rules.

comment:7 Changed 9 years ago by pde

With respect to the warning messages, there are some known cases where HTTPS Everywhere secures form submissions, but the error message still occurs (it tigers before our code can rewrite the request).

Certainly we'd want to help in whatever way we can with securing XYZ.com, but it's a bit hard for us to look at the situation more closely and figure out the best strategy when we don't know what XYZ.com actually is :).

comment:8 Changed 6 years ago by jsha

Resolution: wontfix
Status: newclosed

Firefox no longer warns as obtrusively on mixed content. If an HTTPS Everywhere rewrite causes passive or active mixed content but doesn't break a page we usually leave it on.

Note: See TracTickets for help on using tickets.