作为 HTTPS 的骨灰粉,怎么可以不加入 HSTS 预载入列表
2015-12-18 09:00
736 查看
自从关注了 HTTPS,Linux 中国就成了 HTTPS 的铁杆粉丝了,不但传播了很多 HTTPS 相关的文章,而且身体力行的将 http://linux.cn 也切换到了 https://linux.cn 。非但如此,还激进地配置了 HSTS 策略。
这就给了中间人攻击的一个机会,重定向可能会被破坏,从而定向到一个恶意站点而不是应该访问的加密页面。
HTTP 严格传输安全(HSTS)功能使 Web 服务器告知浏览器绝不使用 HTTP 访问,在浏览器端自动将所有到该站点的 HTTP 访问替换为 HTTPS 访问。
服务器开启 HSTS 的方法是,当客户端通过 HTTPS 发出请求时,在服务器返回的 HTTP 响应头中包含
所以,我们早早就配置上了 HSTS 响应头了。
当前浏览器对 HSTS 的支持如下,可见现代浏览器已经绝大部分支持了:
![](https://oscdn.geek-share.com/Uploads/Images/Content/201512/f59c90487b2f2255f07f8775657419cf.jpg)
所以,追求完美人们,又提出了一个 HSTS 预载入列表(preload list)(友情提示,请自备梯子)。
谷歌在浏览器安全方面总是走在前面,因此它维护了一个预载入列表给 Chrome 使用,这个列表会硬编码到 Chrome 浏览器中。后来,Firefox、Safari、 IE 11 和 Edge 一想,得了,咱也别自己弄一个了,都采用这个列表吧。所以,各大浏览器都支持同一个列表了。
如果要想把自己的域名加进这个列表,需要满足以下条件:
有效的证书(如果使用 SHA-1 证书,必须是 2016 年前就会过期的);
将所有 HTTP 流量重定向到 HTTPS;
确保所有子域名都启用了 HTTPS,特别是 www 子域;
输出 HSTS 响应头:
max-age 至少需要 18 周(10886400 秒),其实在 ssllabs 的测试里面建议更长一些;
必须指定 includeSubdomains 参数;
必须指定 preload 参数;
HSTS 响应头范例:
注意,提交的申请并不是自动处理的,人工处理也许需要一周到几周,你可以在这个表单提交查询看看是否列入了。或者在你的 Chrome 浏览器中访问 chrome://net-internals/#hsts 查询是否列入。一般来说,即便你已经列入到这个列表,但是依旧需要几个月才能逐渐从 Chrome 的 canary 更新通道更新到 dev 、beta 等通道,直到最后的 stable 通道。
郑重警示:如果你并不能确定你的网站从此以后一直使用 HTTPS,那还是不要加入的好。因为,加入后很难撤销,你可以要求撤销,但是这个数据重新更新到稳定版的 Chrome 同样需要几个月,而别的浏览器是如何处理这个撤销数据的,则无法保证。
换句话说,只有 HTTPS 骨灰粉才应该考虑加入。
上个月15号,我修改了符合申请条件的 HTST 响应头,然后提交了申请。
今天晚上突然心血来潮,想着看看是否批准下来了:
![](https://oscdn.geek-share.com/Uploads/Images/Content/201512/97af89d75503478c76dc8f3e65f251b4.jpg)
哈哈,通过了!
然后马上去 Chrome 里面查询——没有……好吧,我用的是稳定版的 Chrome。去下载 canary 通道的 Chrome 看看。安装后马上查询一下:
![](https://oscdn.geek-share.com/Uploads/Images/Content/201512/9b78fc6b3eda20f19a9e0916e9716f38.jpg)
果然列入了 canary 通道的 Chrome 里面!第一次在这个新开封的浏览器里面访问 linux.cn,马上就变成绿色的 https://linux.cn !
![](https://oscdn.geek-share.com/Uploads/Images/Content/201512/8931da55c2cabd363620bb9c05675d23.jpg)
去查询一下 Chrome 的代码看看:
![](https://oscdn.geek-share.com/Uploads/Images/Content/201512/1cf60816e658e65b3184634889915b00.jpg)
从现在的数据看,列表中总共才 4630 个域名,其中 .cn 的才 8 个。怎么样,你要不要也加入进来?
HSTS 是什么?
如果一个 web 服务器支持 HTTP 访问,并将其重定向到 HTTPS 访问的话,那么访问者在重定向前的初始会话是非加密的。举个例子,比如访问者输入 http://www.foo.com/ 或直接输入 foo.com 时。这就给了中间人攻击的一个机会,重定向可能会被破坏,从而定向到一个恶意站点而不是应该访问的加密页面。
HTTP 严格传输安全(HSTS)功能使 Web 服务器告知浏览器绝不使用 HTTP 访问,在浏览器端自动将所有到该站点的 HTTP 访问替换为 HTTPS 访问。
服务器开启 HSTS 的方法是,当客户端通过 HTTPS 发出请求时,在服务器返回的 HTTP 响应头中包含
Strict-Transport-Security字段。浏览器接收到这样的信息之后,在一定期限内对该网站的任何请求都会以 HTTPS 发起,而不会以 HTTP 发起并由服务器重定向到 HTTPS。
所以,我们早早就配置上了 HSTS 响应头了。
当前浏览器对 HSTS 的支持如下,可见现代浏览器已经绝大部分支持了:
![](https://oscdn.geek-share.com/Uploads/Images/Content/201512/f59c90487b2f2255f07f8775657419cf.jpg)
HSTS 预载入列表
但是,这就够了么?如果一个用户从来没有以 HTTPS 方式访问过我们的网站呢,那显然就没有机会得到 HSTS 响应头,从而还是有可能以 HTTP 的方式进行首次访问——虽然我们已经做了很多自动和强制的引导,但是总还稍有缺憾?所以,追求完美人们,又提出了一个 HSTS 预载入列表(preload list)(友情提示,请自备梯子)。
谷歌在浏览器安全方面总是走在前面,因此它维护了一个预载入列表给 Chrome 使用,这个列表会硬编码到 Chrome 浏览器中。后来,Firefox、Safari、 IE 11 和 Edge 一想,得了,咱也别自己弄一个了,都采用这个列表吧。所以,各大浏览器都支持同一个列表了。
如果要想把自己的域名加进这个列表,需要满足以下条件:
有效的证书(如果使用 SHA-1 证书,必须是 2016 年前就会过期的);
将所有 HTTP 流量重定向到 HTTPS;
确保所有子域名都启用了 HTTPS,特别是 www 子域;
输出 HSTS 响应头:
max-age 至少需要 18 周(10886400 秒),其实在 ssllabs 的测试里面建议更长一些;
必须指定 includeSubdomains 参数;
必须指定 preload 参数;
HSTS 响应头范例:
Strict-Transport-Security: max-age=10886400; includeSubDomains; preload
注意,提交的申请并不是自动处理的,人工处理也许需要一周到几周,你可以在这个表单提交查询看看是否列入了。或者在你的 Chrome 浏览器中访问 chrome://net-internals/#hsts 查询是否列入。一般来说,即便你已经列入到这个列表,但是依旧需要几个月才能逐渐从 Chrome 的 canary 更新通道更新到 dev 、beta 等通道,直到最后的 stable 通道。
郑重警示:如果你并不能确定你的网站从此以后一直使用 HTTPS,那还是不要加入的好。因为,加入后很难撤销,你可以要求撤销,但是这个数据重新更新到稳定版的 Chrome 同样需要几个月,而别的浏览器是如何处理这个撤销数据的,则无法保证。
换句话说,只有 HTTPS 骨灰粉才应该考虑加入。
我们就是 HTTPS 骨灰粉!
任性的站长当然是 HTTPS 骨灰粉了,虽然“一入宫门深似海”,将来 HTTPS 会不会和 L2TP、PPTP 一样被限制也未可知,但是这么有 BIG 的事情怎么可以不做呢?上个月15号,我修改了符合申请条件的 HTST 响应头,然后提交了申请。
今天晚上突然心血来潮,想着看看是否批准下来了:
![](https://oscdn.geek-share.com/Uploads/Images/Content/201512/97af89d75503478c76dc8f3e65f251b4.jpg)
哈哈,通过了!
然后马上去 Chrome 里面查询——没有……好吧,我用的是稳定版的 Chrome。去下载 canary 通道的 Chrome 看看。安装后马上查询一下:
![](https://oscdn.geek-share.com/Uploads/Images/Content/201512/9b78fc6b3eda20f19a9e0916e9716f38.jpg)
果然列入了 canary 通道的 Chrome 里面!第一次在这个新开封的浏览器里面访问 linux.cn,马上就变成绿色的 https://linux.cn !
![](https://oscdn.geek-share.com/Uploads/Images/Content/201512/8931da55c2cabd363620bb9c05675d23.jpg)
去查询一下 Chrome 的代码看看:
![](https://oscdn.geek-share.com/Uploads/Images/Content/201512/1cf60816e658e65b3184634889915b00.jpg)
从现在的数据看,列表中总共才 4630 个域名,其中 .cn 的才 8 个。怎么样,你要不要也加入进来?
相关文章推荐
- 13-《电子入门趣谈》第二章_电子电路的神经网络-2.2集成运算放大器
- 千万级规模高性能、高并发的网络架构经验分享
- 一起奇怪的网络问题解决过程
- 猫哥网络编程系列:HTTP PEM 万能调试法
- 《TCP/IP具体解释》读书笔记(18章)-TCP连接的建立与中止
- 如何使用virtualbox+devstack搭建neutron网络模式的openstack
- 如何使用virtualbox+devstack搭建neutron网络模式的openstack
- URLConnection 和 HttpClients 发送请求范例
- Android笔记(六十二)网络框架volley
- 千万级规模高性能、高并发的网络架构经验分享
- 基于fiddler插件开发的移动测试网络监控与分析
- ccf 网络延时(dfs)
- MJRefresh框架 代码地址: https://github.com/CoderMJLee/MJRefresh
- Wireshark 网络抓包工具介绍、应用及一个案例
- 网络层—链路状态路由算法
- 第三方开源项目加载网络图片
- Linux网络监控工具nethogs
- 网络基础知识-2
- 关于HTTP协议的学习
- webView 拦截网络请求