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

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.

added GeorgKoppen201708 TorBrowserTeam201708R component::applications/tor browser ff52-esr owner::tbb-team priority::high resolution::fixed severity::blocker status::closed tbb-7.0-frequent tbb-7.0-issues tbb-usability type::task ux-team 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

#21877 (moved) is a duplicate.

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

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

#8686 (moved) is related (see the closed duplicate #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.

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

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