Opened 7 months ago

Closed 3 weeks ago

Last modified 2 weeks ago

#21321 closed task (fixed)

.onion HTTP is shown as non-secure in Tor Browser

Reported by: cypherpunks Owned by: tbb-team
Priority: High Milestone:
Component: Applications/Tor Browser Version:
Severity: Blocker Keywords: ff52-esr, tbb-7.0-issues, tbb-usability, ux-team, tbb-7.0-frequent, TorBrowserTeam201708R, GeorgKoppen201708
Cc: fdsfgs@…, blockflare, mrphs, catalyst, guido@…, mcs, asn, arthuredelstein Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

blog.mozilla.org/security/2017/01/20/communicating-the-dangers-of-non-secure-http/

http version of .onion is safe. This must be the exception of that slash/ icon.

Child Tickets

Change History (54)

comment:1 Changed 7 months ago by gk

Keywords: ff52-esr tbb-usability-website added

comment:2 Changed 6 months ago by cypherpunks

It is not. https over .onion is secure. .onion is insecure and should be used only for decentralized DNS (insecure, the RSA-1024 is broken), website position obfuscation and offloading exit nodes.

Last edited 6 months ago by cypherpunks (previous) (diff)

comment:3 Changed 6 months ago by tokotoko

Cc: fdsfgs@… added

comment:4 Changed 5 months ago by gk

Cc: blockflare added

#21877 is a duplicate.

comment:5 Changed 2 months ago by gk

Cc: mrphs added
Keywords: tbb-usability ux-team added; tbb-usability-website removed
Priority: MediumHigh
Severity: NormalMajor

#22545 is a duplicate.

comment:6 Changed 2 months ago by gk

For the issue with the password field see: http://j6uhdvbhz74oefxf.onion/

comment:7 Changed 2 months ago by gk

