浏览器在获取该响应头后,在 max-age 的时间内,如果遇到 HTTP 连接,就会通过 307 跳转強制使用 HTTPS 进行连接,并忽略其它的跳转设置(如 301 重定向跳转):
307 跳转 Non-Authoritative-Reason 响应头
Google HSTS 预加载列表(HSTS Preload List)
由于 HSTS 需要用戶经过一次安全的 HTTPS 连接后才会在 max-age 的时间內生效,因此HSTS 策略并不能完美防止 HTTP 会话劫持(HTTP session hijacking),在下面这些情況下还是存在被劫持的可能:
- 从未访问过的网站
- 近期重裝过操作系統
- 近期重裝过浏览器
- 使用新的浏览器
- 使用了新的设备(如手机)
- 刪除了浏览器缓存
- 近期沒有打开过网站且 max-age 过期
针对这种情況,Google 维护了一份『HSTS 预加载列表』,列表里包含了使用了 HSTS 的站点主域名和子域名,可以通过以下页面申请加入:
https://hstspreload.appspot.com/.
申请的时候会先验证站点是否符合资格,一般会检验待验证的站点主域和子域是否能通过 HTTPS 连接、HTTPS 和 HTTP 配置是否有 STS Header 等信息,通过验证后,会让你确认一些限制信息,如下图:
当确认提交后,就会显示处理状态:
申请通过后,列表内的站点名会被写进主流的浏览器,当浏览器更新版本后,只要打开列表内的站点,浏览器会拒绝所有 HTTP 连接而自动使用 HTTPS,即使关闭了 HSTS 设置。
可以在下面两个连接分別查找 Chrome 和 Firfox 的『HSTS 预加载列表』内容:
The Chromium Projects - HTTP Strict Transport Security
Firefox HSTS preload list - nsSTSPreloadList.inc
需要注意的是:
- 一旦把自己的站点名加入『HSTS 预加载列表』,将很难彻底从列表中移除,因为不能保证其它浏览器可以及时移除,即使 Chrome 提供有便捷的移除方法,也是要通过出邮件联系,注明移除原因,并等到最新的浏览器版本更新发布才有机会(用戶不一定会及时更新)
- 所有不具备有效证书的子域或內嵌子域的访问将会被阻止
因此,如果自己站点子域名变化比较多,又沒有泛域证书,又沒法确定全站是否能应用 HTTPS 的朋友,就要谨慎申请了。
更多关于 HSTS 配置可参考:
《HTTP Strict Transport Security (HSTS) and NGINX》
MDN的《HTTP Strict Transport Security》
浏览器兼容性
加强 HTTPS 安全性
HTTPS 基础配置采取的默认加密算法是 SHA-1,这个算法非常脆弱,安全性在逐年降低,在 2014 年的时候, Google 官方博客就宣布在 Chrome 浏览器中逐渐降低 SHA-1 证书的安全指示,会从 2015 年起使用 SHA-2 签名的证书,可参阅 Rabbit_Run 在 2014 年发表的文章:《为什么Google急着杀死加密算法SHA-1》
为此,主流的 HTTPS 配置方案应该避免 SHA-1,可以使用 迪菲-赫尔曼密钥交换(D-H,Diffie–Hellman key exchange)方案。
首先在目录 /etc/ssl/certs 运行以下代码生成 dhparam.pem 文件:
发表评论