Going to this URL, you have to go through three seperate dialogs to access it. The first states the certificate is expired. The second, that the certificate was not issued by a trusted CA. The third alerts you to the fact that the name on the cert doesn't match the site MSIE shows all three of these in one dialog, with a green check next to what's OK, and a red X (or yellow warning <!> sign, in IE6) in front of any of the three that aren't OK. This is ALOT cleaner, you are presented all the information, then can make one decision on how to proceed, rather then presenting small parts of the information, and making three seperate desicions.

Moving to PSM product and marking Enhancement. "a lot" is two words.

I pestered Håkan to do this when he was fixing bug 91466, but apparently that bug was difficult enough as it is.

Also worth noting that after saying OK to the three dialogs, the 'entering a secure site' dialog says: "... The website has identified itself correctly and all ..." Which is kind of misleading. It couldn't id itself correctly, so we bypassed that part. That's fairly trivial though, the three dialogs is the main problem.

*** Bug 194269 has been marked as a duplicate of this bug. ***

Mass reassign ssaux bugs to nobody

Mass change "Future" target milestone to "--" on bugs that now are assigned to nobody. Those targets reflected the prioritization of past PSM management. Many of these should be marked invalid or wontfix, I think.

Bah I just wrote a long comment and then the browser crashed ... *sob*! I'll try writing it again. First prototype of the proposed Bad Certificate dialog. As you can see here the "View Certificate" button is missing and the Cancel button doesn't have a label .. I think this is because we're not chrome. I'm not sure. If you want to see how it should look, take a look at <https://bugzilla.mozilla.org/attachment.cgi?id=198577>. This is how I think it should be: * Lists the various issues found with the certificate with bullet points and short, to-the-point, explanations. * Clicking Cancel aborts the request and does not store anything about the certificate. If you visit the URL again you will get the same box. * Checking the checkbox has no effect if you click Cancel. * Checking the checkbox and clicking Continue should store the certificate forever (permanent storage). * NOT checking the checkbox and clicking Continue should store the certificate for the rest of the session. * Clicking "View Certificate" brings up the dialog as it exists today.

(In reply to comment #7) > First prototype of the proposed Bad Certificate dialog. As you can see here the > "View Certificate" button is missing and the Cancel button doesn't have a label > .. I think this is because we're not chrome. I see that in Seamonkey the "Continue" button doesn't have a label either. It works when called from chrome :-) In any case the review request is for the dialog. If you + it, I'll try to implement.

Baah! I knew I forgot something: The wording would of course have to be enhanced greatly (and reviewed by the right people), but you should get the general idea from the prototype.

Good work, Vidar. Thanks! Suggestions: 1. Use the standard Windows+Mac+Epiphany quote style: double curly quotes. 2. 'The “mozilla.org” security certificate is faulty.' Fewer words is better (though the adjective might need tweaking). 3. Who's "we"? Try "issued by an unknown certificate authority". 4. Changing "Continue" to "Continue Anyway" would make the entire "Are you sure you want to continue?" line unnecessary. 5. Repeating "The certificate" is awkward. Fortunately, (4) above means the bullet points are now immediately underneath "The ... certificate is faulty", so "The certificate" in the list items can be changed to "It". 6. Is the checkbox necessary? It's awkward because once you've trusted a site, it's not obvious how you un-trust it again. 7. What's the overall risk here? The only browser I've seen trying an actual explanation is Safari, which says: 'You might be connecting to a website that is pretending to be “mozilla.org” which could put your confidential information at risk.' Is that true? If so, perhaps Mozilla could follow the list with a shorter equivalent: 'This might not be the real “mozilla.org” site.'

(In reply to comment #10) Thanks for taking a look. > 2. 'The “mozilla.org” security certificate is faulty.' Fewer words is > better (though the adjective might need tweaking). Agreed, I'm not keen on "faulty". Hm. I like your other suggestions though. I don't understand what you mean by #7. I think you're talking specifically about domainMismatch? I think I'll also implement the expired message a bit different. For example, if the certificate expired withing the last 12 months: "It expired about X months ago.", and if it expired more than 12 months ago: "It expired more than X years ago." and so on. The user can get the actual date (which he really does not care about) by clicking 'View Certificate'. Hm.. Could we go even further and just say "It has expired." ? I really can't envision anyone ever caring about the date or relative point in time.

2. Perhaps "not reliable". That more accurately covers the case where you're using Firefox 1.5 at a site whose cert's CA was introduced to the default CA list in Firefox 2.1. 7. I meant it to apply to all problems, not just domain mismatch. But you'd need to corner an SSL expert and (a) come up with a set of real-world scenarios that these alerts protect you against, (b) find out whether/ why it's useful to distinguish the various problems, and (c) find out whether/why it's good to know how long ago a certificate expired.

beltzner: Do you have any comments to the proposed UI (attachment 198851 [details])? Of course, the UI can be polished after the core changes are made (there is lots of work to do there), so I'm thinking more along the conceptual lines, because it might influence design choices to be made in the code.

Will this code also affect firefox? (Sorry, might be a stupid question - but so much UI code seems to be forked from seamonkey.)

(In reply to comment #14) > Will this code also affect firefox? (Sorry, might be a stupid question - but so > much UI code seems to be forked from seamonkey.) Yes.

Comment on attachment 198851 [details] bad certificate dialog prototype adding review to my queue

Please note that I started to work on an approach that combines the dialog and will allow the option to remember a override for a certain hostname+cert pair.

What's there to review here? There's no patch ready for checkin. See also bug 327181 and its attachments. That proposal is similar to this one, is also very like IE's error page, and IMO is more effective against phishing, because it stops the user from immediately overriding the ONLY error that he will ever see to warn him he's being phished.

Another issue: Bad cert dialogs should NEVER say "This cert belongs to", because that is the fundamental problem. The cert CLAIMS to belong to the named party but very well may belong instead to an attacker. In stating that "this cert belongs to" the named party, we are acting as the CA, we are asserting that the certificate's contents are true, even though the very cause of this warning is precisely that we do NOT know that it is true.

Comment on attachment 198851 [details] bad certificate dialog prototype Beltzner's self-request for ui-review is now 16 months old. Johnathan, would you review it? Also, please consider the alternative proposal in bug 327181

Comment on attachment 198851 [details] bad certificate dialog prototype This is not the plan of record. I think the requestees should just r- it instead of letting it rot. I'm cancelling my request.

This was addressed with bug 327181, marking as duplicate.