Closed Bug 31896 Opened 24 years ago Closed 23 years ago

lock icon distinguish between weak and strong encryption

Categories

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

1.0 Branch
enhancement

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: jgmyers, Assigned: jgmyers)

References

Details

Attachments

(5 files)

If an SSL connection is using encryption weaker than 90 bits, the lock icon 
should be displayed in the insecure (open) state.
OS: Mac System 8.5 → All
Hardware: Macintosh → All
Version: 1.01 → 1.1
Depends on: 31982
Component: Client Library → Security: Crypto
Product: PSM → Browser
Version: 1.1 → other
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.
would be nice.  Assinging to myself.  Setting milestone.
Assignee: lord → dougt
Target Milestone: --- → M18
Changing QA to me.
QA Contact: lord → junruh
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....
Assignee: dougt → valeski
Blocks: 31344
re-assigning
Assignee: valeski → javi
I'll take this.
Assignee: javi → jgmyers
Status: NEW → ASSIGNED
Blocks: 48444
cc'ing people
Setting milestone to future.
Target Milestone: M18 → Future
Added angelabu to cc: list
nsbeta1
Severity: normal → enhancement
Keywords: nsbeta1
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?
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.
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.
Summary: lock icon should be in insecure state if encryption weak → lock icon distinguish between weak and strong encryption
Target Milestone: Future → mozilla0.9
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."
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".
or even s/using/which is only capable of/ or 'which can only use'
Attached patch Updated patchSplinter Review
Attached patch Updated patchSplinter Review
This patch is good. r=ddrinan.
r=dmose@netscape.com for the netwerk changes.
sr=darin for the network changes
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.
Really closing FIXED.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Verified in the build where PSM 2.0 is properly installed.
http://ftp.mozilla.org/pub/mozilla/nightly/latest/mozilla-win32-talkback.zip
Status: RESOLVED → VERIFIED
"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
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Heh.  Whoops, yeah, I should have caught this.

r=dmose@netscape.com
sr=darin
Whiteboard: request 0.9 consideration
Checked in.
Status: REOPENED → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → FIXED
Whiteboard: request 0.9 consideration
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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.
Status: REOPENED → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → FIXED
Verified per jgmyers' comments.
Status: RESOLVED → VERIFIED
Mass changing Security:Crypto to PSM
Component: Security: Crypto → Client Library
Product: Browser → PSM
Target Milestone: mozilla0.9 → ---
Version: other → 2.1
Mass changing Security:Crypto to PSM
Product: PSM → Core
Version: psm2.1 → 1.0 Branch
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: