5 ms·
There's one solution that the author didn't cover: Start treating self-signed certs as unencrypted. Then, deprecate http support over a multi-year phase out. Th
by diafygi 11y ago
There's one solution that the author didn't cover: Start treating self-signed certs as unencrypted. Then, deprecate http support over a multi-year phase out. That way, website owners who want to keep their status quo, can just add a self signed cert and their users will be none the wiser.
For https there are two major objectives. 1) Prevent MITM attacks. 2) Prevent snooping from passive monitoring. Self-signed certs can prevent #2, which the IETF has adopted as a Best Current Practice (https://tools.ietf.org/html/rfc7258 https://tools.ietf.org/html/rfc7258). I'm much more in favor of trying to at least do one of the two objectives of https, rather than refusing to do anything until we are able to do both objectives.
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.
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
- ajanuary 11y agoWon't treating self-signed certificates as not-errors make 1 (prevent MITM attacks) worse though? You could then MITM an https site, serve up a self-signed cert, and anyone but the most observant users won't notice that something that used to be secure https now isn't. It isn't about refusing to do anything but both at once, it's that doing only one of them makes the other worse.
- api 11y agoNo, the idea would be that http becomes https with a self-signed cert. It shows as 'not protected' the way http does now to the user. It only turns green or gets the key box when it's a signed cert.
- ajanuary 11y agoVery few people are going to notice that something that used to be green now isn't. In an attempt to increase security against passive monitoring (a laudable aim) this scheme heavily neuters https' ability to increase security against MITM attacks.
- oconnore 11y agoYou are describing a downgrade attack, which is addressed by HSTS, not TLS.
- ajanuary 11y agoHSTS is designed to protect against downgrading from HTTPS to HTTP. Best I can tell, it doesn't protect against downgrading from an HTTPS with a validated certificate chain to HTTPS without a validated certificate chain. To do that, you would need something like certificate pinning. Once there is a widely deployed mechanism for detecting when a certificate has erroneously changed it would be more feasible to stop treating self-signed certificates as errors.
- 11y ago