HSTS详解

1. 缘起：启用HTTPS也不够安全

有很多网站只经过HTTPS对外提供服务，但用户在访问某个网站的时候，在浏览器里却每每直接输入网站域名（例如www.example.com），而不是输入完整的URL（例如https://www.example.com），不过浏览器依然能正确的使用HTTPS发起请求。这背后多亏了服务器和浏览器的协做，以下图所示。

 

图1：服务器和浏览器在背后帮用户作了不少工做

简单来说就是，浏览器向网站发起一次HTTP请求，在获得一个重定向响应后，发起一次HTTPS请求并获得最终的响应内容。全部的这一切对用户而言是彻底透明的，因此在用户眼里看来，在浏览器里直接输入域名却依然能够用HTTPS协议和网站进行安全的通讯，是个不错的用户体验。

一切看上去都是那么的完美，但其实否则，因为在创建起HTTPS链接以前存在一次明文的HTTP请求和重定向（上图中的第一、2步），使得攻击者能够以中间人的方式劫持此次请求，从而进行后续的攻击，例如窃听数据，篡改请求和响应，跳转到钓鱼网站等。

以劫持请求并跳转到钓鱼网站为例，其大体作法以下图所示：

 

图2：劫持HTTP请求，阻止HTTPS链接，并进行钓鱼攻击

• 第1步：浏览器发起一次明文HTTP请求，但实际上会被攻击者拦截下来
• 第2步：攻击者做为代理，把当前请求转发给钓鱼网站
• 第3步：钓鱼网站返回假冒的网页内容
• 第4步：攻击者把假冒的网页内容返回给浏览器

这个攻击的精妙之处在于，攻击者直接劫持了HTTP请求，并返回了内容给浏览器，根本不给浏览器同真实网站创建HTTPS链接的机会，所以浏览器会误觉得真实网站经过HTTP对外提供服务，天然也就不会向用户报告当前的链接不安全。因而乎攻击者几乎能够神不知鬼不觉的对请求和响应动手脚。

2. 解决之道：使用HSTS

既然创建HTTPS链接以前的这一次HTTP明文请求和重定向有可能被攻击者劫持，那么解决这一问题的思路天然就变成了如何避免出现这样的HTTP请求。咱们指望的浏览器行为是，当用户让浏览器发起HTTP请求的时候，浏览器将其转换为HTTPS请求，直接略过上述的HTTP请求和重定向，从而使得中间人攻击失效，规避风险。其大体流程以下：

 

图3：略过HTTP请求和重定向，直接发送HTTPS请求

• 第1步：用户在浏览器地址栏里输入网站域名，浏览器得知该域名应该使用HTTPS进行通讯
• 第2步：浏览器直接向网站发起HTTPS请求
• 第3步：网站返回相应的内容

那么问题来了，浏览器是如何作到这一点的呢？它怎么知道那个网站应该发HTTPS请求，那个网站应该用HTTP请求呢？此时就该HSTS粉墨登场了。

2.1 HSTS

HSTS的全称是HTTP Strict-Transport-Security，它是一个Web安全策略机制（web security policy mechanism）。

HSTS最先于2015年被归入到ThoughtWorks技术雷达，而且在2016年的最新一期技术雷达里，它直接从“评估（Trial）”阶段进入到了“采用（Adopt）“阶段，这意味着ThoughtWorks强烈主张业界积极采用这项安全防护措施，而且ThoughtWorks已经将其应用于本身的项目。

HSTS最为核心的是一个HTTP响应头（HTTP Response Header）。正是它可让浏览器得知，在接下来的一段时间内，当前域名只能经过HTTPS进行访问，而且在浏览器发现当前链接不安全的状况下，强制拒绝用户的后续访问要求。

HSTS Header的语法以下：

Strict-Transport-Security: <max-age=>[; includeSubDomains][; preload]

其中：

• max-age是必选参数，是一个以秒为单位的数值，它表明着HSTS Header的过时时间，一般设置为1年，即31536000秒。
• includeSubDomains是可选参数，若是包含它，则意味着当前域名及其子域名均开启HSTS保护。
• preload是可选参数，只有当你申请将本身的域名加入到浏览器内置列表的时候才须要使用到它。关于浏览器内置列表，下文有详细介绍。

2.2 让浏览器直接发起HTTPS请求####

只要在服务器返回给浏览器的响应头中，增长Strict-Transport-Security这个HTTP Header（下文简称HSTS Header），例如：

Strict-Transport-Security: max-age=31536000; includeSubDomains

就能够告诉浏览器，在接下来的31536000秒内（1年），对于当前域名及其子域名的后续通讯应该强制性的只使用HTTPS，直到超过有效期为止。

完整的流程以下图所示：

 

图4：完整的HSTS流程

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

2.3 让浏览器强制拒毫不安全的连接，不给用户选择的机会####

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

 

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

理论上而言，用户看到这个警告以后就应该提升警戒，意识到本身和网站之间的通讯不安全，可能被劫持也可能被窃听，若是访问的刚好是银行、金融类网站的话后果更是不堪设想，理应终止后续操做。然而现实很残酷，就个人实际观察来看，有很多用户在遇到这样的警告以后依然选择了继续访问。

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

 

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

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

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

4. Preload List：让防护更加完全

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

5. 一些Tips

Tips 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年。

Tips 2：如何加入到HSTS Preload List

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

• 具有一个有效的证书
• 在同一台主机上提供重定向响应，以及接收重定向过来的HTTPS请求
• 全部子域名均使用HTTPS
• 在根域名的HTTP响应头中，加入HSTS Header，并知足下列条件：
  • 过时时间最短不得少于18周（10886400秒）
  • 必须包含includeSubDomains参数
  • 必须包含preload参数
    当你准好这些以后，能够在HSTS Preload List的官网上（https://hstspreload.org）提交申请，或者了解更多详细的内容。

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

从提交申请到完成审核，成功加入到内置列表 ，中间可能须要等待几天到几周不等的时间。可经过官网https://hstspreload.org或在Chrome地址栏里输入chrome://net-internals/#hsts查询状态。

总结

随着愈来愈多的网站开始使用HTTPS，甚至是开启全站HTTPS，数据在传输过程当中的安全性可以获得极大的保障，与此同时，经过HSTS的帮助，避免SSL Stripping或者中间人攻击，可以使得数据通讯变得更加安全。但愿本篇文章经过对HSTS的解析，能使得更多的开发团队将HSTS运用到本身的项目中。

转自  https://www.jianshu.com/p/caa80c7ad45c