如何一步步构建安全的 HTTPS 站点

但是，即便满足了上述所有条件，也不一定能进入 HSTS Preload List，更多信息可以看这里(https://hstspreload.org/)。通过 Chrome 的 chrome://net-internals/#hsts 工具，可以查询某个网站是否在 Preload List 之中，还可以手动把某个域名加到本机 Preload List。

对于 HSTS 以及 HSTS Preload List，我的建议是只要你不能确保永远提供 HTTPS 服务，就不要启用。因为一旦 HSTS 生效，你再想把网站重定向为 HTTP，之前的老用户会被无限重定向，唯一的办法是换新域名。

如果确定要开启，点击https://hstspreload.org，输入你的域名，勾选协议，提交即可。

确认后，你就可以将你的域名提交给 HSTS 预加载列表了：

提交成功后会给你返回成功的信息，不过你要保证你的配置比如是一直开启了，否则也会从列表中删除。

再次访问，查看浏览器响应头：

此外，我们要做到让HTTPS 网站更安全更快速，还应当做到以下几点：

第一，密钥要足够的复杂，以rsa 密钥对为例，最好超过2048位;

第二，ssl_ciphers 的合理配置，尽量抛弃那些已经被证明不安全的加密算法，使用较新的被证明无安全威胁的算法，例如可以这样配置：

ssl_ciphers EECDH+CHACHA20:EECDH+CHACHA20-draft:EECDH+ECDSA+AES128:EECDH+aRSA+AES128:RSA+AES128:EECDH+ECDSA+AES256:EECDH+aRSA+AES256:RSA+AES256:EECDH+ECDSA+3DES:EECDH+aRSA+3DES:RSA+3DES:TLS-CHACHA20-POLY1305-SHA256:TLS-AES-256-GCM-SHA384:TLS-AES-128-GCM-SHA256:EECDH+CHACHA20:EECDH+AESGCM:EECDH+AES:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!KRB5:!aECDH:!EDH+3DES; 

第三，避免使用已经被证明不安全的加密协议，例如 SSLV2和SSLV3 ，而使用 TLSv1.2 TLSv1.3;

ssl_protocols TLSv1.2 TLSv1.3; 

一般来说较新的协议都是针对上一个版本进行了很多的优化，比如TLS1.2和TLS1.3协议，可以看下这2个协议的加密过程，首先，我们看下 TLS1.2的加密过程：

以 ECDHE 密钥交换算法为例，TLS1.2协议完整的SSL握手过程如下：

• 第一步，首先客户端发送ClientHello消息，该消息中主要包括客户端支持的协议版本、加密套件列表及握手过程需要用到的ECC扩展信息;
• 第二步，服务端回复ServerHello，包含选定的加密套件和ECC扩展;发送证书给客户端;选用客户端提供的参数生成ECDH临时公钥，同时回复ServerKeyExchange消息;
• 第三步，客户端接收ServerKeyExchange后，使用证书公钥进行签名验证，获取服务器端的ECDH临时公钥，生成会话所需要的共享密钥;生成ECDH临时公钥和ClientKeyExchange消息发送给服务端;
• 第四步，服务器处理ClientKeyExchange消息，获取客户端ECDH临时公钥;服务器生成会话所需要的共享密钥;发送密钥协商完成消息给客户端;
• 第五步，双方使用生成的共享密钥对消息加密传输，保证消息安全。

可以看到，TLS1.2 协议中需要加密套件协商、密钥信息交换、ChangeCipherSpec 协议通告等过程，需要消耗 2-RTT 的握手时间，这也是造成 HTTPS 协议慢的一个重要原因之一。

通过抓包分析，我们可以看到他的整个加密过程：

接下来，我们看下 TLS 1.3 的的交互过程，如图所示：

抓包得后如图所示，可以看到客户端的整个加密过程：

在 TLS 1.3 中，，客户端首先不仅发送 ClientHello 支持的密码列表，而且还猜测服务器将选择哪种密钥协商算法，并发送密钥共享,这可以节省很大一部分的开销，从而提高了速度。

TLS1.3 提供 1-RTT 的握手机制，还是以 ECDHE 密钥交换过程为例，握手过程如下。将客户端发送 ECDH 临时公钥的过程提前到 ClientHello ，同时删除了 ChangeCipherSpec 协议简化握手过程，使第一次握手时只需要1-RTT，来看具体的流程：

• 客户端发送 ClientHello 消息，该消息主要包括客户端支持的协议版本、DH密钥交换参数列表KeyShare;
• 服务端回复 ServerHello，包含选定的加密套件;发送证书给客户端;使用证书对应的私钥对握手消息签名，将结果发送给客户端;选用客户端提供的参数生成 ECDH 临时公钥，结合选定的 DH 参数计算出用于加密 HTTP 消息的共享密钥;服务端生成的临时公钥通过 KeyShare 消息发送给客户端;
• 客户端接收到 KeyShare 消息后，使用证书公钥进行签名验证，获取服务器端的 ECDH 临时公钥，生成会话所需要的共享密钥;
• 双方使用生成的共享密钥对消息加密传输，保证消息安全。

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!