New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 1 user
Status: Fixed
Owner:
Closed: Sep 2015
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug


Participants' hotlists:
HSTS-Preload


Sign in to add a comment
Need my site delbart.se to be removed from the HSTS preload list
Reported by jensfili...@gmail.com, Sep 3 2015 Back to list
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.85 Safari/537.36

Steps to reproduce the problem:
1. Visit Delbart.se in your browser
2. Site will be stuck in an redirection loop
3. 

What is the expected behavior?
To load the site over http instead of https

What went wrong?
My developers advised me to activate the HSTS header on my site, because we moved the whole site to SSL.

A month into the project, we realised that SSL made our ad income significantly lower, since lot's of the premium advertisers in my country apparently isn't providing secure scripts.

This is what I do for a living, and if this continues, I will have a problem supporting my family for the months it will take for the header to expire.

I'm panicking over this fact and do truly regret activating HSTS in the first place.

Besides removing the site from the preload list, is there anything else I can do to solve this problem?

Right now, I can't even access the site and work with it, since my browser has cached the header...

// Jens.

Did this work before? N/A 

Chrome version: 45.0.2454.85  Channel: stable
OS Version: OS X 10.10.4
Flash Version: Shockwave Flash 18.0 r0

Please help me, I'm truly desperate!
 
Cc: rsleevi@chromium.org
Labels: -Type-Bug-Security Type-Bug
Owner: agl@chromium.org
Status: Assigned
This is an issue tracker for bugs in the chromium browser itself; you may also want to try the support forums.  I've CC'd some folks who may be able to help; however, it sounds like the feature is doing exactly what it is supposed to do.
Cc: -rsleevi@chromium.org agl@chromium.org timwillis@chromium.org
Labels: -Restrict-View-SecurityTeam -OS-Mac OS-All
Owner: lgar...@chromium.org
Hi,

While I'm sad that your willingness to try HSTS didn't work out, we can remove your site from the HSTS preload list if that is your wish (I've verified that `curl -I "https://delbart.se"` redirects to http://delbart.se/). However, the change will not reach most users until 3 months from now, and we can't make guarantees about other browsers. So you'd still have to look into other workarounds for the time being.

Would you still like us to go ahead?
Yes, please go ahead! Thank you so much for your help and quick replies!

// Jens.
Btw: The reason it won't reach users is because you push updates every three months? When do you push the next one?

Thanks!

// Jens.
We start a new beta channel branch every 6 weeks, and the beta channel takes 6 weeks before we push it to all users. Since we recently had a branch point, current changes will take about 12 weeks to reach all users.
Ok, too bad I missed the last one... Thanks a lot for your help!
Also, if you absolutely want to turn off HSTS, I recommend sending an HSTS header with max-age: 0 (which clears the HSTS value if it's not preloaded).
But if it's not preloaded, then it wont be a problem, right? I can access the site in the Opera browser for instance, since I didn't visit the site there before.

Can I set this header even if the site now runs without a SSL certificate?
Blocking: chromium:527947
Opera probably didn't get around to the version of the preload list that has delbart.se.

You should still serve a `max-age: 0` HSTS header on the root domain, so that users with HSTS will have their HSTS setting clear before they are redirected.
I also recommend trying to find a way to serve to users with HSTS in the meantime, e.g. by biting the bullet and serving the site over HTTPS for users that have it preloaded.
Status: Fixed
Labels: M-47
The fix should land in Chrome Canary tomorrow.
Thanks, I really appreciate it!
You mentioned that I should find a way to serve over https for HSTS users, but have not found a way to do this
this. Any ideas how I can run this check on Nginx?
I meant that you could just serve the site over HTTPS as well as HTTP, and sent an HSTS token with a max-age of 0.

You can update your navigation links to HTTP version if you want users to be downgraded in browsers where your site is not preloaded.

This way, you can still serve to all users, and you can avoid taking an ad revenue hit when you don't have to. And it becomes easier to switch back to HTTPS once that becomes viable.
Just to be clear, do you mean like this?

Activate ssl certificate on server again, but point all links to http and ignore mixed content warnings? 
Some more info: I also use cloudflare, so maybe I could let cloudflare take care of https somehow? 

I meant:

- Active SSL.
- Point all *links* to HTTP, but keep resource URLs HTTP (or use a protocol-relative URLs, or send the `upgrade-Insecure-requests` CSP token from HTTPS pages).

Cloudflare can probably help some of it, but I don't know how much.
I know I didn't explain much, but hopefully that gives you enough options to explore via web searches.
Thanks Igar!
Have tried to set it up, but I'm not sure how to serve users without the preloaded HSTS header a http page instead of https. Right now, the ads are blocked by all browsers.

Might need to change this line to something else I guess, but I'm not sure to what.

subs_filter http://delbart.se/ https://delbart.se/;

Since I have the SSL certificate on, I get mixed content warnings in all browsers...
I think I solved it! Thanks anyway for all you help!
Labels: Hotlist-HSTS-Preload-Removals
Blocking: -527947
Components: Internals>Network>DomainSecurityPolicy
Sign in to add a comment