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

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

Related old ticket: legacy/trac#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 legacy/trac#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 legacy/trac#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

Replying to tom:

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.

+1 to all of those. I have no clear opinion yet (either) on whether we should show an HTTP .onion as grey or green.

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

From the meeting today:

Icon Styles we can choose from. (You may need FF 58 to view these the way tjr sees them.)

Green Padlock with EV Banner 

Green Onion with EV Banner 


Green Padlock: https://sha512.badssl.com/ 

Green Onion

The four above states indicate complete trust in the website. The EV Banner is used to convey identity information, to positive indicate you are talking to this specific company that operates this website.

Green Padlock with warning - https://self-signed.badssl.com/ (used for excepted self-signed certs this one is WEIRD)

This state is weird. We shouldn't need it. It indicates that while the connection is secure, the browser thought it might not be secure but you went and told the browser no really this is secure.

Grey Padlock with warning - https://mixed.badssl.com/ 

Grey Onion with warning

These icons indicate that the website is mostly secure, but that there was a problem with the configuration. It could be better, but it's not INSECURE.

Grey Padlock with Red Strikethrough - http://http-password.badssl.com/ 

Grey onion with Red Strikethrough

These icons indicate something is DEFINETLY INSECURE

Grey Onion

Grey Padlock

These icons don't exist. We could make them, but we would need to define what they mean.

Missing Entirely http://http.badssl.com/

This is a legacy state. It's for HTTP. It's insecure because it's not actually secure, but we don't want to say it's insecure because we'd put it on so much of the web we'd scare users.

I believe this table represents current thinking.


    Onion over HTTP:                 ???????

    Onion with Self-Signed HTTPS:    ???????

    Onion with CA-Issused DV Cert:   Green Onion

    Onion with CA-Issused EV Cert:   Green Onion with EV Banner 


    Mixed Content Scenarios: 

    A HTTPS Site embeds onion:
       HTTPS Site with HTTP Onion Subresources:              Keeps Original Padlock (whether that was Green or w/ Warning or whatever)
       HTTPS Site with HTTPS Onion Subresources:             Keeps Original Padlock
       HTTPS Site with HTTPS Self-Signed Onion Subresources: Keeps Original Padlock


    An Onion embeds HTTP:
       HTTP Onion with HTTP Subresources:               Grey onion with Red Strikethrough
       HTTPS Onion with HTTP Subresources:              Grey onion with Red Strikethrough 
       HTTPS Self Signed Onion with HTTP Subresources:  Grey onion with Red Strikethrough

    An onion embeds HTTPS:
       HTTP Onion with HTTPS Subresources:              ???????
       HTTPS Onion with HTTPS Subresources:             Green Onion (with EV Banner if EV certificate)
       HTTPS Self Signed Onion with HTTPS Subresources: Grey Onion with warning

Replying to tom:

From the meeting today:

I believe this table represents current thinking.

Hello tjr, I posted some thoughts on the various options on the pad. Check them out and please enrich them with your thoughts! :)

Based on last week meeting, I have been working on the .onion services states outlined before in this thread.

As you may see, I continued working on the .onion icon trying to make it more clear and visible even in small sizes(8px/14px).

https://trac.torproject.org/projects/tor/attachment/ticket/23247/23247-2.png

Firefox is deprecating the lockpad related icons to inform security states based on their design documentation: https://design.firefox.com/icons/viewer/

As we talked at #tor-project, it is something we need to figure out if we want to keep consistency with FF.

Let me know your thoughts!

I spoke with Mozilla's crypto engineering team - they're not aware of any padlock deprecation, so I think the design guide is a separate thing.

Replying to tom:

I spoke with Mozilla's crypto engineering team - they're not aware of any padlock deprecation, so I think the design guide is a separate thing.

ACK thanks for asking. That's good. This means we can continue considering onions in the URL bar.

BTW, you guys that are at All Hands this week, would you be able to figure out the tradeoffs about onion color on HTTP vs self-signed HTTPS? There is a debate in the end of the pad that might help you. All Hands seems like a good place to figure this debate out!

