Mozilla的官方博客2015.4.30正式宣布了淘汰HTTP的方案。
其中包括：设定一个日期，所有的新特性将只提供给HTTPS网站；HTTP网站将逐步被禁止访问浏览器功能，尤其是那些与用户安全和隐私相关的功能。 Mozilla此举是向Web开发者社区发出一条信息，他们需要确保网站的安全性，而只有整个Web社区和浏览器开发商联合起来，淘汰HTTP才能真正实 现。
Mozilla计划不久之后向W3C WebAppSec工作组递交相关提议。
对于这项策略，也有不同的观点，总结无外乎以下几点：
1、SSL证书需要花钱
2、公开非敏感内容不需要加密
3、加密会导致网站速度变慢，性能下降
4、SSL本身也不是无懈可击（比如CA可以颁发假证书）
以上几点其实都不对
1、SSL证书目前正趋于廉价话，对于个人或者初创团队，还可以申请免费证书。而收费证书目前SSL数字证书网页可以提供低至百元左右的可信域名型DVSSL证书；
2、GitHub被中间人攻击就证明不加密的网络的潜在危害是很大的。
3、硬件水平的增长和算法优化（比如Chacha20_Poly1305），加密开销越来越在可接受范围内。
4、SSL相关的漏洞目前都有解决方案，比如为了对抗假证书风险，我们有Public key pinning。而且发假证书给CA带来的风险太大
以下是Mozilla博客原文:
Today we are announcing our intent to phase out non-secure HTTP.
There’s pretty broad agreement that HTTPS is the way forward for the web. In recent months, there have been statements from IETF, IAB (even the other IAB), W3C, and the US Government calling for universal use of encryption by Internet applications, which in the case of the web means HTTPS.
After a robust discussion on our community mailing list, Mozilla is committing to focus new development efforts on the secure web, and start removing capabilities from the non-secure web. There are two broad elements of this plan:
- Setting a date after which all new features will be available only to secure websites
- Gradually phasing out access to browser features for non-secure websites, especially features that pose risks to users’ security and privacy.
For the first of these steps, the community will need to agree on a date, and a definition for what features are considered “new”. For example, one definition of “new” could be “features that cannot be polyfilled”. That would allow things like CSS and other rendering features to still be used by insecure websites, since the page can draw effects on its own (e.g., using
The second element of the plan will need to be driven by trade-offs between security and web compatibility. Removing features from the non-secure web will likely cause some sites to break. So we will have to monitor the degree of breakage and balance it with the security benefit. We’re also already considering softer limitations that can be placed on features when used by non-secure sites. For example, Firefox already prevents persistent permissions for camera and microphone access when invoked from a non-secure website. There have also been some proposals to limit the scope of non-secure cookies.
It should be noted that this plan still allows for usage of the “http” URI scheme in legacy content. With HSTS and the upgrade-insecure-requests CSP attribute, the “http” scheme can be automatically translated to “https” by the browser, and thus run securely.
Since the goal of this effort is to send a message to the web developer community that they need to be secure, our work here will be most effective if coordinated across the web community. We expect to be making some proposals to the W3C WebAppSec Working Group soon.
Thanks to the many people who participated in the mailing list discussion of this proposal. Let’s get the web secured!
Richard Barnes, Firefox Security Lead
