4 ms·
Here's two relevant Bugzilla bugs: Self-signed certificates are treated as errors: https://bugzilla.mozilla.org/show_bug.cgi?id=431386 https://bugzilla.mozilla
by diafygi 11y ago
Here's two relevant Bugzilla bugs:
Self-signed certificates are treated as errors: https://bugzilla.mozilla.org/show_bug.cgi?id=431386 https://bugzilla.mozilla.org/show_bug.cgi?id=431386
Switch generic icon to negative feedback for non-https sites: https://bugzilla.mozilla.org/show_bug.cgi?id=1041087 https://bugzilla.mozilla.org/show_bug.cgi?id=1041087
Here's a proposed way of phasing this plan in over time:
1. Mid-2015: Start treating self signed certificates as unencrypted connections (i.e. stop showing a warning, but the UI would just show the globe icon, not the lock icon). This would allow website owners to choose to block passive surveillance without causing any cost to them or any problems for their users.
2. Late-2015: Switch the globe icon for http sites to a gray unlocked lock. The self signed certs would still be the globe icon. The would incentivize website owners to at least start blocking passive surveillance if they want to keep the same user experience as previous. Also, this new icon wouldn't be loud or intrusive to the user.
3. Late-2016: Change the unlocked icon for http sites to a yellow icon. Hopefully, by the end of 2016, Let's Encrypt has taken off and has a lot of frameworks like wordpress including tutorials on how to use it. This increased uptake of free authenticated https, plus the ability to still use self-signed certs for unauthenticated https (remember, this still blocks passive adversaries), would allow website owners enough alternative options to start switching to https. The yellow icon would push most over the edge.
4. Late-2017: Switch the unlocked icon for http to red. After a year of yellow, most websites should already have switched to https (authenticated or self-signed), so now it's time to drive the nail in the coffin and kill http on any production site with a red icon.
5. Late-2018: Show a warning for http sites. This experience would be similar to the self-signed cert experience now, where users have to manually choose to continue. Developers building websites would still be able to choose to continue to load their dev sites, but no production website would in their right mind choose to use http only.
- MichaelGG 11y agoUsers should still get a warning if they requested an HTTPS URL. If they requested HTTP and there was opportunistic encryption, fine. But under no circumstances should HTTPS URLs, which indicate secure intent, silently downgrade to insecure (self-signed or otherwise).
- zmmmmm 11y agoWhy the hate for self-signed certificates? I would personally rather see those promoted and methods developed to securely bootstrap them than make us all reliant on centralised CA infrastructure. The centralised CAs are all at the mercy of their governments and hence, in my opinion, ought to be considered almost as insecure as self-signed certs. EDIT: I think I misunderstood your comment - reading again it sounds like you are also in favour of self-signed (hopefully so).
- talideon 11y agoUntil supports for DANE and DNSSEC becomes widespread, unless it's a site for personal use, self-signed certs can't really be trusted by third parties. (BTW, if you're not using a conventional CA, you'd best off being your own CA, and signing your certs with a CA certificate you've generated rather than simply self-signing the cert. It's a little more trouble in the short term, but it means that each time you subsequently need to generate a new cert, you don't need to put up with warnings everywhere because it'll be validated by your own CA cert. The downside of this is having to install the CA cert everywhere. That's what I do for my private stuff. There are tonnes of tutorials online on how to do it.)