The discussion we had in Amsterdam (https://trac.torproject.org/projects/tor/wiki/org/meetings/2017Amsterdam/Notes/OSUX) might be helpful as well.

comment:8 Changed 2 months ago by gk

#8686 is related (see the closed duplicate #22483 as well).

comment:9 Changed 2 months ago by arma

Is there a way to separate the more general issue ("maybe we should teach mozilla to treat onion addresses like https addresses in all ways) from the more immediate issue ("ff52 has a new feature where it scares you when you're about to use a text form on an onion page")?

comment:10 Changed 2 months ago by gk

Well, we want to come up with patches in this ticket to the more immediate issue and then upstream them (which would be the "convince"-part).

comment:11 Changed 2 months ago by gk

Summary: Convince Mozilla; .onion HTTP is SECURE..onion HTTP is shown as non-secure in Tor Browser

comment:12 Changed 2 months ago by gk

Cc: catalyst added

comment:13 Changed 2 months ago by gk

I am not sure yet about how to deal with the various security indicators in the browser UI (like padlock icon) but it seems to me we could make sure that the scary password field warning does not show up anymore when being on an HTTP .onion site. Even if we might disagree about how secure exactly that mode is I feel it is sufficiently secure that the warning against plain-HTTP password fields is not warranted. Does that sound like a reasonable start?

comment:14 in reply to:  13 ; Changed 2 months ago by yawning

Replying to gk:

I am not sure yet about how to deal with the various security indicators in the browser UI (like padlock icon) but it seems to me we could make sure that the scary password field warning does not show up anymore when being on an HTTP .onion site. Even if we might disagree about how secure exactly that mode is I feel it is sufficiently secure that the warning against plain-HTTP password fields is not warranted. Does that sound like a reasonable start?

As massively flawed and totally horrible as the CA system is, having a CA signed TLS cert serves to bind the address to an external identity. .onion address do not have this property. What assurance is there that the address a user is entering their credentials to is the correct one?

And yes, DV certs exist. Normal FQDNs are not a UI disaster like the current (and prop-224) .onions are.

I'm open to being convinced otherwise, but I currently will be strongly against blurring the lines between "http over onions" and "https".

comment:16 Changed 2 months ago by cypherpunks

This is Tor Browser, not Firefox. If you say HTTP .onion or HTTPS .onion is insecure, then you need to update your Tor manual and documentation to state .onion is dangerous.

Tor Browser must accept HTTP .onion and HTTPS .onion as safe TLD.

comment:17 Changed 2 months ago by cypherpunks

1) Using .onion on plain Firefox is indeed NOT secure and I think it is smart if Firefox > users get this warning in case they've proxied their browser to use Tor.

Tor user should use Tor Browser. No exception.
Using native Firefox with Tor will do some level of harm to user's privacy(firefox telemetry, sending computer information to mozilla servers, etc).

comment:18 Changed 2 months ago by guido

Cc: guido@… added

comment:19 Changed 2 months ago by mrphs

Ditto the last 2 comments by 'cypherpunks'. And also ditto on what geko said about on removing the password warning as a first step. (how I wish we had 'like' or '+1' buttons on trac)

I've explained how I think about this issue to some extent on #22545. As someone who directly works with people at immediate risk and as someone with UX background, I believe this warning has actually became a security issue as it misleads people to take far less secure route.

I happen to believe while debating the security features of 'HTTPS' vs 'HTTP .onion' vs 'HTTPS .onion' is healthy and necessary to have, it's outside of the urgent needs of this ticket.

To help you understand where I come from... People in various movements and situations are adopting using Tor Browser and .onion as their most reliable and secure way of communicating, and this is the result of a greater community pushing for this for a long period of time. Building trust relationship with often-exploited communities is extremely difficult. Now after they've learned to trust Tor Browser to do the right thing, and they see this warning, that affects both their trust with Tor in general (for being inconsistent) and then the person who taught them how to use Tor. I don't want to vent too much here so I think these are the actionable items we have for this problem:

1- Remove the password warning. (this is immediate)
2- Remove the padlock warning. (also immediate, preferably at the same time with 1)
3- Improve our messaging with user about .onion URLs in Tor Browser to make sure we're consistent (more long-term but prevents us from situations like this)

then at the same time we can also have two conversations:

  • What's the way we want to recommend people to use .onion
  • And how do we convince Mozilla and others to adopt based on our decision on that

I guess the reason I'm leaving this comment is that we don't get into a rabbit hole that gets us away from fixing this immediate need.

comment:20 Changed 2 months ago by mrphs

Severity: MajorBlocker

bumping the severity to "blocker" as I'm seeing on a day to day basis this has started to make users wonder about the security of sites accessible by .onion. People are falling back to other (less safe and potentially dangerous) communication methods because of this.

comment:21 Changed 2 months ago by mcs

Cc: mcs added

comment:22 Changed 2 months ago by mo

It also shows severe warnings when you try to submit a form "over HTTP" (to an onion).

comment:23 Changed 2 months ago by gk

Keywords: TorBrowserTeam201706 added

https://blog.torproject.org/comment/269369#comment-269369 mentions security.insecure_field_warning.contextual.enabled as a preference one could think about flipping.

comment:24 Changed 2 months ago by gk

See #22693 for a possible fingerprinting problem associated with the warning message.

comment:25 Changed 2 months ago by arma

I am excited to see progress on this one. It continues to be an issue, as we see in the blog comments.

Also, the riseup people auto redirect users to their onion version, when they come from an IP address that riseup thinks is a Tor exit relay. So many riseup users using Tor Browser are experiencing this bug and being scared by the confusing UI and then probably doing foolish things in response.

comment:26 Changed 2 months ago by asn

Cc: asn added

comment:27 in reply to:  19 ; Changed 2 months ago by yawning

Replying to mrphs:

I've explained how I think about this issue to some extent on #22545. As someone who directly works with people at immediate risk and as someone with UX background, I believe this warning has actually became a security issue as it misleads people to take far less secure route.

How is using a site over Tor through an exit, with a CA signed TLS cert any less secure than using an onion over HTTP.

I happen to believe while debating the security features of 'HTTPS' vs 'HTTP .onion' vs 'HTTPS .onion' is healthy and necessary to have, it's outside of the urgent needs of this ticket.

No.

Mozilla and Firefox defines "secure enough not to show a warning" as "HTTPS with a CA signed cert".

The prerequisite to changing the behavior is to present a strong case for "they are wrong, and the definition of 'secure enough not to show a warning' should be 'HTTP over .onion, *or* HTTPS with a CA signed cert'", where "strong case" is along the lines of "the security properties are at least identical, if not better".

"People get confused" is not a good reason to redefine what secure means, as a matter of general principle, and disabling the warnings is redefining what secure means.

(If people think the warning should go away all together, then they're even more wrong.)

comment:28 in reply to:  27 ; Changed 2 months ago by cypherpunks

Replying to yawning:

How is using a site over Tor through an exit, with a CA signed TLS cert any less secure than using an onion over HTTP.

There's the risk of MiTM by the exit, or due to the flawed CA system itself - as happened in the past for Tor Project infrastructure with CA DigiNotar [1], in comparison with a 0 risk for a MiTM with onion services.

[1] : https://blog.torproject.org/comment/12045

comment:29 in reply to:  28 ; Changed 2 months ago by yawning

Replying to cypherpunks:

Replying to yawning:

How is using a site over Tor through an exit, with a CA signed TLS cert any less secure than using an onion over HTTP.

There's the risk of MiTM by the exit, or due to the flawed CA system itself - as happened in the past for Tor Project infrastructure with CA DigiNotar [1], in comparison with a 0 risk for a MiTM with onion services.

HSTS is a thing.

comment:30 in reply to:  29 Changed 2 months ago by cypherpunks

Replying to yawning:

HSTS is a thing.

Yeah, and how many websites use it?

comment:31 in reply to:  27 ; Changed 2 months ago by mrphs

Replying to yawning:

Mozilla and Firefox defines "secure enough not to show a warning" as "HTTPS with a CA signed cert".

The prerequisite to changing the behavior is to present a strong case for "they are wrong, and the definition of 'secure enough not to show a warning' should be 'HTTP over .onion, *or* HTTPS with a CA signed cert'", where "strong case" is along the lines of "the security properties are at least identical, if not better".

"People get confused" is not a good reason to redefine what secure means, as a matter of general principle, and disabling the warnings is redefining what secure means.

(If people think the warning should go away all together, then they're even more wrong.)

Do you have a good reason to believe they've even considered .onion when they were designing this warning message? Because I don't and I do happen to follow major browser UX discussions when it comes to security. Do you have a link that I missed about them having this conversation and knowingly deciding that onions aren't secure?

This warning is misleading and half-baked. It's been designed so people get notified when they're submitting information and particularly passwords in plain text. Obviously not the case with .onion.

If we wanna talk about how Mozilla defines security, -and I'm a bit cautious of going down that rabbit hole-, we should consider that they've decided to block .onions at DNS level by default with network.dns.blockDotOnion so people don't accidentally paste .onion URLs in Firefox thinking it's Tor Browser. That decision has a very clear message, and that is to Mozilla that .onion users aren't supposed to use Firefox for their business and they should stick to Tor Browser. That by itself explains they clearly didn't have to even think about how this might look for .onion users in TB, because that's our job to do and not theirs. So no, we're not "redefining" what secure means. We're fixing a problem of not seeing an update coming and thinking what it means for our users. The problem of having reactionary UX instead of a pro-active one.

comment:32 in reply to:  31 Changed 2 months ago by yawning

Replying to mrphs:

That decision has a very clear message, and that is to Mozilla that .onion users aren't supposed to use Firefox for their business and they should stick to Tor Browser.

What? The only thing that signals is "Mozilla gives lip service to an RFC", and "Firefox as an application does not implement the Tor protocol" (RFC 7686). Nothing more, nothing less.

We're fixing a problem of not seeing an update coming and thinking what it means for our users.

What you're proposing is blurring the line between a CA cert signed site over TLS, and .onion, which isn't something that should be done lightly. "The problem of having reactionary UX instead of a pro-active one.".

comment:33 Changed 8 weeks ago by cypherpunks

This warning is misleading and half-baked. It's been designed so people get notified when they're submitting information and particularly passwords in plain text. Obviously not the case with .onion.

If some likes to run tor on an another machine like a Tor router (eg on an OpenWRT-Router or Whonix in a VM) all the PCs or VMs in the same network could still capture all the http-packages before the packages enter the internet... Thereby, there are use cases in which using an onion-address is not sufficient and less secure than an onion-address + tls.

comment:34 in reply to:  19 ; Changed 8 weeks ago by linda

Hi, the UX team has reviewed this ticket, and we recommend removing the warnings as soon as possible and working on messaging thereafter.

I think that there are two problems to solve, 1) the password and padlock warnings are misleading users, telling them that something is insecure when it isn't 2) educating users on what secure means. I think that we can, and should, solve these issues independently. Getting rid of the warnings will be a much better improvement than leaving them up, even if there is no explanation.

Of course, it would be good to educate users on why .onion sites are secure. When we onboard users to Tor, we should mention .onion sites and other features on first use, and show information on .onion sites when they first visit an onion website. Additionally, we can also put a message when you click on or hover over the "secure" indicator (something like this) that says why .onion sites are safe, for people who are wondering why it is safe.

I, Linda, especially agree with mrphs' comment, who suggested:

Replying to mrphs:

1- Remove the password warning. (this is immediate)
2- Remove the padlock warning. (also immediate, preferably at the same time with 1)
3- Improve our messaging with user about .onion URLs in Tor Browser to make sure we're consistent (more long-term but prevents us from situations like this)

We're essentially recommending the same thing, with an emphasis on separating out 1+2 from 3.

I guess the reason I'm leaving this comment is that we don't get into a rabbit hole that gets us away from fixing this immediate need.

+1, we should fix this issue, and solve on working on user understanding later. Ultimately, the warnings are more confusing and interrupting user flow.

Last edited 8 weeks ago by linda (previous) (diff)

comment:35 Changed 8 weeks ago by cypherpunks

I think that there are two problems to solve, 1) the password and padlock warnings are misleading users, telling them that something is insecure when it isn't [...]

There are use cases where just an onion site isn't secure at all, like having the tor process running on a separate PC/Router etc.

comment:36 in reply to:  35 Changed 8 weeks ago by cypherpunks

Replying to cypherpunks:

There are use cases where just an onion site isn't secure at all, like having the tor process running on a separate PC/Router etc.

While you can modify the Tor Browser configuration today I believe it's discouraged to do it. When you manually remove it's default configuration to use a non local tor process you are opting-in to degrade the privacy and security features not just for onion websites.

comment:37 in reply to:  34 Changed 7 weeks ago by asn

Replying to linda:

Hi, the UX team has reviewed this ticket, and we recommend removing the warnings as soon as possible and working on messaging thereafter.

I think that there are two problems to solve, 1) the password and padlock warnings are misleading users, telling them that something is insecure when it isn't 2) educating users on what secure means. I think that we can, and should, solve these issues independently. Getting rid of the warnings will be a much better improvement than leaving them up, even if there is no explanation.

