31896 - lock icon distinguish between weak and strong encryption

Status: VERIFIED FIXED

(Core Graveyard :: Security: UI, enhancement, P3)

Description

[John G. Myers]

If an SSL connection is using encryption weaker than 90 bits, the lock icon 
should be displayed in the insecure (open) state.

Comment 1

[Chris Newman]

User interfaces need to be intuitive, so the "lock" icon should indicate "secure" rather than "crackers can eavesdrop if they care enough".  Every time I've explained what the lock icon really means to a non-computer person, they're shocked.  I'm sure it makes tech support harder for banks requiring 128-bit when they have to explain to customers that the browser isn't secure even though it appears to be secure on other online shopping sites.

Comment 2

[Doug Turner (:dougt)]

would be nice.  Assinging to myself.  Setting milestone.

Comment 3

[John Unruh]

Changing QA to me.

Comment 4

[Doug Turner (:dougt)]

Reassigning all https/cartman/security bugs to valeski.  He will be finding new 
owner(s).  This shift is so that I can focus on embedding issues.  If the new 
owner has questions that can not be resovled, I may be able to lend a (quick) 
hand.

over to valeski....

Comment 5

[Javier Delgadillo]

re-assigning

Comment 6

[John G. Myers]

I'll take this.

Comment 7

[John Unruh]

cc'ing people

Comment 8

[John Unruh]

Setting milestone to future.

Comment 9

[Angela Butler]

Added angelabu to cc: list

Comment 10

[John Unruh]

nsbeta1

Comment 11

[John G. Myers]

Attachment: First part of fix: distinguish between strong & weak ciphers

Comment 12

[Javier Delgadillo]

The patch looks fine, I just worry that this will cause a backlash from web 
developpers saying, "We're using SSL, therefore we're secure.  Switch to a 
different client that doesn't bring up that message."

How many web sites have you run into this message for?

Comment 13

[John G. Myers]

At home I normally run with weak ciphers disabled, so I get a handshake failure 
on sites that only use weak crypto.  I've seen two or three such sites, but then 
I don't do a whole lot of online shopping.

As you'll note, the warning can be disabled just like the other warnings.

Comment 14

[John G. Myers]

The proposed patch adds a new possible state "low" to the existing 
security levels "high", "broken", and the unset state indicating insecure.  It 
also adds an additional "Entering site" warning which is used instead of the 
"You have requested a secure document" for weak sites.  Like the other "Entering 
site" warnings, it can be disabled by a checkbox.

It is up to the theme to choose the lock icon to display for weak sites.  I 
intend to submit a patch for the three existing themes that chooses the insecure 
"unlocked" icon until theme designers decide to design a new icon.

Changing summary.

Comment 15

[David Woodhouse]

If it's really a concern that incompetent or malicious server admins could tell
clients that the problem is with their browser rather than with the crippled
server, then perhaps the message could be rephrased slightly to make it clear
that the weak encryption is occurring because the _server_ doesn't support real
encryption, and that while less security-conscious browsers may not warn about
this, they still won't be able to actually use real encryption.

Something like.... "Although the web server to which you have connected uses
encryption, it is not capable of providing the full level of security supported
by Mozilla. The most secure encryption which the server is capable of is
considered by many to be insufficient for the transfer of sensitive information
such as passwords or credit card numbers. Although less security-conscious
browsers may not warn about this problem, they will not be able to establish a
more secure connexion unless the server is upgraded."

Comment 16

[John G. Myers]

The dialog box does try to point the finger squarely at the server.  The message 
does, however, have to be succinct.  Perhaps to remove an ambiguity the word 
"using" should be changed to "which uses".

Comment 17

[David Woodhouse]

or even s/using/which is only capable of/ or 'which can only use'

Comment 18

[John G. Myers]

Attachment: Updated patch

Comment 19

[John G. Myers]

Attachment: Updated patch

Comment 20

[John G. Myers]

Attachment: Corrected updated patch

Comment 21

[David P. Drinan]

This patch is good. r=ddrinan.

Comment 22

[Dan Mosedale (:dmosedale, :dmose)]

r=[e-mail] for the netwerk changes.

Comment 23

[Darin Fisher]

sr=darin for the network changes

Comment 24

[John G. Myers]

Filed bug 74320 and bug 74322 on the issue of changing the themes.  Closing this 
as FIXED, as PSM2 now makes the necessary information available to the theme.

Comment 25

[John G. Myers]

Really closing FIXED.

Comment 26

[John Unruh]

Verified in the build where PSM 2.0 is properly installed.
http://ftp.mozilla.org/pub/mozilla/nightly/latest/mozilla-win32-talkback.zip

Comment 27

[Blake Ross]

"WeakSiteMessage=You have requested a document from a site using weak 
encryption.  The ***docmument*** and any information you send back could be 
observed by a third party while in transit."

/me smacks the reviewers

Comment 28

[John G. Myers]

Attachment: Patch to fix typo.

Comment 29

[Dan Mosedale (:dmosedale, :dmose)]

Heh.  Whoops, yeah, I should have caught this.

r=[e-mail]

Comment 30

[Darin Fisher]

sr=darin

Comment 31

[John G. Myers]

Checked in.

Comment 32

[John Unruh]

Reopening. John Myers wrote "If an SSL connection is using encryption weaker 
than 90 bits, the lock icon should be displayed in the insecure (open) state." 

You can test individual ciphers here:
http://junruh.mcom.com/ciphers.html
If the site can be reached, even if the cipher is less than 90 bits, the lock 
always shows locked.

Comment 33

[John G. Myers]

Bug 74320 now tracks the issue of changing the lock icons.  This bug has morphed 
to track the pop-up warning and the provision of weak/strong information to the 
chrome.

Comment 34

[John Unruh]

Verified per jgmyers' comments.

Comment 35

[John Unruh]

Mass changing Security:Crypto to PSM

Comment 36

[John Unruh]

Mass changing Security:Crypto to PSM