Disable Plaintext HTTP Clearnet Connections

I think that the Tor Browser Bundle should aim to disable allowing connections to plaintext HTTP websites out the box by the end of the year 2016.

Content injection into MITM'd clearnet HTTP connections is the number one security threat to Tor users. It's incredibly easy to do and I'm certain that it happens all the time. (You can reproduce this easily by going to http://example.com in the latest TBB. https://example.com is completely valid, but the connection to the plaintext version is made).

Even without direct content injection, it's the obvious weak point in the overall privacy that Tor provides for a common TBB user.

It's 2016 - the vast majority of websites now serve pages over SSL. Thanks to projects like Let's Encrypt, it's now completely easy and free to run SSL out of the box with any important web server software package - there's really no excuse not to be running HTTPS.

Rather than making this change immediately, we could announce the intention to release the change by the end of the year, thereby giving any stragglers time to add SSL to their websites. We could look at how browsers like Chrome and Firefox degrade deprecated TLS ciphers in successive releases as an example - first a visual indication, then a confirmation warning, then a total block.

What do you think?

Trac:
Username: miserlou2

added component::applications/tor browser in Legacy / Trac https-everywhere in Legacy / Trac owner::tbb-team in Legacy / Trac priority::high in Legacy / Trac reporter::miserlou2 in Legacy / Trac severity::major in Legacy / Trac status::new in Legacy / Trac tbb-security in Legacy / Trac type::enhancement in Legacy / Trac labels

who about HTTPS Everywhere? [https://www.eff.org/https-everywhere]

Trac:
Username: f451022

Related: https://www.fxsitecompat.com/en-CA/docs/2015/insecure-http-will-be-deprecated/

Trac:
Version: Tor: 0.2.8.6 to N/A
Keywords: security, ssl, https deleted, tbb-security added

Replying to f451022:

who about HTTPS Everywhere? [https://www.eff.org/https-everywhere] It is not reliable. Should we really move this task to HTTPS Everywhere?

Trac:
Keywords: N/A deleted, https-everywhere added

moved from legacy/trac#19850 (moved)

added Feature label and removed 1 deleted label

added HTTPS Everywhere + 1 deleted label and removed 1 deleted label

If I understand things right, https everywhere has a config option for doing what we want here -- (a) move all http requests to https by default, but then (b) have a way to fall back to http if https fails and also the user chooses to? And we still worry that too much of the web will be broken by default, leading to a poor user experience if this is the default behavior?

Sounds to me like we should integrate it into the security slider as the next step. Maybe put it in by default to the 'safest' mode? Or maybe we think it's important enough to put in to 'safer' too, since after all it would only go to people who have made a conscious choice to change their usability / safety balance, so those people would hopefully be skilled enough to be able to change it back if they don't like the resulting behavior?

I think my vote would be to put it into both 'safer' and 'safest'. And then we'd want to think about how to teach people about the change (maybe there is some way inside the tor browser interface to let people know?) and also we'd want to think about how to assess whether it's working as intended (like, do people actually benefit from it, or do they hate it and it makes them steer away from safer mode, which ultimately and counterintuitively would hurt them in other ways?)

Of course, I tend to use my tor browser on the 'default' slider setting, since if it's good enough for the Tor Browser devs it's good enough for me (and because I want to be getting the experience that most Tor Browser users get, so I can best provide user support). So if there is somebody out there who uses safer and not safest, maybe they have a stronger opinion about which setting it should apply to.

And then ultimately we'd want to have some criteria for when we think it's suitable to go in to the default Tor Browser settings too.

A mode for that landed actually quite recently in Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1644152

It contains some UX for the failure mode, too, it seems, see: https://bugzilla.mozilla.org/show_bug.cgi?id=1625156.

The parent ticket for the experimental HTTPS Only Mode is: https://bugzilla.mozilla.org/show_bug.cgi?id=1613063.

A bunch of stuff landed in Firefox 78 but we'd likely need to backport things if we want to play with the Firefox version of that feature.

I was not sure whether this would break http .onions, but there's an exception for that, which is nice: https://searchfox.org/mozilla-release/rev/2f837d7eb1a53eeb9c8937446520b39b9aacb90d/dom/security/nsHTTPSOnlyUtils.cpp#164

mentioned in issue #40077 (closed)

@arthuredelstein: Thanks for #40077 (closed). I think the plan is to try some form of HTTPS-only mode in the next alpha series at least (that's the one starting after 10.0 is out) and, personally, I am happy to try out what Firefox provides. Two items you probably could help with would be very helpful for us:

1. Getting a handle on the most important things to backport: I've been following HTTPS-only-mode development a bit and got the feeling that a bunch of things, in particular for UX, landed after ESR 78. So, having an idea which patches would give us the biggest improvements here would be very nice. In particular, if that decision is backed up by data Mozilla has.
2. backporting patches now: ESR 78 is still in its stabilizing phase, so backports to it are easier now than later once essentially only security bugs are getting fixed. If you could move ahead suggesting patches for uplift now rather than later that would be very useful as it might lessen the amount of patches we need to backport later on (ideally this would take 1. into account but I realize that might conflict with Mozilla's policy to not backport larger/more risky patches, in particular for ESR).

added 1 deleted label

mentioned in issue #40087

Georg Koppen:

Georg Koppen commented:

@arthuredelstein: Thanks for #40077 (closed). I think the plan is to try some form of HTTPS-only mode on the next alpha series at least (that's the one starting after 10.0 is out) and, personally, I am happy to try out what Firefox provides. Two items you probably could help with would be very helpful for us:

1. Getting a handle on the most important things to backport: I've been following HTTPS-only-mode development a bit and got the feeling that a bunch of things, in particular for UX, landed after ESR 78. So, having an idea which patches would give us the biggest improvements here would be very nice. In particular, if that decision is backed up by data Mozilla has.
2. backporting patches now: ESR 78 is still in its stabilizing phase, so backports to it are easier now than later once essentially only security bugs are getting fixed. If you could move ahead suggesting patches for uplift now rather than later that would be very useful as it might lessen the amount of patches we need to backport later on (ideally this would take 1. into account but I realize that might conflict with Mozilla's policy to not backport larger/more risky patches, in particular for ESR).

We got an annotated list of bugs with backport prios from @arthuredelstein which can probably guide us:

https://bugzilla.mozilla.org/buglist.cgi?classification=Client%20Software&classification=Developer%20Infrastructure&classification=Components&classification=Server%20Software&classification=Other&columnlist=target_milestone,bug_type,short_desc,product,component,assigned_to,bug_status,resolution,changeddate,priority,status_whiteboard&f1=blocked&j_top=OR&o1=substring&resolution=---&resolution=FIXED&resolution=INVALID&resolution=WONTFIX&resolution=INACTIVE&resolution=DUPLICATE&resolution=WORKSFORME&resolution=INCOMPLETE&resolution=SUPPORT&resolution=EXPIRED&resolution=MOVED&v1=1613063

marked #40157 (closed) as a duplicate of this issue

marked this issue as related to #40157 (closed)

changed milestone to %Tor Browser: 10.5

removed milestone %Tor Browser: 10.5