Librewolf + HSTS Cache partitioning

privacytests / privacytests.org

Source code for privacytests.org. Includes browser testing code and site rendering.

https://privacytests.org

MIT License

798 stars 23 forks source link

Librewolf + HSTS Cache partitioning #75

Closed Thorin-Oakenpants closed 2 years ago

Thorin-Oakenpants commented 2 years ago

Librewolf shows HSTS cache fails state partitioning. This doesn't seem right

LW has network partitioning on by default. Looking at entries in SiteSecurityServiceState.txt they are (with some principals excepted) all eTLD or eTLD+1 with partitionKey= origin attributes. Where are 3rd party entries kept?

Same in Firefox, and in arkenfox with Firefox. Arkenfox is literally the same as LW (in v96 we move from FPI to dFPI), which is why I am interested in why LW fails

Reading your description and code which I can't quite wrap my head around

I wonder if HTTPS-Only Mode is affecting this result? LW also fails in this test in PB Mode and we know HoM also overrides HTTPS-First in PB mode. Could you run LW with dom.security.https_only_mode reset to false? And/or give any insight?

TIA

Thorin-Oakenpants commented 2 years ago

AFAIK any HSTS supercookies are rendered useless with HoM

in this example (scroll down to the third picture about half way down) it would return a=Y, b=Y, c=Y, d=Y, e=Y every single time regardless of HSTS

I doubt anyone is going to set HoM exceptions for numerous subresources, and HoM silently fails those anyway

So, if I understand this correctly, the HTTPS cache test should take Insecure website into account, reflect that in the result, and return "passed"?

edit: um, after a sleep, this is a bad idea, I think the test needs to be more robust with multiple binary outcomes: some HSTS, some not, mixed HTTP/HTTPS - I'll await to see what arthur says, it's his test :)

fxbrit commented 2 years ago

thanks @Thorin-Oakenpants for opening this issue which is relevant to me as well (and sorry to both of you, I previously posted a - now deleted - comment that was meant for private research). I'm under the same impression that this could be a false positive as I tested and connections are always upgraded to https before leaving the browser.

I have a question for @arthuredelstein anyway: if you have the time, could you explain to me how you go about testing isolation of the HSTS cache? if it really turns out to be a false positive could it be worked around by having two subresources, one that asks for the secure connection and the other that doesn't?

arthuredelstein commented 2 years ago

Hi @Thorin-Oakenpants and @fxbrit -- you are right. This is a false positive for LibreWolf. I removed the X for now and I'm looking into a fix. Thank you both and sorry for the error.

Thorin-Oakenpants commented 2 years ago

Rather than create a new issue

Tor Browser has a Desktop + Desktop private mode. Isn't the first redundant?
same with TB Nightly and Nightly private mode
https://privacytests.org/news.html - link for 10 desktop is for current desktop issue
TB Tor test
- issue 10: desktop private mode mode shows Tor as failed
- issue 10.1: desktop shows Tor as failed

Change in issue 11 - font isolation is now a fail for gecko desktop. Font cache should be isolated by network partitioning

arthuredelstein commented 2 years ago

Rather than create a new issue

Please do create new issues! :) So I can close each issue one by one.

arthuredelstein commented 2 years ago

I split out #77.

The HSTS issue was fixed in Issue 11.