You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Nov 6, 2023. It is now read-only.
Repository navigation
This repository was archived by the owner on Nov 6, 2023. It is now read-only.
Project: Find all the HTTPS Everywhere rules that can be HSTS rules #77
The idea is to write a program that parses HTTPS Everywhere rules and detects which ones can be equivalent to HSTS preloads. Seth took a stab at it in utils/simple.py, but it needs some work.
Once we have a list of rules from HTTPS Everywhere that can be used to expand the built-in browser HSTS preload list, there's a couple of awesome things we can try:
Offer this list as a download to developers writing software/apps that would benefit from STS.
Since it's impossible to make HTTPS Everywhere for Safari, the next-best thing seems to be adding this list to ~/Library/Cookies/HSTS.plist in Mavericks. This file remembers STS for Safari and possibly other apps as well.
Perhaps we can completely replace these rules in FF and Chrome by STS preloads so that we use the browsers' built-in STS mechanism for switching domains to HTTPS rather than HTTPS Everywhere's. This might help with performance issues.
Closing. I don't think it's safe to inject HSTS headers for sites, since that means any certificate error turns into a hard fail (can't click through it). I think it really needs to be at the site owner's discretion to turn on HSTS.
Activity
semenko commentedon Jan 29, 2014
FWIW: On Chrome, we could probably inject the HSTS header (via a blocking onHeadersReceived hook).
Unfortunately, I can't think of a great way to have this improve performance.
The best way would be to stop listening to httpS in onBeforeRequest, so we'd only call HTTPS Everywhere during an insecure request.
The downside:
We couldn't do any more rewriting of erroneous SSL requests. (How critical is that feature?) That is, rewriting something like https://broken-cert.example.com -> https://www.broken-cert.example.com
I'll think a little harder on this, but I don't think HSTS helps us unless we can pull back from listening on all HTTPS requests.
jsha commentedon Mar 13, 2016
Closing. I don't think it's safe to inject HSTS headers for sites, since that means any certificate error turns into a hard fail (can't click through it). I think it really needs to be at the site owner's discretion to turn on HSTS.