只要是在有效期内，浏览器都将直接强制性的发起HTTPS请求，但是问题又来了，有效期过了怎么办？其实不用为此过多担心，atv直播，因为HSTS Header存在于每个响应中，随着用户和网站的交互，这个有效时间时刻都在刷新，再加上有效期通常都被设置成了1年，所以只要用户的前后两次请求之间的时间间隔没有超过1年，则基本上不会出现安全风险。更何况，就算超过了有效期，只要用户和网站再进行一次新的交互，用户的浏览器又将开启有效期为1年的HSTS保护。

　　强制拒绝不安全的链接，不给用户选择的机会

　　在没有HSTS保护的情况下，当浏览器发现当前网站的证书出现错误，或者浏览器和服务器之间的通信不安全，无法建立HTTPS连接的时候，浏览器通常会警告用户，但是却又允许用户继续不安全的访问。如下图所示，用户可以点击图中红色方框中的链接，继续在不安全的连接下进行访问。

　　图5：浏览器依然允许用户进行不安全的访问

　　理论上而言，用户看到这个警告之后就应该提高警惕，意识到自己和网站之间的通信不安全，可能被劫持也可能被窃听，如果访问的恰好是银行、金融类网站的话后果更是不堪设想，理应终止后续操作。然而现实很残酷，就我的实际观察来看，有不少用户在遇到这样的警告之后依然选择了继续访问。

　　不过随着HSTS的出现，事情有了转机。对于启用了浏览器HSTS保护的网站，如果浏览器发现当前连接不安全，它将仅仅警告用户，而不再给用户提供是否继续访问的选择，从而避免后续安全问题的发生。例如，当访问Google搜索引擎的时候，如果当前通信连接存在安全问题，浏览器将会彻底阻止用户继续访问Google，如下图所示。

　　图6：浏览器彻底阻止用户继续进行不安全的访问

　　道高一尺魔高一丈：攻击者依然有可乘之机

　　细心的你可能发现了，HSTS存在一个比较薄弱的环节，那就是浏览器没有当前网站的HSTS信息的时候，或者第一次访问网站的时候，依然需要一次明文的HTTP请求和重定向才能切换到HTTPS，以及刷新HSTS信息。而就是这么一瞬间却给攻击者留下了可乘之机，使得他们可以把这一次的HTTP请求劫持下来，继续中间人攻击。

　　Preload List：让防御更加彻底

　　针对上面的攻击，HSTS也有应对办法，那就是在浏览器里内置一个列表，只要是在这个列表里的域名，无论何时、何种情况，浏览器都只使用HTTPS发起连接。这个列表由Google Chromium维护，FireFox、Safari、IE等主流浏览器均在使用。

　　一些Tips

　　Tip 1：如何配置HSTS

　　很多地方都可以进行HSTS的配置，例如反向代理服务器、应用服务器、应用程序框架，以及应用程序中自定义Header。你可以根据实际情况进行选择。

　　常见的是在代理服务器中进行配置，以Nginx为例，只需在配置文件中加上下面这条指令即可：

　　add_header Strict-Transport-Security "max-age=31536000; includeSubDomains"always;

　　不过需要特别注意的是，在生产环境下使用HSTS应当特别谨慎，因为一旦浏览器接收到HSTS Header（假如有效期是1年），但是网站的证书又恰好出了问题，那么用户将在接下来的1年时间内都无法访问到你的网站，直到证书错误被修复，或者用户主动清除浏览器缓存。

　　因此，建议在生产环境开启HSTS的时候，先将max-age的值设置小一些，例如5分钟，然后检查HSTS是否能正常工作，网站能否正常访问，之后再逐步将时间延长，例如1周、1个月，并在这个时间范围内继续检查HSTS是否正常工作，最后才改到1年。

　　Tip 2：如何加入到HSTS Preload List

　　根据官方说明，你的网站在具备以下几个条件后，可以提出申请加入到这个列表里。

具备一个有效的证书

在同一台主机上提供重定向响应，以及接收重定向过来的HTTPS请求

所有子域名均使用HTTPS

在根域名的HTTP响应头中，加入HSTS Header，并满足下列条件：

过期时间最短不得少于18周（10886400秒）

必须包含includeSubDomains参数

必须包含preload参数

　　当你准好这些之后，可以在HSTS Preload List的官网上（

　　Tip 3：如何查询域名是否加入到了Preload List

　　从提交申请到完成审核，成功加入到内置列表，中间可能需要等待几天到几周不等的时间。可通过官网

　　总结