Of course, it would be good to educate users on why .onion sites are secure. When we onboard users to Tor, we should mention .onion sites and other features on first use, and show information on .onion sites when they first visit an onion website. Additionally, we can also put a message when you click on or hover over the "secure" indicator (something like this) that says why .onion sites are safe, for people who are wondering why it is safe.

I think this is a very reasonable course of action. +1

comment:38 Changed 7 weeks ago by gk

Keywords: TorBrowserTeam201707 added; TorBrowserTeam201706 removed

Moving Tickets to July 2017.

comment:39 in reply to:  38 ; Changed 6 weeks ago by linda

The UX team triaged the ticket today with Geko and catalyst a part of the conversaion.

We decided that keeping the padlock icon as is but removing the warning is the best course of action for now.

The core issue here is that the lock icon indicates if it is http/https. But what users really want to know is if the website is secure or not. While turning the lock icon to look secure would be telling them what they want to know ("yes, it is secure"), it is lying to them (since the indicator technically means that it is or is not https).

We have been discussing what we should do going forward--there were a lot of ideas, including: showing both an .onion icon and http/s icon and having a message for each combination of states, overriding the https and just showing the onion icon when on a .onion website (not messing with the https icon to lie, but to omit it), or focusing on just getting the user to use .onion AND https.

