Opened 6 months ago

Last modified 2 days ago

#23247 new project

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

Reported by: isabela Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: ux-team
Cc: asn, arthuredelstein, tor@…, phw Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description (last modified by linda)

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

Child Tickets

Attachments (3)

padlock states FF and TB.png (468.0 KB) - added by antonela 3 months ago.
onion-mockup.png (20.3 KB) - added by pospeselr 3 months ago.
23247-2.png (554.6 KB) - added by antonela 2 months ago.

Download all attachments as: .zip

Change History (32)

comment:1 Changed 6 months ago by linda

Related old ticket: #8686

comment:2 Changed 6 months ago by linda

Type: defectproject

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

comment:3 Changed 6 months ago by linda

Description: modified (diff)
Summary: creating padlock states for .onion services on tool barCommunicating security expectations for .onion: what to say about different padlock states for .onion services

comment:4 Changed 6 months ago by linda

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

comment:5 Changed 6 months ago by tom

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:

  1. HTTPS Site with HTTP Onion Subresources
  2. HTTPS Site with HTTPS Onion Subresources
  3. HTTPS Site with HTTPS Self-Signed Onion Subresources
  4. HTTP Onion with HTTP Subresources
  5. HTTPS Onion with HTTP Subresources
  6. HTTPS Self Signed Onion with HTTP Subresources
  7. HTTP Onion with HTTPS Subresources
  8. HTTPS Onion with HTTPS Subresources
  9. 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:

  1. Onion over HTTP: Green
  2. Onion with Self-Signed HTTPS: Green
  3. Onion with CA-Issused EV Cert: Green with EV Banner [0]
  4. Mixed Content Scenarios:
    1. HTTPS Site with HTTP Onion Subresources: Green (no mixed content warning) - but we remove the EV Banner if present [1]
    2. HTTPS Site with HTTPS Onion Subresources: Green or Green w/ EV Banner (no mixed content warning)
    3. HTTPS Site with HTTPS Self-Signed Onion Subresources: Green (no mixed content warning) - but we remove the EV Banner if present [1]
    4. HTTP Onion with HTTP Subresources: Red
    5. HTTPS Onion with HTTP Subresources: Red
    6. HTTPS Self Signed Onion with HTTP Subresources: Red
    7. HTTP Onion with HTTPS Subresources: Strikethrough
    8. HTTPS Onion with HTTPS Subresources: Strikethrough
    9. 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.

comment:6 Changed 3 months ago by asn

Cc: asn added

comment:7 Changed 3 months ago by tom

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

comment:8 Changed 3 months ago by tom

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

Changed 3 months ago by antonela

comment:9 Changed 3 months ago by antonela

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! :)

comment:10 Changed 3 months ago by cypherpunks

@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?

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

comment:11 in reply to:  8 Changed 3 months ago by asn

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.

comment:12 Changed 3 months ago by arthuredelstein

Cc: arthuredelstein added

comment:13 Changed 3 months ago by tom

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.

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

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

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

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

comment:14 Changed 3 months ago by arthuredelstein

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.

comment:15 Changed 3 months ago by antonela

Cc: hola@… added

comment:16 Changed 3 months ago by antonela

Cc: hola@… removed

Changed 3 months ago by pospeselr

Attachment: onion-mockup.png added

comment:17 Changed 3 months ago by pospeselr

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

comment:18 in reply to:  13 Changed 3 months ago by gk

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.

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

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

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

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

comment:19 Changed 3 months ago by antonela

Cc: tor@… added

comment:20 Changed 3 months ago by tom

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

comment:21 in reply to:  20 Changed 3 months ago by asn

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! :)

comment:22 Changed 2 months ago by antonela

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!

comment:23 Changed 2 months ago by 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.

comment:24 in reply to:  23 ; Changed 2 months ago by 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!

Changed 2 months ago by antonela

Attachment: 23247-2.png added

comment:25 in reply to:  24 Changed 2 months ago by tom

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'

comment:26 Changed 3 weeks ago by phw

Cc: phw added

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

comment:27 Changed 10 days ago by 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?

comment:28 in reply to:  27 Changed 3 days ago by gk

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.

comment:29 Changed 2 days ago by gk

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]
Note: See TracTickets for help on using tickets.