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

added GeorgKoppen201708 in Legacy / Trac TorBrowserTeam201708R in Legacy / Trac component::applications/tor browser in Legacy / Trac ff52-esr in Legacy / Trac owner::tbb-team in Legacy / Trac priority::high in Legacy / Trac resolution::fixed in Legacy / Trac severity::blocker in Legacy / Trac status::closed in Legacy / Trac tbb-7.0-frequent in Legacy / Trac tbb-7.0-issues in Legacy / Trac tbb-usability in Legacy / Trac type::task in Legacy / Trac ux-team in Legacy / Trac labels

Trac:
Keywords: N/A deleted, tbb-usability-website, ff52-esr added

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.

Trac:
Username: tokotoko
Cc: N/A to fdsfgs@krutt.org

legacy/trac#21877 (moved) is a duplicate.

Trac:
Cc: fdsfgs@krutt.org to fdsfgs@krutt.org, blockflare

legacy/trac#22545 (moved) is a duplicate.

Trac:
Cc: fdsfgs@krutt.org, blockflare to fdsfgs@krutt.org, blockflare, mrphs
Keywords: tbb-usability-website deleted, tbb-usability, ux-team added
Priority: Medium to High
Severity: Normal to Major

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

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

legacy/trac#8686 (moved) is related (see the closed duplicate legacy/trac#22483 (moved) as well).

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")?

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).

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

Trac:
Cc: fdsfgs@krutt.org, blockflare, mrphs to fdsfgs@krutt.org, blockflare, mrphs, catalyst

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?

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".

https://trac.torproject.org/projects/tor/ticket/13410

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.

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).

Trac:
Username: guido
Cc: fdsfgs@krutt.org, blockflare, mrphs, catalyst to fdsfgs@krutt.org, blockflare, mrphs, catalyst, guido@dis.tur.bio

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 legacy/trac#22545 (moved). 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.

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.

Trac:
Severity: Major to Blocker

Trac:
Cc: fdsfgs@krutt.org, blockflare, mrphs, catalyst, guido@dis.tur.bio to fdsfgs@krutt.org, blockflare, mrphs, catalyst, guido@dis.tur.bio, mcs

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

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

Trac:
Keywords: N/A deleted, TorBrowserTeam201706 added

See legacy/trac#22693 (moved) for a possible fingerprinting problem associated with the warning message.

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.

Trac:
Cc: fdsfgs@krutt.org, blockflare, mrphs, catalyst, guido@dis.tur.bio, mcs to fdsfgs@krutt.org, blockflare, mrphs, catalyst, guido@dis.tur.bio, mcs, asn

Replying to mrphs:

I've explained how I think about this issue to some extent on legacy/trac#22545 (moved). 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.)

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

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.

Replying to yawning:

HSTS is a thing.

Yeah, and how many websites use it?

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.

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.".

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.

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.

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.

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.

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

Moving Tickets to July 2017.

Trac:
Keywords: TorBrowserTeam201706 deleted, TorBrowserTeam201707 added

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.

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).

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 , there should too be a padlock for when http resources get loaded with an onion site (as you proposed in legacy/trac#21952 (moved)).

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.

Trac:
Keywords: N/A deleted, tbb-7.0-issues, GeorgKoppen201707 added

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.

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.

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.

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.

Trac:
Cc: fdsfgs@krutt.org, blockflare, mrphs, catalyst, guido@dis.tur.bio, mcs, asn to fdsfgs@krutt.org, blockflare, mrphs, catalyst, guido@dis.tur.bio, mcs, asn, arthuredelstein
Status: new to needs_review
Keywords: TorBrowserTeam201707 deleted, TorBrowserTeam201707R added

Tracking frequent 7.0 reports

Trac:
Keywords: N/A deleted, tbb-7.0-frequent added

I added a comment in oniongit.

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?

Moving review tickets to August.

Trac:
Keywords: TorBrowserTeam201707R deleted, TorBrowserTeam201708R added

Moving my tickets to August.

Trac:
Keywords: GeorgKoppen201707 deleted, GeorgKoppen201708 added

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.

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 30b633b9 and 7a03cca9) and tor-browser-52.2.0esr-7.5-1 (commits df2223e1 and 490f3cc2). 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.

Trac:
Resolution: N/A to fixed
Status: needs_review to closed

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.

Replying to 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.

It's not HSTS that should be spoken about but HPKP. And FYI Google is abandroning HPKP: theregister.co.uk/2017/10/30/google_hpkp

HPKP is dead, and there's no way to save it, it's only a matter of time now: https://scotthelme.co.uk/the-death-knell-for-hpkp/ Only 6,616 out of the top 1 million Alexa websites were having it set up (Aug 2017, about 50% of them from tumblr subdomains) https://scotthelme.co.uk/alexa-top-1-million-analysis-aug-2017/

At that point one would have to be I don't know to suggest that we shouldn't be "blurring the lines between "http over onions" and "https"."