The issue is complicated though: .onion sites are secure, but is it more/less/as secure as https? the answer is unclear. .onion sites can be easily be phishing sites due to their address, and has different security guarantees than https. What happens with loading http images on a .onion http site? etc. Any feedback welcome.

comment:40 in reply to:  39 Changed 6 weeks ago by cypherpunks

Replying to linda:

We decided that keeping the padlock icon as is but removing the warning is the best course of action for now.

warning padlock icon without a warning message...

The core issue here is that the lock icon indicates if it is http/https.

Wrong, see MCB...

But what users really want to know is if the website is secure or not.

Is knife secure or not? Life? HTTPS? Who will tell them?

While turning the lock icon to look secure would be telling them what they want to know ("yes, it is secure"), it is lying to them (since the indicator technically means that it is or is not https).

Correct.

We have been discussing what we should do going forward--there were a lot of ideas, including: showing both an .onion icon and http/s icon and having a message for each combination of states, overriding the https and just showing the onion icon when on a .onion website (not messing with the https icon to lie, but to omit it), or focusing on just getting the user to use .onion AND https.

The latter.

The issue is complicated though: .onion sites are secure

Lie. See about the knife.

, but is it more/less/as secure as https? the answer is unclear. .onion sites can be easily be phishing sites due to their address, and has different security guarantees than https. What happens with loading http images on a .onion http site? etc.

