前几天和朋友喝茶，聊起网站安全，他一脸笃定地跟我说：“我现在全站上了HSTS，等于给网站穿了防弹衣，什么中间人劫持、SSL剥离攻击，统统不怕了！” 看着他自信满满的样子，我一时语塞，不知道该不该泼这盆冷水。确实，HSTS（HTTP Strict Transport Security）是个好东西，它能强制浏览器只通过HTTPS访问你的站点，彻底堵死了从HTTP入口被攻击的可能。但是，如果你觉得它能“完全”避免劫持，那可能真的把网络安全想得太简单了。
HSTS最大的弱点，恰恰在于它的生效机制。想象一下这个场景：一个用户第一次访问你的网站。他的浏览器里没有任何关于你网站的HSTS记录。这个时候，如果有一个足够强大的攻击者（比如在公共Wi-Fi里），完全可以在用户发出第一个HTTP请求时，就把它劫持走。因为在这个“第一次”的真空期，浏览器还不知道要强制HTTPS呢！这个首次访问的漏洞，在安全圈里被称为“HSTS空白期”，是理论上无法被HSTS本身弥补的。
你可能会想到HSTS Preload List——那个被硬编码进Chrome、Firefox等主流浏览器内核的“好人名单”。如果你的域名提交并被收录进去了，那么用户即使用全新的浏览器，也会从一开始就知道必须用HTTPS访问你。这听起来很完美，对吧？
但问题又来了：这个列表的更新和同步，是需要时间的。从你提交申请，到各大浏览器厂商更新版本并推送到全球用户的设备上，这个周期可能是几个月。在这期间，新用户依然暴露在风险之下。而且，这个列表的收录有严格的门槛，不是你想进就能进的。
好，就算我们成功用HSTS把用户“赶”上了HTTPS通道，是不是就高枕无忧了？别忘了，HTTPS的基石是SSL/TLS证书。如果证书本身出了问题，HSTS也无能为力。
比如，如果证书颁发机构（CA）被攻破，攻击者完全可以为一个钓鱼网站签发一个对你域名来说“合法”的证书。浏览器看到有效的证书，HSTS策略也被遵守了（确实是HTTPS连接），但它连接到的却是攻击者的服务器。这种基于“合法”证书的中间人攻击，HSTS根本识别不出来。
我自己就遇到过更哭笑不得的情况：有一次网站迁移，运维同事不小心在负载均衡器上配置错了证书链，导致中间证书缺失。结果就是，一部分用户的浏览器认为证书无效，直接阻断访问；而另一部分用户（包括HSTS策略）却正常连接了——只不过连接到了一个“不完整”的安全通道上。你看，HSTS只管是不是HTTPS，可管不了这个HTTPS通道本身是否“健康”。
我们总是聚焦在“浏览器到网站”这段路程，但劫持的起点，可能远比我们想的要早。DNS劫持听说过吧？如果用户在访问你的网站之前，解析域名的请求就被篡改了，直接指向了攻击者的IP。那么后续无论浏览器是走HTTP还是被HSTS强制到HTTPS，最终连接的都是错误的服务器。HSTS对DNS劫持，是完全免疫的——因为它的作用范围在DNS解析之后。
所以，我现在看待HSTS的态度很明确：它是一个极其重要、必须配置的“强制安全策略”，能消灭一大片低级和常见的攻击向量。但千万别把它神话为“终极解决方案”。
真正的安全，像是一个洋葱，需要一层又一层。HSTS是里面很关键的一层，但外面还需要DNSSEC来保护解析过程，里面还需要定期审计证书和密钥，底层还需要可靠的托管和网络环境。指望单单一层HSTS就刀枪不入，那可能只是在心里给自己筑起了一座不设防的城墙。
茶凉了，我朋友若有所思。希望他回去之后，会给他的“防弹衣”旁边，再配上盾牌和头盔。
参与讨论
HSTS第一次访问的空窗期确实是个大问题，很多人没意识到这点。
原来预加载列表也不是万能的啊，更新延迟这茬真没想到。
作者比喻很形象，安全确实得像洋葱一样层层防护。
所以光靠HSTS确实不够，还得配合DNSSEC和其他措施才行。
😂 朋友自信满满被泼冷水的场景过于真实了。
那如果用户清除了浏览器缓存，HSTS记录没了，是不是又得重新经历这个风险期？
说得对，证书出问题的话HSTS根本防不住，这点很重要。
感觉文章把HSTS的优缺点讲得很透彻，不是一味吹捧。
长知识了，之前真以为上了HSTS就万事大吉呢。
最后一句“配上盾牌和头盔”说得真好，安全没有银弹。
催更！能不能再写写具体怎么配置这些安全措施啊？