Opened 9 years ago

Closed 8 years ago

#5676 closed defect (fixed)

HTTPS rewriting is bypassed if DNS root is explicitly specified

Reported by: NYKevin Owned by: pde
Priority: Very High Milestone:
Component: HTTPS Everywhere/EFF-HTTPS Everywhere Version:
Severity: Keywords:
Cc: mikeperry, aaronsw Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


If you go to a URL such as HTTPS-Everywhere will *not* switch to HTTPS. This is a legal DNS value, technically but not practically distinct from and as such, it should be handled similarly.

On the other hand, it is sometimes useful to have an "escape hatch" to disable HTTPS rewriting for just one pageload (e.g. Google's doodles don't show under HTTPS in my experience). However, that hatch ought to have better affordances if it's to continue existing at all. As it is, this is potentially a social engineering vulnerability (although I'm not sure how practical such a hypothetical attack might be; it would probably need to be targeted at a particular individual).

Child Tickets

Change History (8)

comment:1 Changed 9 years ago by pde

Priority: normalcritical

This is a serious security vulnerability.  Thank you for reporting it!

comment:2 Changed 9 years ago by pde

(it would allow an active attacker to perform Firesheep-style cookie stealing accounts against sites that HTTPS Everywhere protects with domain-wide redirects, if the ruleset does not also have a <securecookie> directive)

comment:3 Changed 9 years ago by pde

Cc: mikeperry aaronsw added

This bug also exists in the Chromium port, and will need to be fixed separately there.

comment:4 Changed 9 years ago by mikeperry

Oh wow. Nightmare.

I guess the best thing is to change how we evaluate regular expressions to allow an optional period at the end of every host? Or maybe just temporarily remove it before applying any rules (and put it back later?)

comment:6 Changed 9 years ago by pde

Owner: changed from pde to dtauerbach
Status: newassigned

This has been fixed in version 3.0development.2 and 2.0.3 of the Firefox code.  We still need a chromium fix.

comment:7 Changed 9 years ago by dtauerbach

Owner: changed from dtauerbach to pde

For a fix for chromium, see the last 2 commits of the convergence-integration branch of public git repo here and merge at your convenience:;a=shortlog;h=refs/heads/convergence-integration. One caveat: I couldn't track down a place where the userpass code changes were activated. Using basicauth worked for several sites but I was unable to test one where a rewrite rule was active. Do you have such an example available?

comment:8 Changed 8 years ago by pde

Resolution: fixed
Status: assignedclosed

The chrome fix shipped in 2012.5.1

Note: See TracTickets for help on using tickets.