It is more about the connection, than HTTPS. About onion routing only.

Any feedback welcome.

Feedback is given when something is done. There are only cries of some sort of users that can't understand the difference between "site" and "connection" for now.

Mozilla says:

Clicking on the “i” icon, will show the text, “Connection is Not Secure” and “Logins entered on this page could be compromised”.

To make it clear and TRUE, add "HTTP" - “Connection is Not Secure HTTP” and upstream it.

Edit: deleted off-topic part (not original cypherpunk commentator).

Last edited 2 weeks ago by cypherpunks (previous) (diff)

comment:41 in reply to:  39 Changed 6 weeks ago by cypherpunks

Replying to linda:

We decided that keeping the padlock icon as is but removing the warning is the best course of action for now.

Still better than the current situation, hope this lands soon.

What happens with loading http images on a .onion http site? etc.

IMHO just as there's a padlock for when http resources get loaded with an https site https://support.cdn.mozilla.net/media/uploads/gallery/images/2015-10-21-18-54-26-fe01d6.png, there should too be a padlock for when http resources get loaded with an onion site (as you proposed in #21952).

But again this isn't high priority for the moment, and the fix you agreed on will be vastly sufficient to counter the current "passwords can be stolen" issue for most users.

Last edited 6 weeks ago by cypherpunks (previous) (diff)

comment:42 Changed 6 weeks ago by gk

Keywords: tbb-7.0-issues GeorgKoppen201707 added

comment:43 in reply to:  14 ; Changed 5 weeks ago by cypherpunks

Replying to yawning:

As massively flawed and totally horrible as the CA system is, having a CA signed TLS cert serves to bind the address to an external identity. .onion address do not have this property. What assurance is there that the address a user is entering their credentials to is the correct one?

The secure padlock only means that the stuff in transit is secure, it has absolutely no relevance to whether we're talking to Satan or RiseUp. EV certs are what one should look at if they want to make sure they're talking to the right organization.

comment:44 in reply to:  43 Changed 5 weeks ago by yawning

Replying to cypherpunks:

The secure padlock only means that the stuff in transit is secure, it has absolutely no relevance to whether we're talking to Satan or RiseUp. EV certs are what one should look at if they want to make sure they're talking to the right organization.

As a happy coincidence, the only CA signed certs for .onion domains are EV certs.

comment:45 Changed 5 weeks ago by gk

Okay, just as an update on where we are with this issue. I have a workaround for the password part which I will post for review in a child ticket. While working on this I thought about good ways of upstreaming this patch and generally of a way to get .onion URLs not treated as non-secure anymore.

