Communicating security expectations for .onion: what to say about different padlock states for .onion services

added TorBrowserTeam201806R component::applications/tor browser owner::pospeselr priority::high resolution::fixed severity::normal status::closed tor-hs type::project ux-team labels

Related old ticket: #8686 (moved)

I've switched this from a task to a project, for organizational purposes.

Trac:
Type: defect to project

Trac:
Description: Firefox (and other browsers) have created a set of states a site can have in relationship with ssl certificates, and how to communicate that to the user.

Tor Browser has a particular state related to the padlock at the toolbar when it comes to .onion services.

This is something that was discussed under this ticket:

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

Based on that discussion, we decided that the best solution would be treat .onion sites different when we are communicating these states for .onion sites at Tor Browser.

The work on this ticket is to map all the current states Firefox has for ssl certificates on the padlock, and from there start to build a new way to communicate these states when they are related to a .onion sites.

We start mapping them here:

https://docs.google.com/document/d/1KHkj2DpmFMB0mjHEfehD5ztY2L0lQzKNtZqct1TXbmg/edit

Is still pending the most difficult part of the work, which is to define what to do for .onion sites on those states.

to

= Background =

Firefox (and other browsers) have created a set of states a site can have in relationship with ssl certificates, and how to communicate that to the user.

Currently, Tor Browser doesn't communicate ideally to users that visit onion sites--i.e. http + onion looks really scary with lots of warnings! This is something that was discussed under #21321 (moved). We then realized that we should look at all the different state + .onion combinations, and carefully communicate what these mean to the user.

= Objective =

The work on this ticket is to map all the current states Firefox has for ssl certificates on the padlock, and from there start to build a new way to communicate these states when they are related to a .onion sites. We started mapping them here:

https://docs.google.com/document/d/1KHkj2DpmFMB0mjHEfehD5ztY2L0lQzKNtZqct1TXbmg/edit

Is still pending the most difficult part of the work, which is to define what to do for .onion sites on those states.
Summary: creating padlock states for .onion services on tool bar to Communicating security expectations for .onion: what to say about different padlock states for .onion services

Relevant to this discussion, an idea I ended up not liking #21952 (moved) and conclusion.

I think there are more states not in that doc (specifically related to Mixed Content) - or at least there are nuances of the single mixed content line:

HTTPS Site with HTTP Onion Subresources
HTTPS Site with HTTPS Onion Subresources
HTTPS Site with HTTPS Self-Signed Onion Subresources
HTTP Onion with HTTP Subresources
HTTPS Onion with HTTP Subresources
HTTPS Self Signed Onion with HTTP Subresources
HTTP Onion with HTTPS Subresources
HTTPS Onion with HTTPS Subresources
HTTPS Self Signed Onion with HTTPS Subresources

1-3 can be described as "A clearnet website embeds onion stuff" 4-6 as "An onion website embeds clearnet stuff over HTTP" 7-9 as "An onion website embeds clearnet stuff over HTTPS"

