在想一个问题： HSTS 为什么有意义？

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

› Certbot 使用文档

› Dehydrated

› Stay.live 证书有效期监控

› HTTP Strict Transport Security

› OpenSSL 官网

› Qualys SSL Test

› 证书链补全工具

› 在线 CSR 生成工具

› SSL 云监控

› What's My Chain Cert?

› Certificate Search by Comodo

这是一个创建于 2888 天前的主题，其中的信息可能已经有所发展或是发生改变。

不谈预置列表，就谈强制 HTTPS ，如果只是首页要强制 HTTPS ，那么 301 我记得是缓存 100 年的。
如果是第一次请求就被中间人的情况 HSTS 也没用啊...，而且HSTS开启子域名后有一些没配证书的就会挂掉。
而且HSTS这种做法还会有一些兼容性问题，似乎也只在HTTPS下访问才会生效。

第 1 条附言 · 2017-01-26 11:45:15 +08:00

个人感觉的总结如下：
1 、 301+过期时间配合 HPKP 比 preload 更灵活（子域名自由选择是否配置证书，过期时间灵活，在 HTTP 至 HTTPS 迁移方面有优势。 preload 更安全，但是反悔的话...）。
2 、在遇上仅首页要做重定向的情况下， HSTS 显得有点“没必要”（重复并且不支持老式浏览器。
3 、通配符大法好！

HSTS

强制

中间人

预置

52 条回复 • 2020-01-18 14:56:41 +08:00

lhbc

2017-01-26 10:19:49 +08:00

1. preload 有效防止中间人
2. includeSubDomains 可以传染到所有子域
3. 中间人如果使用了无效证书，浏览器会拒绝例外证书
4. 301 默认不会缓存很久，通过头部让浏览器缓存指定时间

lslqtz

2017-01-26 10:23:05 +08:00 via iPhone

@lhbc 不谈 preload （不谈预置列表）和子域（只是首页）了啊...
4 的话 301 网上看默认 100 年
3 是个好理由发个感谢

kindjeff

2017-01-26 10:23:05 +08:00 via iPhone

所以需要预置列表

ryd994

2017-01-26 10:26:36 +08:00 via Android

hsts 的所谓兼容性问题，恰恰是普通 https 中常见的弱点。
比如混合内容，这就是错误的处理，没 hsts 的时候有人凑合用而已
hsts 是对 https 的常见实现错误的修正，毕竟事实证明 https 当初的很多设计在理论上是安全的，可实际上没能做到

davidyin

2017-01-26 10:28:26 +08:00

HSTS 的重要性就在于预置列表。

lhbc

2017-01-26 10:37:37 +08:00

@lslqtz 301 大多数浏览器在重启后没有缓存。可以用 Cache-Control 指定缓存时间

ZE3kr

2017-01-26 10:37:48 +08:00 via iPhone

L3 已经说了一些了。还有就是 301 ，他只能重定向一个页面，如果是一个域名下的所有页面（ Path ）呢？假如有人就是根据某一个域名钓鱼，它可以定义一个你之前绝对没访问过的 Path ，那假如开了 HSTS 并之前访问过，肯定好比 301 好。

事实情况是，首页 301 之后，浏览器不知道所有页面都是 301 ，所以有 HSTS

ZE3kr

2017-01-26 10:41:18 +08:00 via iPhone

HSTS 必须在 HTTPS 下才能生效啦，假如没 HTTPS 和 HTTPS 证书，也弄了 HSTS ，或者中间人加了这个 Header ，岂不是就再也无法忘问了？

还有不会有人会在实际部署时没配好证书就 includeSubDomains 的

VmuTargh

2017-01-26 11:19:17 +08:00

@lhbc 第三点不是 HPKP/DANE 的事情么（

kn007

2017-01-26 11:32:13 +08:00

最主要是 1L 说的中间人如果使用了无效证书，浏览器会拒绝例外证书。而不会询问你是否继续，既然不安全，为何继续。

kn007

2017-01-26 11:33:09 +08:00

补充：当然必须 preload

kn007

2017-01-26 11:33:41 +08:00

另外 301 可以被劫持，并不安全。

lslqtz

2017-01-26 11:35:44 +08:00 via iPhone

@kn007 在第一次建连时， HSTS 同样可以被劫持。
第二次建连时，两个都可以被缓存。

kn007

2017-01-26 11:36:51 +08:00

@lslqtz 所以我下面补充了， preload 是必须的。

kn007

2017-01-26 11:37:57 +08:00

@lslqtz 找了下，可以下屈哥写的文章。
https://imququ.com/post/sth-about-switch-to-https.html#toc-2

