1731984 - Security icons should only imply secure when the the communication is properly end-to-end encrypted

Status: NEW

(MailNews Core :: Security: OpenPGP, defect, P3)

Description

[Magnus Melin [:mkmelin]]

For prior discussion, see bug 1624676 comment 31 and some of the below.

For non-technical (=most) users IMO this is perhaps the single largest UI failure we have related to how we communicate the state of message security: we show encryption and signing separately, and a green encryption lock when the message was decrypted correctly (sick!).

How end to end security works is difficult to explain to end users. That something is encrypted doesn't really mean a thing in it self. That just means the content was hidden some point during the transport (maybe by the sender, maybe by someone attacking, maybe by surveillance, maybe by the ISP or server admin): whether the content was sent by the purported sender is really anybody's guess. And that is the beef around security.

What people don't realize is that only a (preferably verified) signature gives any kind of security in the sense of being able to trust that the message content is what it should be, and importantly an attacker or mass surveillance did not simply read an relay the message to you after they did that.

So, essentially, regarding what normally is perceived as security does not happen when the message is not signed+encrypted. Displaying "security ok" for unsigned can be compared to the case where big services would use self-signed certificates. The browser will have you click through scary dialogs even to view, while for secure messages at the moment we just show a big green "ok" icon. It's so not ok...

Comment 1

[Magnus Melin [:mkmelin]]

Nicolas, this could be a very good project to explore and also do some user testing on to see if users understand when they are secure or not.

Comment 2

[Nicolas Falquet]

Attachment: Screenshot from 2021-09-22 12-52-38.png

Here is what I have in daily with an encrypted and unsigned email.

I totally agree with you. The padlock with a green check looks problematic to me as well.

We should not create a false sense of security with encrypted and unsigned emails. Your comparison with self-signed certificates is spot on!

I could test new icons and variations with users. I see some proposed on bug#1624676 but haven't read all of them yet.

Comment 3

[Magnus Melin [:mkmelin]]

We didn't have time to fix it back then, but it should be possible now. I really think it needs to be only one icon shown in total so that e.g. encrypted unsigned won't ever be displayed as better than encrypted signed.
Displaying state of signature separately is mostly just confusing matters... though it should be accessible somewhere for the times you care.

Comment 4

[Nicolas Falquet]

To support this, during the usability tests in February, I sent an email that was encrypted but not signed to the test participants. The email included the public key of activists taking part in a fictitious action:

• None of the test participants realized that the message was unsafe.
• 5 out of 7 participants sent sensitive information to 1 rogue that was included in the email.

In the debriefing, I asked some participants to identify which of my email was "unsafe" and they all took a while to find it, if ever.

Here is a video clip from P3, a German journalist and one of the most tech-savvy participants:

https://un.poivron.org/~nf/thunderbird-openpgp/clips/signature.webm

Comment 5

[Nicolas Falquet]

For example, Thunderbird could display a scary red notification of top of emails that are encrypted but unsigned.

Comment 6

[u617804]

Currently, received unencrypted+unsigned mails are displayed as "normal" mail "without any security problem" (no special warning icon), while in fact they are completely unsecure.
I think received encrypted+unsigned mails are not less secure than received unencrypted+unsigned mails.
Therefore I would suggest to display both the same way (no special icon), so for the user it makes no difference and TB does not make any security claim about them.

Comment 7

[u617804]

(In reply to Magnus Melin [:mkmelin] from comment #0)

only a (preferably verified) signature gives any kind of security

I do not understand why having a verified signature is not mandatory? What value has a signature from someone who can be anybody? Can MITM when encrypting also not just add a signature?

Displaying "security ok" for unsigned can be compared to the case where big services would use self-signed certificates

Here you talk only of unsigned mail but compare it with unverified (self-)signed webserver certificates, so I guess a unverified mail signature would not be better?

Comment 8

[Magnus Melin [:mkmelin]]

(In reply to Arvidt from comment #7)

I do not understand why having a verified signature is not mandatory? What value has a signature from someone who can be anybody? Can MITM when encrypting also not just add a signature?

Please note the difference between accepted and verified signature. If it's an accepted signature, you still get most benefits, e.g. you know this was the same user or attacker as in the past. With only accepted you don't know if it's the real user or a middleman/attacker.

Displaying "security ok" for unsigned can be compared to the case where big services would use self-signed certificates

Here you talk only of unsigned mail but compare it with unverified (self-)signed webserver certificates, so I guess a unverified mail signature would not be better?

Not too much better, BUT: for that we show the question mark (?) and color, so we don't say that's totally ok.
If the attacker leaves out the signature, we only display all ok because the encryption (hiding during transport from the attacker) is technically correct!

Comment 9

[u617804]

Just found this in RFC 7435 Opportunistic Security Design Principles:

No misrepresentation of security: Unauthenticated, encrypted
communication must not be misrepresented to users or in
application logs of non-interactive applications as equivalent to
authenticated, encrypted communication.