Opened 2 years ago

Closed 2 years ago

#5676 closed defect (fixed)

HTTPS rewriting is bypassed if DNS root is explicitly specified

Reported by: NYKevin Owned by: pde
Priority: critical Milestone:
Component: EFF-HTTPS Everywhere Version:
Keywords: Cc: mikeperry, aaronsw
Actual Points: Parent ID:
Points:

Description

If you go to a URL such as http://www.google.com./ HTTPS-Everywhere will *not* switch to HTTPS. This is a legal DNS value, technically but not practically distinct from http://www.google.com/ 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 2 years ago by pde

  • Priority changed from normal to critical

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

comment:2 Changed 2 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 2 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 2 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 2 years ago by pde

  • Owner changed from pde to dtauerbach
  • Status changed from new to assigned

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 2 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: https://git.eff.org/?p=dan/https-everywhere.git;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 2 years ago by pde

  • Resolution set to fixed
  • Status changed from assigned to closed

The chrome fix shipped in 2012.5.1

Note: See TracTickets for help on using tickets.