其中提到：
可以看到 HSTS 可以很好的解决 HTTPS 降级攻击，但是对于 HSTS 生效前的首次 HTTP 请求，依然无法避免被劫持。浏览器厂商们为了解决这个问题，提出了 HSTS Preload List 方案：内置一份可以定期更新的列表，对于列表中的域名，即使用户之前没有访问过，也会使用 HTTPS 协议。

lslqtz

2017-01-26 11:38:48 +08:00 via iPhone

@ryd994 HSTS 也是允许混合内容的吧...
如果不要子域名， 301 感觉重新在加一个 HSTS 没啥必要。
@lhbc 已发感谢。
@VmuTargh HPKP +1
@kn007 感觉 preload 不太灵活...301 可以灵活的设置过期时间，配合 HPKP 。

lslqtz

2017-01-26 11:39:41 +08:00 via iPhone

@kn007 哈哈，这篇文章我也看过。
经常逛屈屈的博客。

kn007

2017-01-26 11:42:47 +08:00

@lslqtz 嗯，我一开始也是你这种想法，但配合泛域名证书就无所谓灵活不灵活了。。。有了 http2 ，我想不出为什么要回到 http

前几天 V2 有位 BuySSL 的赞助了份泛域名。

lslqtz

2017-01-26 11:43:56 +08:00 via iPhone

@kn007 可我没有啊噗噗=A=

kn007

2017-01-26 11:45:55 +08:00

@lslqtz 哈哈哈哈。因为有了 preload 和 hsts ，我就没上 HPKP ，无所谓了。懒得维护。

lslqtz

2017-01-26 11:47:10 +08:00 via iPhone

@kn007 以后下一个买同样域名的时候就被我们坑死了（内心 OS ：为什么明明正常客户打不开 hhhh ）

lslqtz

2017-01-26 11:48:38 +08:00 via iPhone

突然发现 AppEnd 少了个括号...

kn007

2017-01-26 11:50:57 +08:00

@lslqtz 哈哈，那是不可能的，我是不会让出去的，嗯嗯嗯~

lhbc

2017-01-26 11:57:18 +08:00

@VmuTargh
@lslqtz
HPKP 需要团队维护，如果缺少实践及长期规划，可能会造成严重的生产事故
相反， HSTS 就简单些，只要求证书有效

lslqtz

2017-01-26 11:58:54 +08:00 via iPhone

@lhbc Let's Encrypt 自动续期，以及把 LE 的根 /中级加入 HPKP 名单即可～

lhbc

2017-01-26 12:05:59 +08:00

@lslqtz 还有那种证书被 CA 意外 /正常吊销的情况啊
对于小公司， HPKP 还是比较麻烦，可能平时连工作流程 /文档都没有，怎么去管理 HPKP ？

kn007

2017-01-26 12:23:19 +08:00

@lhbc 这确实是个问题。+1

但是这个无所谓小公司的问题，主要还是运维的能力问题。还有个人处理能力的问题。

lslqtz

2017-01-26 12:57:40 +08:00 via iPhone

@lhbc HPKP 可以设置多个 CA 做备用～
但是小公司 HSTS 都不知道怎么用...

VmuTargh

2017-01-26 13:16:35 +08:00

@lhbc HPKP/DANE 只能够保证这个 CA 是你要的信任 CA ，如果是吊销的情况得靠 OCSP-Stapling&OCSP-Must-Staple 或者 Certificate Transparency

VmuTargh

2017-01-26 13:18:10 +08:00

啊更正一下， DANE 是 per Cert 而不是 per CA

lslqtz

2017-01-26 13:20:39 +08:00 via iPhone

@VmuTargh 他的意思是开了 HPKP 证书误吊销无法换～

ZE3kr

2017-01-26 13:32:46 +08:00

我怎么觉得 HPKP 一点也不灵活，换 CA 都麻烦。 DANE 稍微灵活一点，但兼容性不如 HPKP 。 HPKP 兼容性不如 HSTS 。 preload 比较坑的就是必须要启用子域名，但是大不了不加 preload 和子域名不是还照样用么。

还有**HPKP 和 HSTS 是两个不同的东西**。 HSTS 是必须配合 301 ， HPKP 可以不配合 301 。不知道 lz 为什么说 HSTS 重复？只不过是多了一个 header 而已。

所以，如果是全站 HTTPS ，既然开了 301 就一定要一起开 HSTS （可以不加子域名，而且 HSTS 也是可以配置灵活的有效期啊），没有副作用。 HPKP 没必要开（哪家 CA 敢乱发证书？）

HSTS 还有一个好处，就是证书不是有效 CA 的话，直接无法访问，不去问“是否信任”之类的，正如 L10 和 L1 说的。而 HPKP 直接绑定在一家或几家 CA ，不灵活。

HPKP 兼容性： http://caniuse.com/#feat=publickeypinning
HSTS 兼容性： http://caniuse.com/#feat=stricttransportsecurity
DANE 兼容性：约为 0

