On Thu, Mar 12, 2015 at 3:56 PM, Adam Roach <a...@mozilla.com> wrote: > As an aside, the first three are not just fixable, but actually fixed within > the next few months: https://letsencrypt.org/
That seems like a huge step forward. But putting my ex-sysadmin hat on -- assuming it works as advertised, there are still significant remaining practical issues for at least some sites: 1) SNI is reportedly still not usable if you care about IE on XP. This means HTTPS is not usable on shared hosting, which is most small sites, unless you don't care that your site doesn't load in IE on XP. This is also a problem for larger sites whose content is accessible via multiple domains (even just www.foo.com vs. foo.com), unless they want to get an IP address per domain. For instance, Wikipedia serves a whole bunch of second-level domains (wikipedia.org, wikimedia.org, wiktionary.org, etc.) from the same servers, and to support HTTPS, they needed to reconfigure their site so that all of these were different IP addresses. 2) If you want to support access via both HTTP and HTTPS for whatever reason, you have to make sure your content uses protocol-relative URLs exclusively, which means making modifying the software that runs on your site. Otherwise users will click a link and get sent back to the insecure site without noticing. This could include user-provided URLs. You could just use HTTPS exclusively, but that's a somewhat bigger step to take. 3) If you include third-party scripts that are not available over HTTPS, at least Chrome will helpfully break your site until your users click through a permissions dialog, if I remember correctly. 4) According to the O'Reilly book linked from istlsfastyet.com, best-case TLS usage still adds a round-trip to every connection. Common non-best-case scenarios are worse (e.g., IE < 10 apparently doesn't support False Start). This is a nontrivial performance penalty. There are probably other practical issues that will crop up on specific sites. It's still a change that requires nonzero effort to test and deploy, and has downsides, so using HTTPS is not necessarily a no-brainer for everyone. For instance, Wikimedia took a long time to deploy HTTPS, even though setting up certificates was not an issue, because of the various side issues that had to be handled (at least 1 and 2). So "use HTTPS" isn't an easy solution for everyone. But yes, this project should remove one of the big issues for a lot of people. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
