-
Notifications
You must be signed in to change notification settings - Fork 513
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
tracking: HTTPS-Only mode #1047
Comments
correct me if I'm wrong but AFAIK this leak is only really a leak if you use DoH+ESNI. As I understand it, the background request is also only triggered if a webserver doesn't respond to the HTTPS request within 3 seconds. I only mention this because in another issue @rusty-snake said that this "always leaks" and that's not true AFAIK.
we can add it inactive, for people using DoH+ESNI. |
It was here. My understanding up to now was that to each server a http and a https connection attempt is made when opening a new site. But thanks to your push I checked this again, and yes it looks like it's only done after 3secs of no response. https://phabricator.services.mozilla.com/D85300
The IP of the site is always leaked w/o a VPN. And the domain is leaked if you don't use DoH/DoT/… and w/o eSNI (which needs to be supported by your firefox and the server) it's leaked too. As long as background-requets are enabled, a attacker (e.g. your ISP) could delay all your requests and then catch these http requsts. However, you would note if every site takes much longer. As HOM now is on about:preferences I wouldn't consider it experimental anymore (as you said). And it works with FPI (but see below). We should add it as FWIW: If you set |
Thanks for mentioning the problem with |
/* 1244: enable HTTPS-Only mode [FF76+]
* When "https_only_mode" (all windows) is true, "https_only_mode_pbm" (private windows only) is ignored
* [NOTE] If the last pref is true, firefox sends a http requests after 3 seconds of no response to this _domain_
* to see if the site supports https. This avoids waiting for timeouts.
* [SETTING] to add site exceptions: Page Info>Permissions>Use insecure HTTP (FF80+)
* [SETTING] Privacy & Security>HTTPS-Only Mode
* [1] https://bugzilla.mozilla.org/1613063 [META]
* [2] https://bugzilla.mozilla.org/1647829 ***/
user_pref("dom.security.https_only_mode", true); // [FF76+]
// user_pref("dom.security.https_only_mode_pbm", true); // [FF80+]
// user_pref("dom.security.https_only_mode.upgrade_local", true); // [FF77+]
user_pref("dom.security.https_only_mode_send_http_background_request", false); // [FF82+]
Since FF82 it only leaks the domain , but not the site. If |
Could you file a bug on the potential bad interaction between dFPI and HTTPS-only? It's a bit hard to make out what the problem is without context. |
FYI, these are 2 different prefs!
yes they increased it to 3 seconds |
STR (used Nightly 85.0a1 (2020-11-18)): Test sites:
NOTE: You need to open the Nothing changed (in Nightly this means
Enable HOM (and sanitize cookies, cache, ...):
Enable FPI (and sanitize):
Enable
EDIT: Summary: dFPI is not affected. Only HOM + FPI + FPI.use_site. |
/* 1244: enable HTTPS-Only mode [FF76+]
* When "https_only_mode" (all windows) is true, "https_only_mode_pbm" (private windows only) is ignored
* [SETTING] to add site exceptions: Page Info>Permissions>Use insecure HTTP (FF80+)
* [SETTING] Privacy & Security>HTTPS-Only Mode
* [1] https://bugzilla.mozilla.org/1613063 [META]
* [2] https://bugzilla.mozilla.org/1647829 ***/
user_pref("dom.security.https_only_mode", true); // [FF76+]
// user_pref("dom.security.https_only_mode_pbm", true); // [FF80+]
user_pref("dom.security.https_only_mode_send_http_background_request", false); // [FF82+]
/* 1245: Upgrade requests to local resource too [FF77+] ***/
// user_pref("dom.security.https_only_mode.upgrade_local", true);
/* 1246: Disable http background requests [FF82+]
* If a site is upgraded by HOM and the server didn't response with in 3 seconds, firefox sends a
* http requests to the domain in order to see whether the server supports https or no.
* This is done to avoid waiting for a timeout which takes 90 seconds.
* [1] https://bugzilla.mozilla.org/1642387
* [2] https://bugzilla.mozilla.org/1660945 ***/
user_pref("dom.security.https_only_mode_send_http_background_request", false); |
I like http://neverssl.org/, because its random, avoiding cache "problems". |
Edit: thoughts on testsites:
|
So, is there no proper way to add exceptions/whitelists yet? |
It doesn't work with some sites that act like they have a HTTPS version but this version is actually a stub asking you to use HTTP instead (e.g. this one). I'm not sure what's the reasoning behind such setups. |
Yep, manual SQL insert fixes the issue for websdr.space and several other sites, thanks. |
I'm done tracking this [in OP]: you're going to get weird edge cases until the interwebs get their shit together and HTTP is outlawed |
I was wondering if |
I'm not sure if it upgrades sub-requests. Anyway in the worst case you end up with not loading sub-request due to mixed-content blocking. Lines 692 to 697 in 00fa8f1
|
When I have tested last time looong time ago, when HOM is enabled also mixed passive content is upgraded to HTTPS. But you can easily test your scenario at Cheers |
So it does upgrade mixed content sub-requests, and blocks them if downloading via https is not available? |
HTTPS-First is the one that silently fails and allows insecure
HoM upgrades everything: this comment says (emphasis mine), and chris makes a point of difference with
There was also another comment Chris made some time after that, but I can't find it, in which I'm almost certain he did state it does upgrade all subresources (and silently fail) So that's the intent, AFAIK. If you follow the meta ticket, there are still a few holes (not web content itself that I know of: it's edge cases likeTCP, HSTS) and teething issues here and there, and tickets for finishing building tests - I'm not really following it TBH. HoM should be pretty robust. IDK if HTTPS-E in EASE Mode is it's equal - given that it's limited by WebExt |
Excellent, thanks! |
re-opening to remind me: we should add that info to the item in the user.js |
Btw I'm unable to set exceptions, either from the padlock icon (on/off) or from the "manage exceptions" section in about:preferences#privacy, probably because of FPI as reported by @rusty-snake above. You might want to add this info too. |
worksforme, also where I don't see where rusty snake-eyes g.i. joe said something about FPI, but yes, you need to make sure you exception has the right FPI syntax can you give me the site that doesn't work for you? edit: example: here's my only exception
|
Last 3 lines in this comment
Any http website, e.g. libgen.lc - I add the exception (usually setting to "off" via padlock, I also tried via manage exceptions), shutdown Firefox, and the next time there is no exception listed in "manage exceptions". Since your example (impawards) also met the same fate, I think one of my addons is deleting them for some reason. I'll have to do some tests... |
@eleius Either don't set Did you set |
http://http.badssl.com/ -> "continue to HTTP Site" -> Padlock "Not Secure" -> HTTPS-Only mode -> Off WFM with FPI=true FPI.use_site=false |
If you set a HOM exception from the Padlock, it uses the current site. If you are on |
Ah yes. So https exceptions are counted as "site settings". |
Permissions are site settings. |
Here's the full list: Ci.nsIClearDataService.CLEAR_PERMISSIONS |
Ci.nsIClearDataService.CLEAR_CONTENT_PREFERENCES |
Ci.nsIClearDataService.CLEAR_DOM_PUSH_NOTIFICATIONS |
Ci.nsIClearDataService.CLEAR_SECURITY_SETTINGS |
Ci.nsIClearDataService.CLEAR_CERT_EXCEPTIONS https://searchfox.org/mozilla-central/source/browser/modules/Sanitizer.jsm#513-517 |
IDK what's going on. In FF85 or 86 or whatever or 89 or 90 it worked, for the impawards site, single upgrades worked with FPI, adding exceptions worked with FPI (e.g. edit in sqlite if needed). When the UI for exceptions came along, it still all worked. It still works in my FF91 main Firefox. But now it all seems broken with FPI in nightly. Seriously, I am so tired of all this shit (not you guys, but the constantness of all this stuff), that honestly, I think I might just fuck off for a year .. I've almost had it
FPI is enabled. Clicking If FPI is disabled, everything seems to work. |
Ok I'm setting it to false, I just hope "content preferences" (?) cannot be abused for tracking. |
OK, so it was you clearing site preferences on close, then? right? thank fuck for that. As for nightly, fuck it. I just tested in my main FF and everything works fine with FPI, so until breakage happens in stable, I do not care. Taking a year off, see you in 2022 |
Oh man, sorry about that... |
not your fault. I assumed you wouldn't be deleting site exceptions (we don;t in the user.js) because that's rather extreme. And I just jumped to the most logical conclusion that it was one of those weird edge case sites: hence why I asked what it was
"content preferences" ? If you mean site exceptions, then no. Exceptions are not global (they are literally exceptions) so can't be used to help track you, and exceptions are only things like allow/prompt/block things - do a control-I on a page and view permissions |
But I shouldn't have posted here using a customized js, I totally forgot I had switched that one to true. |
pants
rusty
sorry rusty, I simply don't use the interface or add exceptions (except the one I have had for ages) - so my method was a little RUSTY (sorry). We better add that: edit bit pointless listing off temporarily then isn't it, in order to use it you already set that (talk about ass about face)
|
OK, how is this /* 1244: enable HTTPS-Only mode in all windows [FF76+]
* If the top-level is HTTPS, then insecure subresources are also upgraded, failing silently
* [SETTING] to add site exceptions: Padlock>HTTPS-Only mode>On <- when on the site
* [SETTING] Privacy & Security>HTTPS-Only Mode
* [TEST] http://example.com [upgrade] <--- RUSTY FIND ME SOMETHING ELSE
* [TEST] http://neverssl.org/ [no upgrade]
* [1] https://bugzilla.mozilla.org/1613063 [META] ***/
user_pref("dom.security.https_only_mode", true); // [FF76+]
// user_pref("dom.security.https_only_mode_pbm", true); // [FF80+] |
/* 1244: enable HTTPS-Only mode in all windows [FF76+]
* If the top-level is HTTPS, then insecure subresources are also upgraded, failing silently
* [SETTING] to add site exceptions: Padlock>HTTPS-Only mode>On (After "Continue to HTTP Site")
* [SETTING] to add site exceptions: click "Continue to HTTP Site", Padlock>HTTPS-Only mode>On
* [SETTING] Privacy & Security>HTTPS-Only Mode
* [TEST] http://example.com [upgrade] <--- RUSTY FIND ME SOMETHING ELSE; Actually every site with ~correct configured~ _working_ https, _idealy without 301 upgrade_. However if it is in https://hg.mozilla.org/mozilla-central/raw-file/tip/security/manager/ssl/nsSTSPreloadList.inc, it will be upgrade regardless of HOM. Will look for a good one.
* [TEST] http://neverssl.com/ [no upgrade] <--- .org is dead
* [1] https://bugzilla.mozilla.org/1613063 [META] ***/
user_pref("dom.security.https_only_mode", true); // [FF76+]
// user_pref("dom.security.https_only_mode_pbm", true); // [FF80+] |
shit that was meant to be the neverssl one
|
wait a second ... http://neverssl.com/ is working - #1235 (comment) so I guess we don't need to worry about that now |
edit: no longer tracking/updating since May 2021
if you see
HOM
in this issue, it this stands forHTTPS-Only mode
I've gone through the bugzillas and picked the eyes out. Note that we block mixed active and passive by default, and there is also the upcoming insecure downloads pref: these probably all have a bearing on how this works
update: FF83+ the UI is exposed
🔻 meta
🔻 landed
🔻 of interest
🔻 misc / open
www
issues🔻 visuals
The text was updated successfully, but these errors were encountered: