Opened 6 years ago

Last modified 3 years ago

#15763 reopened defect

Need whitelist entry for and

Reported by: bit0mike Owned by:
Priority: Medium Milestone: HTTPS-E next Chrome release
Component: HTTPS Everywhere/EFF-HTTPS Everywhere Version:
Severity: Normal Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


Short version: HTTPS Anywhere now breaks many form submissions on and, and we need a whitelist rule.

Longer version: our desktop site's ads cannot load over HTTPS, so we have to unfortunately run that site HTTP to avoid mixed-content warnings.  Google's ad team, and third party ad networks, apparently don't have the same urgency as Google's Chrome team when it comes to encouraging HTTPS use...

We do now have a way to pay a small monthly amount to turn ads off yet still support the site (BareFark), and anyone that buys that gets an SSL version of the site as a perk, and is forcibly redirected to it if they hit it via plaintext.  To make ads work though, we have to push everyone else back to the plaintext version.

Unfortunately, this combined with HTTPS Anywhere breaks our Post-Redirect-Get form submission logic.  The POST always goes to HTTPS, caches the form variables, then redirects to a GET which then retrieves those variables (and clears the cached version to avoid double-submits).  HTTPS Anywhere then tries to redirect that GET back to an HTTPS version, which causes the form variables to be lost and the overall POST to fail.  Sad trombone.

Fortunately our mobile ad networks don't have the limitation of being HTTP-only, so, we do NOT need a whitelist rule for,, or our images host  We already forcibly redirect all mobile hits over to HTTPS, though we aren't quite yet using HSTS to do it.  (See, we're at least trying...)

Child Tickets

Change History (9)

comment:1 Changed 6 years ago by bit0mike

OK, ignore the part where I mistyped "HTTPS Anywhere" instead of "HTTPS Everywhere".  Or if I put this in the wrong ticket queue.  Derp!

Also, if there is some kind of header I can send to tell HTTPS-Everywhere to lay off and that I really do know what I'm doing by forcing HTTP on occasion, kinda like an HSTS header in reverse, that would be awesome, because then I can remove it at our end when we're no longer forced to do that.

comment:2 Changed 6 years ago by jsha

Resolution: fixed
Status: newclosed

Hi Mike! Thanks for working on HTTPS for Fark. BTW, did you see Google's recent announcement that they'll be supporting HTTPS for ads? Hopefully that will help.

I've disabled the Fark rule for now. When you've got HTTPS working better, it would be awesome if you could re-enable the rule (it's at Or just file another issue and we'll bring it up to date.

comment:3 Changed 6 years ago by bit0mike


I did see that, though if I remember right, it was more a "can" do HTTPS than a "must", and it's still a ways off.  Less helpful, short term.  :p

comment:4 Changed 3 years ago by bit0mike

Resolution: fixed
Severity: Blocker
Status: closedreopened

Digging this 3 year old ticket back up to report that enough ad networks are on board with SSL that we finally were able to cut everything over at long last.

One new exception: we still have cases where we iframe external plaintext sites, so the containing page must obviously also be plaintext, and so we’ve created a new hostname dedicated to that. That one is port 80 only, no 443 at all.

Everything else under * and * EXCEPT for is now SSL, and sets an HSTS header to enforce it. will never support SSL, so that needs to stay blacklisted.

So that should, uh, drastically simplify or eliminate the ruleset, yes? White

comment:5 Changed 3 years ago by cypherpunks

Hi, thanks a bunch for following up with this!

Your almost complete switch to HTTPS does not eliminate the need for a rule in HTTPS Everywhere. HTTPS Everywhere still adds an additional protection against attacks such as SSLstrip. Also, as opposed to HSTS, it does not rely on a trust on first use scheme.

The only equivalent protection would be to HSTS preload the entire domain but that's not an option here since you said that some subdomains don't/won't support HTTPS.

The best move here would be for you to edit the ruleset yourself. Simply add a target for each subdomain that supports HTTPS. More information is available in our contributing guide:

Otherwise, I can edit this ruleset for you but it would simplify things a lot if you could provide me with a complete list of subdomains that support HTTPS.

Last edited 3 years ago by cypherpunks (previous) (diff)

comment:6 Changed 3 years ago by bit0mike

HTTPS domains would be all of the subjectAltNames in the certificate, plus one we're planning to add later. So that'd be:

<target host="" /> <!-- redirects to -->
<target host="" />
<target host="" />
<target host="" />
<target host="" />
<target host="" />
<target host="" />
<target host="" />
<target host="" />
<target host="" />
<target host="" />
<target host="" />
<target host="" /> <!-- will be added later this year, so might as well throw it in there -->
<target host="" />
<target host="" />
<target host="" />

Then would be the only one to exclude.

Oh, and it should also be OK to do this now:

<securecookie host=".+" name=".+" />

comment:7 Changed 3 years ago by cypherpunks

Severity: BlockerNormal

comment:8 Changed 3 years ago by cypherpunks

Thank you!

We will have to wait to add, we don't usually add non-functional subdomains.

Also, times out. Do you have an example of a working URL for this subdomain?

comment:9 Changed 3 years ago by bit0mike

Wait, I'm a complete idiot. is email only, no HTTP or HTTPS. (That's why we're changing the name... next time the cert's up for renewal.) Take both of those off the list. Sorry.

Note: See TracTickets for help on using tickets.