Trac:

Replying to asn:

Replying to tom:

I spoke with Mozilla's crypto engineering team - they're not aware of any padlock deprecation, so I think the design guide is a separate thing.

ACK thanks for asking. That's good. This means we can continue considering onions in the URL bar.

BTW, you guys that are at All Hands this week, would you be able to figure out the tradeoffs about onion color on HTTP vs self-signed HTTPS? There is a debate in the end of the pad that might help you. All Hands seems like a good place to figure this debate out!

I talked to a few people there, but didn't take a big survey. Trend seems to be that positive indicators are 'blah' and we should move to only negative indicators and in a positive state show nothing.

Another vote, separate from that discussion, was a very strong 'no positive indicator for .onion'

The following SOUPS 2016 paper seems very relevant to this ticket. It was written by people from the Chrome security team and their work resulted in the indicators we see in Chrome today: https://www.usenix.org/system/files/conference/soups2016/soups2016-paper-porter-felt.pdf

I skimmed parts of the paper and found the following two takeaways relevant:

Section 1:

The indicator's meaning needs to be taught with words when possible. Millions of new Internet users have recently come online via smartphones without learning "standard" iconography from desktop browsers.

We may also want to change the text next to the onion icon. In the paper, in Table 4, they evaluated what string users most associate with security and "secure" won, closely followed by "https," which they deemed too technical. Another of their candidates was "secure and private" which may be suitable in our case. I worry that just replacing the lock icon with an onion may not make it clear what's different -- in particular because onions are typically not associated with security.

Section 3.1:

Making major modifications to this [lock] symbol, such as using a different object, may be disorienting: users now expect to find a lock in a browser window.

I wonder if the presence of an onion will confuse some people? Another way forward would be to use the lock icon for onion services too but change the string from "secure" to "secure and private."

Trac:
Cc: asn, arthuredelstein, tor@antonela.me to asn, arthuredelstein, tor@antonela.me, phw

So where do we think we are here? Do we think it's worth yet another meeting or do we have a plan laid out?

Replying to asn:

So where do we think we are here? Do we think it's worth yet another meeting or do we have a plan laid out?

Good question. I'll put this onto the meeting agenda for our Tor Browser meeting tomorrow.

Actually isa already answered that on the meeting pad on Feb 12:

 [isa: is pending a task from me asked by Geko which is to create a new doc with the final states we are implementing and copy (cleaner version from what is currently linked on the ticket) then after that it should be planned/added for implementation at TB roadmap in Rome]

Trac:
Priority: Medium to High
Cc: asn, arthuredelstein, tor@antonela.me, phw to asn, arthuredelstein, tor@antonela.me, phw, pospeselr
Keywords: N/A deleted, TorBrowserTeam201804 added

Cleaned up and updated all stated with icon and copy:

https://docs.google.com/document/d/1bPrNLIl7Qy-sA7aTfElu80Xk2eXzTfH_5BGTOUDK8XU/edit#

Replying to isabela:

Cleaned up and updated all stated with icon and copy:

https://docs.google.com/document/d/1bPrNLIl7Qy-sA7aTfElu80Xk2eXzTfH_5BGTOUDK8XU/edit#

In looking over the above document, the only scenario that surprised me was "HTTPS Site with HTTPS Self-Signed Onion Subresources" which has an onion icon (I expected a padlock).

Replying to brade:

Replying to isabela:

Cleaned up and updated all stated with icon and copy:

https://docs.google.com/document/d/1bPrNLIl7Qy-sA7aTfElu80Xk2eXzTfH_5BGTOUDK8XU/edit#

In looking over the above document, the only scenario that surprised me was "HTTPS Site with HTTPS Self-Signed Onion Subresources" which has an onion icon (I expected a padlock). Padlock downgrades to onion icon to reflect "Self-Signed Onion" trick. And for "HTTPS Site with HTTP Onion Subresources" too, please.

Replying to brade:

Replying to isabela:

Cleaned up and updated all stated with icon and copy:

