Opened 6 years ago

Closed 5 years ago

#7871 closed defect (user disappeared)

HTTPS breaks redirect for ATT Wifi "Hotspots"

Reported by: cypherpunks Owned by: pde
Priority: Medium Milestone:
Component: HTTPS Everywhere/EFF-HTTPS Everywhere Version: HTTPS-E 3.1
Severity: Keywords: httpse-ruleset-bug
Cc: ted.l.wood@… Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

When HTTPS Everywhere is enabled and you try to access the web via an "attwifi" hotspot you are redirected to their "Terms of Service" page from the URL you type in to the URL bar. This redirect does not work as expected until you disable the HTTPS Everywhere plugin. I believe this may just a rule that needs to be added in order to disable redirection for "*.wayport.net" but I do not have the technical skill necessary (or so it seems) to write the rule myself.

Child Tickets

Change History (7)

comment:1 Changed 6 years ago by pde

We'll need to figure out whether this is simply an instance of the <a href="https://eff.org/https-everyhwere/faq#captiveportal">captive portal</a> problem, or whether it's a problem with a particular ruleset.

Do you think you might be able to try joing one of these networks with the "AT&T (partial)" ruleset disabled?

comment:2 Changed 6 years ago by cypherpunks

I did not see this rule when I was searching but I was not looking for AT&T. I will attempt to locate the rule, disable it and try again next time I'm out.

comment:3 Changed 6 years ago by cypherpunks

I just tried to disable the AT&T (partial) rule as requested and I do not see such rule in the rules list. I also checked for American Telephone and Telegraph but did not find anything like that either. Is there an updated rules set that I do not have installed?

comment:4 Changed 6 years ago by mikeperry

Keywords: httpse-ruleset-bug added

comment:5 Changed 6 years ago by pde

Sorry, it looks like the AT&T ruleset is only in the master (4.0development) branch.

comment:6 Changed 6 years ago by schoen

Status: newneeds_information

I suspect this is the captive portal problem. There's no rule that applies to wayport.net... but the captive portal problem tends to produce exactly this kind of behavior.

To the original reporter, could you try using yahoo.com or sfgate.com instead of whatever site you're currently typing in to the browser? Those are sites that definitely won't be redirected to HTTPS, so if the problem is about captive portals, they should work to cause the AT&T portal page to come up with no error.

comment:7 Changed 5 years ago by bm

Resolution: user disappeared
Status: needs_informationclosed
Note: See TracTickets for help on using tickets.