(I think that's comprehensive...)

There are five padlock styles:

Green with EV Banner
Green
Strikethrough
Red
Missing Entirely.

My opinion about behavior:

Onion over HTTP: Green
Onion with Self-Signed HTTPS: Green
Onion with CA-Issused EV Cert: Green with EV Banner [0]
Mixed Content Scenarios:
HTTPS Site with HTTP Onion Subresources: Green (no mixed content warning) - but we remove the EV Banner if present [1]
HTTPS Site with HTTPS Onion Subresources: Green or Green w/ EV Banner (no mixed content warning)
HTTPS Site with HTTPS Self-Signed Onion Subresources: Green (no mixed content warning) - but we remove the EV Banner if present [1]
HTTP Onion with HTTP Subresources: Red
HTTPS Onion with HTTP Subresources: Red
HTTPS Self Signed Onion with HTTP Subresources: Red
HTTP Onion with HTTPS Subresources: Strikethrough
HTTPS Onion with HTTPS Subresources: Strikethrough
HTTPS Self Signed Onion with HTTPS Subresources: Strikethrough

[0] Security concern: Make sure EV banner only displays for CA-signed EV certs and not self-signed EV certs! [1] Removing the EV banner might be difficult, but in the ideal situation I think we should.

I reserve the right to change my mind, but this is what I am thinking right now.

Trac:
Cc: N/A to asn

Talking about this with asn on irc the following came up. Is there is a difference between a self-signed certificate and other types of invalid ssl certificates?

E.g. A self-signed cert with the correct name vs a CA-signed cert with the incorrect name.

IF we show a green icon for a self-signed cert with the correct name, someone who is actually running a malicious onion and gets you to visit it and change all other situations (ca-signed cert with incorrect name) to one that gets you a green icon. So showing a warning page for any other situation provides no security. BUT maybe it provides the webmaster with an indicator that their server was misconfigured and is not sending the certificate they should send?

(Alternately, maybe we don't want to send that indicator because it now requires webmasters who have a working example.com cert and configuration to not only deploy a .onion but deploy a new vhost pointing at the same config and serve that vhost a separate SSL cert which is configuration they could otherwise avoid.)

More discussion: there are definitely better ways to surface a potential misconfiguration to a site admin than an intersitial. A console warning/error or (if we want to surface something to UI) a mixed content icon.

There's also the notion of showing different icons for self-signed .onion (grey onion?) vs DV-ca-signed .onion (green onion?)

Trac:

As we signed last week, I started to work on the UI cases for .onion services states. This is the first approach and could totally change during this process.

https://trac.torproject.org/projects/tor/attachment/ticket/23247/padlock%20states%20FF%20and%20TB.png

I re-worked the Onion glyph in order to work better on small sizes. Also, I included colors based on the current Firefox UI.

If we are on track with this ones, we can move forward with Doorhangers components. I think we are going to use doorhangers for mixed content states and for EV-style https certificates.

http://design.firefox.com/photon/components/doorhangers.html

Let me know what do you think, thanks! :)

@antonela

Looks pretty damn neat for a first try. One remark though, isn't the "Onion" near it redundant? Considering that onion addresses will become more than 50 characters long, and that the Tor Browser size is generally around 1000x600, so there are strong incentives to preserve as much space as possible for the address bar.

Also I think there should be a better idea on distinguishing between http/https onions, a "yellow" version suggests that it is less secure. Maybe "purple" would be better in the case of http onion?

Replying to tom:

There's also the notion of showing different icons for self-signed .onion (grey onion?) vs DV-ca-signed .onion (green onion?)

Hm. Reason this idea is good:

Will be easier for users to distinguish between real facebook onion (DV-ca-signed green onion) and phishing facebook onion (self-signed grey onion).

Reason this idea is bad:

It basically gives no way for onion site operators to get the green onion without paying the CA mafia.

How does Let's Encrypt blend into the above idea? Would it give a green-onion or not? If yes, then phishers can just use a Let's Encrypt cert to get the green onion anyway.

Trac:
Cc: asn to asn, arthuredelstein

Right now you can't get a DV onion cert. There's a recent thread on drafting a ballot to allow them in the CAB Forum, with early support, but there's no guarantee it will pass. No DV onion certs means no Let's Encrypt. And once DV is allowed, LE would need to develop the software needed to validate .onions automatically, which would take some time as well.

My thoughts:

Graphics wise I think all of them look good.

I don't think we should put the word 'Onion' either though. In fact, doing so overloads the location where EV data is displayed, so if I got a company called 'Onion' I could make it look like I had an onion address!

I'm not sure what the (i) button is intended to show graphics wise. "There is information for you to review here"? I presume it opens the current doorhanger thing that lets you get certificate information and review permissions.

I don't know if there was a path forward agreed upon that was not documented here, but policy-wise this is a bit different from what I at least envisioned.

An HTTP Onion is Orange. Orange indicates a warning state. I don't believe we should communicate that HTTP Onion is 'warning'. It's almost always better than HTTP in fact, which we give 'grey' treatment. So I think HTTP+Onion should either be Grey or Green.
EV HTTPS + Onion has an info bubble but does not display the company name like EV does for HTTPS. I think we should be consistent here and display the company name here.
I don't understand why HTTPS onion lacks a (i) but self-signed HTTPS onion has it. Both of them should let you review the information. So the (i) definetly is implying some sort of state about the website, but it's confusing what I'm supposed to be able to draw from this.
It seems like we need to make a decision: is a self-signed SSL cert on a .onion: a) completely meaningless b) an indicator something is wrong c) an indicator of trust.

These would correspond to: a) the same icon as a http onion b) an orange or red icon c) a green icon

I don't think a self-signed cert is an indicator of trust, so it wouldn't automatically mean it gets a green icon. I also don't think it's an indicator something is wrong, so automatically giving it orange or red are out too. So it should match an HTTP Onion icon but allow you to view the certificate in the doorhanger.

My 2 cents.

I think it would be nice to give the user a hint that an onion connection is encrypted. Maybe the icon could be a padlock superimposed on an onion? Or we could continue to show the padlock but use the word "Onion" instead of "Secure".

Of course, there's the added complication of that the padlock might be intended to convey both "encrypted" and "externally authenticated", but that model isn't quite the same for onions. I'm not sure how to deal with this complication.

Trac:
Cc: asn, arthuredelstein to asn, arthuredelstein, hola@antonela.me

Trac:
Cc: asn, arthuredelstein, hola@antonela.me to asn, arthuredelstein

Trac:

I realize we might be a bit constrained by Mozilla's design language for Firefox, but speaking as someone that's mildly red-green colour-blind, please don't differentiate important states solely through a red/green/grey/orange colour change. Even for colour-blind users that can tell a difference if they actually look at it (such as myself) the difference isn't going to be attention grabbing and may as well not exist.

For .onion addresses, why not just add a Green onion icon beside whatever existing icon/text Firefox already uses to communicate HTTPS information?

Something like this: https://trac.torproject.org/projects/tor/attachment/ticket/23247/onion-mockup.png

Communicating security expectations for .onion: what to say about different padlock states for .onion services

Final Version

Child items 0

Activity