https://docs.google.com/document/d/1bPrNLIl7Qy-sA7aTfElu80Xk2eXzTfH_5BGTOUDK8XU/edit#

In looking over the above document, the only scenario that surprised me was "HTTPS Site with HTTPS Self-Signed Onion Subresources" which has an onion icon (I expected a padlock).

Yes, I think it should have a padlock. I think isa may have missed this case when e updated the other ones in this section?

Replying to tom:

Replying to brade:

Replying to isabela:

Cleaned up and updated all stated with icon and copy:

https://docs.google.com/document/d/1bPrNLIl7Qy-sA7aTfElu80Xk2eXzTfH_5BGTOUDK8XU/edit#

In looking over the above document, the only scenario that surprised me was "HTTPS Site with HTTPS Self-Signed Onion Subresources" which has an onion icon (I expected a padlock).

Yes, I think it should have a padlock. I think isa may have missed this case when e updated the other ones in this section?

Seems to me this is fixed now in the doc. I think the doc Looks Good To Me right now.

FWIW it's important to keep this timeline in mind especially the coming deprecation of the lock icon (2019) for HTTPS https://blog.cloudflare.com/https-or-bust-chromes-plan-to-label-sites-as-not-secure/

Google will announce the lock icon’s demise in 2018 and remove it in January 2019 with the release of Chrome 72

Trac:
Cc: asn, arthuredelstein, tor@antonela.me, phw, pospeselr to asn, arthuredelstein, tor@antonela.me, phw, pospeselr, dmr

Replying to cypherpunks:

FWIW it's important to keep this timeline in mind especially the coming deprecation of the lock icon (2019) for HTTPS https://blog.cloudflare.com/https-or-bust-chromes-plan-to-label-sites-as-not-secure/

Google will announce the lock icon’s demise in 2018 and remove it in January 2019 with the release of Chrome 72

Just to place the quote into context: This is a //guess/prediction// by CloudFlare. That Chrome will eventually deprecate the lock icon seems to be part of their rough plan from 2014, but there is no set timeframe indicated in the article. (Still good to keep in mind, however.)

Chris Palmer's [to blink-dev] in 2014 included this "strawman proposal" for introducing negative indicators and phasing out the marking of secure origins entirely:

Secure > 65%: Non-secure origins marked as Dubious Secure > 75%: Non-secure origins marked as Non-secure Secure > 85%: Secure origins unmarked

Trac:
Keywords: N/A deleted, tor-hs added

Trac:
Status: new to assigned
Owner: tbb-team to pospeselr

Trac:
Cc: asn, arthuredelstein, tor@antonela.me, phw, pospeselr, dmr to asn, arthuredelstein, tor@antonela.me, phw, pospeselr, dmr, brade, mcs

Trac:
Cc: asn, arthuredelstein, tor@antonela.me, phw, pospeselr, dmr, brade, mcs to asn, arthuredelstein, tor@antonela.me, phw, pospeselr, dmr, brade, mcs, tbb-team

Move our roadmap tickets to May.

Trac:
Keywords: TorBrowserTeam201804 deleted, TorBrowserTeam201805 added

Replying to dmr:

Replying to cypherpunks:

FWIW it's important to keep this timeline in mind especially the coming deprecation of the lock icon (2019) for HTTPS https://blog.cloudflare.com/https-or-bust-chromes-plan-to-label-sites-as-not-secure/

Google will announce the lock icon’s demise in 2018 and remove it in January 2019 with the release of Chrome 72

Just to place the quote into context: This is a //guess/prediction// by CloudFlare. That Chrome will eventually deprecate the lock icon seems to be part of their rough plan from 2014, but there is no set timeframe indicated in the article. (Still good to keep in mind, however.)

It's official: in September 2018, Google will stop marking HTTPS sites as secure (but there's a non-green doorhanger still). https://blog.chromium.org/2018/05/evolving-chromes-security-indicators.html

Full doorhanger removal will happen "eventually", and CloudFlare's prediction is it will happen "in January 2019 with the release of Chrome 72".

Trac:

http onion Page Info window

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

Final Version

Designs

Child items ...

Activity