GNOME Bugzilla – Bug 542454
Trusted security certificates should be marked differently
Last modified: 2014-07-07 00:51:45 UTC
In the modern browsers "signed certificates are trusted but some are more trusted then others". For example in Fx 3.0 the verified certificates are mark on green on the left. IMHO this security feature should be implemented. However I would suggested all of the address bar green instead of only part of it (as it more similar to current marking).
This bug should really be marked as a security risk because there is no visual difference between trusted and untrusted certificates.
There is visual difference now - the padlock is marked as broken if the certificate is not trusted.
I'm a stickler for this , but I would suggest a popup/dialog/warning in the event of a certificate that shouldn't be trusted, detailing: - What's wrong with the certificate (Was it expired? Is it not signed by someone you trust? Was it just self-signed?) - The risks involved in trusting it anyways - The option to override it (trusting it permanently or temporarilly)
*** Bug 542461 has been marked as a duplicate of this bug. ***
I'd prefer (as a user) an error page rather than a pop-up. If Epiphany did what Firefox does then I'd be quite happy.
If you're going to allow pages with unverified certificates to load, it's critical to prevent them from XSS-ing pages from the same domain with a verified certificate. I'm using Fedora's epiphany-2.28.2-1.fc12.x86_64, and it doesn't seem to verify certificates at all. I'm guessing it is just declining to override the default behavior of libsoup; see bug 600447.
When a bad/untrusted certificate is used, encryption is worse than useless, since it produces a false sense of security, while the medium is still subject to a trivial man-in-the-middle attack. Right now, the only warning is a "broken" icon in the bottom-left corner, far from where the user's visual focus, and a subtly different color URL bar. Chrome/firefox take the approach of a dialog page to educate the user about what's wrong, and continue if they opt to do so. (Ideally they also tie into the certificate manager to permanently trust a certificate, however, that's a much less important feature than protecting the user's confidential information). Right now, I can interact with my online banking site, send my account number and password, and easilly not realise that my connection has been subverted. priority => "immediate", per bug life cycle documentation, "is a security issue in a released version of the software." severity = > "critical", since it doesn't actually block development work.
Downstream at https://bugs.launchpad.net/epiphany-browser/+bug/589877 Related to, but not equivelent to, https://bugzilla.gnome.org/show_bug.cgi?id=594856
*** Bug 620852 has been marked as a duplicate of this bug. ***
See bug 639764 for a related problem: certificate validity for connections other than the one used to retrieve the main HTML page is not indicated at all.
Interesting article in this context: http://www.freedom-to-tinker.com/blog/sjs/web-browser-security-user-interfaces-hard-get-right-and-increasingly-inconsistent
(In reply to comment #11) > Interesting article in this context: > http://www.freedom-to-tinker.com/blog/sjs/web-browser-security-user-interfaces-hard-get-right-and-increasingly-inconsistent The current problem is way more basic than the UI design considerations in that article. See https://bugzilla.mozilla.org/show_bug.cgi?id=327181#c14 for why Mozilla rejected Epiphany's current approach.
Though from the first post this looks like Bug #721179, the rest of the discussion in this bug is about Epiphany's poor UI for indicating certificate authentication errors, which we're working on in bug #708847. *** This bug has been marked as a duplicate of bug 708847 ***