The tricky thing is that there is a spec behind defining what secure contexts are (see: https://w3c.github.io/webappsec-secure-contexts/) and, looking at the algorithm defining "secure context", getting .onion domains treated as such is not going to fly without a spec change. I'd assume a lot of the stakeholders would show quite some resistance to that (probably with some good reasons).

But we might be able to bypass that hassle by using other means provided in that spec, in particular treating .onions as potentially trustworthy origins (https://w3c.github.io/webappsec-secure-contexts/#is-origin-trustworthy):

A potentially trustworthy origin is one which a user agent can generally trust as delivering data securely.

This algorithms considers certain hosts, scheme, and origins as potentially trustworthy, even though they might not be authenticated and encrypted in the traditional sense.

Mozilla folks indicated they would be amenable to this idea, which is very exciting. The upstream bug for that is https://bugzilla.mozilla.org/show_bug.cgi?id=1382359. Not sure if I get to rewriting my patches according to that idea before the next Tor Browser release. But the plan is to have this upstream bug fixed for esr59 at least.

comment:46 Changed 4 weeks ago by gk

Cc: arthuredelstein added
Keywords: TorBrowserTeam201707R added; TorBrowserTeam201707 removed
Status: newneeds_review

Please review: https://oniongit.eu/gk/tor-browser/merge_requests/1. I have not looked at a mixed content context. The tests in browser_hasInsecureLoginForms.js should get adapted once we have those bits figured out. But I'd say that should happen in a different bug titled "Don't block .onion sites in a mixed content setup" or something like that.

comment:47 Changed 4 weeks ago by gk

Keywords: tbb-7.0-frequent added

Tracking frequent 7.0 reports

comment:48 Changed 4 weeks ago by brade

I added a comment in oniongit.

comment:49 Changed 3 weeks ago by gk

Updated the branch with review feeback and created a new merge request: https://oniongit.eu/gk/tor-browser/merge_requests/2. Arthur, could you have a look at that one?

comment:50 Changed 3 weeks ago by gk

Keywords: TorBrowserTeam201708R added; TorBrowserTeam201707R removed

Moving review tickets to August.

comment:51 Changed 3 weeks ago by gk

Keywords: GeorgKoppen201708 added; GeorgKoppen201707 removed

Moving my tickets to August.

comment:52 in reply to:  49 ; Changed 3 weeks ago by arthuredelstein

Replying to gk:

Updated the branch with review feeback and created a new merge request: https://oniongit.eu/gk/tor-browser/merge_requests/2. Arthur, could you have a look at that one?

I reviewed both patches and commented on oniongit.eu. I suggested a minor (optional) revision, but otherwise they look good.

comment:53 in reply to:  52 Changed 3 weeks ago by gk

Resolution: fixed
Status: needs_reviewclosed

Replying to arthuredelstein:

Replying to gk:

Updated the branch with review feeback and created a new merge request: https://oniongit.eu/gk/tor-browser/merge_requests/2. Arthur, could you have a look at that one?

I reviewed both patches and commented on oniongit.eu. I suggested a minor (optional) revision, but otherwise they look good.

Thanks. I included that and pushed the patches to tor-browser-52.2.0esr-7.0-1 (commits 30b633b92a94bced2537354afe3d228f0eace8da and 7a03cca9991cfab93be16e9d5521bc58c35d4d44) and tor-browser-52.2.0esr-7.5-1 (commits df2223e1b1f8a4b782e7e49bbbeb79296ea74dff and 490f3cc2d708cf693ebb7c730b7bb2562dc8987c). This will be available in Tor Browser 7.0.4 and 7.5a4.

Just for the record: the patches don't mess with TLS indicators and with the concept of a secure context (which is often bound to HTTPS) on purpose. I think we should be very wary of blurring the line between TLS with a CA-signed certificate and onion services. However, that does not mean that only TLS traffic is authenticated and encrypted and everything else is untrusted and has to be treated accordingly.

comment:54 in reply to:  45 Changed 2 weeks ago by cypherpunks

Replying to gk:

But we might be able to bypass that hassle by using other means provided in that spec, in particular treating .onions as potentially trustworthy origins (https://w3c.github.io/webappsec-secure-contexts/#is-origin-trustworthy):

Make an encrypted channel between Tor and Tor Browser to get

A potentially trustworthy origin is one which a user agent can generally trust as delivering data securely.

Note: See TracTickets for help on using tickets.