很明显 HSTS 兼容性好

@VmuTargh DANE 是可以对 CA 或中间证书配置的，相比 HPKP 多了 Per Cert

ZE3kr

2017-01-26 13:37:09 +08:00

@ryd994 混合内容正确处理方法（不推荐）： Content- Security-Policy: upgrade-insecure-requests

这是真正的消除混合内容的方法，**包括外部链接在内**。

VmuTargh

2017-01-26 13:39:23 +08:00

@ZE3kr HPKP 同样可以 per Cert ，但是实际部署的时候都是拿中间证书来搞。另外 HPKP 我的 ttl 是设置到很低的，避免换 CA 签发证书的时候爆炸（我就被坑过一次）
@lslqtz 低 ttl 设定即可（另外不设定备用 CA 怪我咯

lslqtz

2017-01-26 13:50:13 +08:00 via iPhone

@VmuTargh 我知道可以啊是回复他的...
@ZE3kr 我们已经在用了，主机壳的页面 HTTPS 后插入的图片改链接失败了，所以就...

lslqtz

2017-01-26 13:52:39 +08:00 via iPhone

@ZE3kr 但对于老式浏览器额外 HSTS 就没必要了
HPKP 也不一定必要和支持，但是有人提到无法取消告警，就提了提。

lslqtz

2017-01-26 13:54:08 +08:00 via iPhone

@ZE3kr 我的意思就是：在功能重复的情况下，尽量精简

otakustay

2017-01-26 15:39:55 +08:00

因为非 HTTPS 的 301 能被劫持，所以面对有针对性的钓鱼的话，没有 HSTS 的 HTTPS 跟没有一样，劫持下初始的 301 跳掉就行了，整个 HTTPS 就绕开了

lslqtz

2017-01-26 18:06:06 +08:00 via iPhone

@otakustay 首次访问 HSTS 也能被劫持。
301 和 HSTS 第二次访问都会使用缓存

otakustay

2017-01-26 20:34:13 +08:00

@lslqtz 所以有 hsts preload list 这东西啊， 301 能靠 preload 不被劫持么

lslqtz

2017-01-26 22:03:43 +08:00

@otakustay 不是说不谈那个了么。。。

valkjsaaa

2017-01-27 03:56:26 +08:00

我怀疑 HSTS 有一个作用是如果你的子域名被劫持了，实际上还是可以盗取 Cookie 的，所以想要安全，最好全站 HSTS 。这个 301 就搞不定了吧？

lslqtz

2017-01-27 05:32:18 +08:00 via iPhone

@valkjsaaa Cookie 不一定是泛域的，子域名的确是需要 HSTS ，但是实际上除了裸域和 www ，对大部分人来说子域的需求不是那么大。

msg7086

2017-01-29 13:55:44 +08:00

考虑用 307 而不是 301 。
HPKP 必须包含一个备用密钥，否则 HPKP 直接不生效。
HSTS 就是在安全性和灵活性之间选择了安全性，而你说的跳转大法则是相反，在安全性和灵活性之间选择了灵活性。
这些东西就是些 trade off 而已，根据需要来选择就好了。
你问有没有意义，当然是有的，而且和你关系不大，因为你不需要这个级别的安全性，所以感受不到其意义。

lslqtz

2017-01-30 03:52:03 +08:00 via iPhone

@msg7086 我感觉如果只是在裸域的话， HPKP+301 能兼顾灵活+安全

msg7086

2017-01-31 01:37:36 +08:00

@lslqtz HPKP 和 HSTS 要解决的问题是不太一样的。
比如你打开 HPKP 以后，我仍然可以在任何一个公共 Wifi 上劫持你的 301 请求。

lslqtz

2017-01-31 08:55:18 +08:00 via iPhone

@msg7086 缓存了就无法劫持了...
第一次都能被劫持

msg7086

2017-02-01 10:27:35 +08:00

@lslqtz 301 缓存和 HSTS 缓存还不太一样。 301 的缓存应该很容易被清除……

Williamp

2017-03-07 14:58:17 +08:00

HSTS stands for HTTP Strict Transport Security which helps to stop HTTP downgrade attacks while transferring user's data from http to https.

lslqtz

2017-03-08 18:32:23 +08:00

@Williamp 如果是通过响应头发送的不能阻止降级攻击，而且缓存也能够实现相同的效果（强制缓存多久，然后就不会向服务器请求响应）

Williamp

2017-03-23 19:32:00 +08:00

@lslqtz Yes, HSTS header response only sent over secure transport layer and that's why attacker get a chance to complete targeted attack.

kcats

2020-01-18 14:56:41 +08:00

我在想为啥不是浏览器直接优先发起 https 请求呢? 如果 https 失败, 再请求 http