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)
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: jgmyers, Assigned: jgmyers)
References
Details
Attachments
(5 files)
10.00 KB,
patch
|
Details | Diff | Splinter Review | |
12.08 KB,
patch
|
Details | Diff | Splinter Review | |
10.44 KB,
patch
|
Details | Diff | Splinter Review | |
12.67 KB,
patch
|
Details | Diff | Splinter Review | |
1.77 KB,
patch
|
Details | Diff | Splinter Review |
If an SSL connection is using encryption weaker than 90 bits, the lock icon should be displayed in the insecure (open) state.
Assignee | ||
Updated•24 years ago
|
OS: Mac System 8.5 → All
Hardware: Macintosh → All
Assignee | ||
Updated•24 years ago
|
Version: 1.01 → 1.1
Assignee | ||
Updated•24 years ago
|
Component: Client Library → Security: Crypto
Product: PSM → Browser
Version: 1.1 → other
Comment 1•24 years ago
|
||
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•24 years ago
|
||
would be nice. Assinging to myself. Setting milestone.
Assignee: lord → dougt
Target Milestone: --- → M18
Comment 4•24 years ago
|
||
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
Assignee | ||
Updated•24 years ago
|
Status: NEW → ASSIGNED
Comment 7•24 years ago
|
||
cc'ing people
Comment 9•24 years ago
|
||
Added angelabu to cc: list
Assignee | ||
Comment 11•24 years ago
|
||
Comment 12•24 years ago
|
||
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?
Assignee | ||
Comment 13•24 years ago
|
||
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.
Assignee | ||
Comment 14•24 years ago
|
||
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
Assignee | ||
Updated•24 years ago
|
Target Milestone: Future → mozilla0.9
Comment 15•24 years ago
|
||
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."
Assignee | ||
Comment 16•24 years ago
|
||
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•24 years ago
|
||
or even s/using/which is only capable of/ or 'which can only use'
Assignee | ||
Comment 18•23 years ago
|
||
Assignee | ||
Comment 19•23 years ago
|
||
Assignee | ||
Comment 20•23 years ago
|
||
Comment 21•23 years ago
|
||
This patch is good. r=ddrinan.
Comment 22•23 years ago
|
||
r=dmose@netscape.com for the netwerk changes.
Comment 23•23 years ago
|
||
sr=darin for the network changes
Assignee | ||
Comment 24•23 years ago
|
||
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.
Assignee | ||
Comment 25•23 years ago
|
||
Really closing FIXED.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 26•23 years ago
|
||
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
Comment 27•23 years ago
|
||
"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 → ---
Assignee | ||
Comment 28•23 years ago
|
||
Comment 29•23 years ago
|
||
Heh. Whoops, yeah, I should have caught this. r=dmose@netscape.com
Comment 30•23 years ago
|
||
sr=darin
Assignee | ||
Updated•23 years ago
|
Whiteboard: request 0.9 consideration
Assignee | ||
Comment 31•23 years ago
|
||
Checked in.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Whiteboard: request 0.9 consideration
Comment 32•23 years ago
|
||
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 → ---
Assignee | ||
Comment 33•23 years ago
|
||
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 ago → 23 years ago
Resolution: --- → FIXED
Comment 35•23 years ago
|
||
Mass changing Security:Crypto to PSM
Component: Security: Crypto → Client Library
Product: Browser → PSM
Target Milestone: mozilla0.9 → ---
Version: other → 2.1
Comment 36•23 years ago
|
||
Mass changing Security:Crypto to PSM
Updated•8 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•