Nginx 配置 HTTPS 服务器的方法

浏览器在获取该响应头后，在 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 文件：