这是一个创建于 2850 天前的主题，其中的信息可能已经有所发展或是发生改变。
不谈预置列表，就谈强制 HTTPS ，如果只是首页要强制 HTTPS ，那么 301 我记得是缓存 100 年的。
如果是第一次请求就被中间人的情况 HSTS 也没用啊...，而且HSTS开启子域名后有一些没配证书的就会挂掉。
而且HSTS这种做法还会有一些兼容性问题，似乎也只在HTTPS下访问才会生效。
如果是第一次请求就被中间人的情况 HSTS 也没用啊...，而且HSTS开启子域名后有一些没配证书的就会挂掉。
而且HSTS这种做法还会有一些兼容性问题，似乎也只在HTTPS下访问才会生效。
第 1 条附言 · 2017-01-26 11:45:15 +08:00
个人感觉的总结如下：
1 、 301+过期时间配合 HPKP 比 preload 更灵活（子域名自由选择是否配置证书，过期时间灵活，在 HTTP 至 HTTPS 迁移方面有优势。 preload 更安全，但是反悔的话...）。
2 、在遇上仅首页要做重定向的情况下， HSTS 显得有点“没必要”（重复并且不支持老式浏览器。
3 、通配符大法好！
1 、 301+过期时间配合 HPKP 比 preload 更灵活（子域名自由选择是否配置证书，过期时间灵活，在 HTTP 至 HTTPS 迁移方面有优势。 preload 更安全，但是反悔的话...）。
2 、在遇上仅首页要做重定向的情况下， HSTS 显得有点“没必要”（重复并且不支持老式浏览器。
3 、通配符大法好！
 |
1
lhbc 2017-01-26 10:19:49 +08:00  2
1. preload 有效防止中间人
2. includeSubDomains 可以传染到所有子域 3. 中间人如果使用了无效证书，浏览器会拒绝例外证书 4. 301 默认不会缓存很久，通过头部让浏览器缓存指定时间 |
 |
2
lslqtz OP |
 |
3
kindjeff 2017-01-26 10:23:05 +08:00 via iPhone
所以需要预置列表
|
 |
4
ryd994 2017-01-26 10:26:36 +08:00 via Android
hsts 的所谓兼容性问题，恰恰是普通 https 中常见的弱点。
比如混合内容，这就是错误的处理，没 hsts 的时候有人凑合用而已 hsts 是对 https 的常见实现错误的修正，毕竟事实证明 https 当初的很多设计在理论上是安全的，可实际上没能做到 |
 |
5
davidyin 2017-01-26 10:28:26 +08:00
HSTS 的重要性就在于预置列表。
|
 |
7
ZE3kr 2017-01-26 10:37:48 +08:00 via iPhone 2
L3 已经说了一些了。还有就是 301 ，他只能重定向一个页面，如果是一个域名下的所有页面（ Path ）呢？假如有人就是根据某一个域名钓鱼，它可以定义一个你之前绝对没访问过的 Path ，那假如开了 HSTS 并之前访问过，肯定好比 301 好。
事实情况是，首页 301 之后，浏览器不知道所有页面都是 301 ，所以有 HSTS |
|
8
ZE3kr 2017-01-26 10:41:18 +08:00 via iPhone
HSTS 必须在 HTTPS 下才能生效啦，假如没 HTTPS 和 HTTPS 证书，也弄了 HSTS ，或者中间人加了这个 Header ，岂不是就再也无法忘问了？
还有不会有人会在实际部署时没配好证书就 includeSubDomains 的 |
 |
10
kn007 2017-01-26 11:32:13 +08:00
最主要是 1L 说的中间人如果使用了无效证书，浏览器会拒绝例外证书。而不会询问你是否继续，既然不安全，为何继续。
|
|
11
kn007 2017-01-26 11:33:09 +08:00
补充：当然必须 preload
|
|
12
kn007 2017-01-26 11:33:41 +08:00
另外 301 可以被劫持，并不安全。
|
|
15
kn007 2017-01-26 11:37:57 +08:00 1
@lslqtz 找了下，可以下屈哥写的文章。
https://imququ.com/post/sth-about-switch-to-https.html#toc-2 其中提到： 可以看到 HSTS 可以很好的解决 HTTPS 降级攻击，但是对于 HSTS 生效前的首次 HTTP 请求，依然无法避免被劫持。浏览器厂商们为了解决这个问题，提出了 HSTS Preload List 方案：内置一份可以定期更新的列表，对于列表中的域名，即使用户之前没有访问过，也会使用 HTTPS 协议。 |
|
16
lslqtz OP |
|
18
kn007 2017-01-26 11:42:47 +08:00
|
|
21
lslqtz OP @kn007 以后下一个买同样域名的时候就被我们坑死了（内心 OS ：为什么明明正常客户打不开 hhhh ）
|
|
22
lslqtz OP 突然发现 AppEnd 少了个括号...
|
|
24
lhbc 2017-01-26 11:57:18 +08:00
|
|
25
lslqtz OP @lhbc Let's Encrypt 自动续期，以及把 LE 的根 /中级加入 HPKP 名单即可～
|
|
26
lhbc 2017-01-26 12:05:59 +08:00
@lslqtz 还有那种证书被 CA 意外 /正常吊销的情况啊
对于小公司， HPKP 还是比较麻烦，可能平时连工作流程 /文档都没有，怎么去管理 HPKP ？ |
 |
29
VmuTargh 2017-01-26 13:16:35 +08:00
@lhbc HPKP/DANE 只能够保证这个 CA 是你要的信任 CA ，如果是吊销的情况得靠 OCSP-Stapling&OCSP-Must-Staple 或者 Certificate Transparency
|
|
30
VmuTargh 2017-01-26 13:18:10 +08:00
啊更正一下， DANE 是 per Cert 而不是 per CA
|
|
32
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 |
|
33
ZE3kr 2017-01-26 13:37:09 +08:00
@ryd994 混合内容正确处理方法（不推荐）： Content- Security-Policy: upgrade-insecure-requests
这是真正的消除混合内容的方法，**包括外部链接在内**。 |
|
34
VmuTargh 2017-01-26 13:39:23 +08:00
|
|
35
lslqtz OP |
|
36
lslqtz OP @ZE3kr 但对于老式浏览器 额外 HSTS 就没必要了
HPKP 也不一定必要和支持，但是有人提到无法取消告警，就提了提。 |
 |
38
otakustay 2017-01-26 15:39:55 +08:00
因为非 HTTPS 的 301 能被劫持，所以面对有针对性的钓鱼的话，没有 HSTS 的 HTTPS 跟没有一样，劫持下初始的 301 跳掉就行了，整个 HTTPS 就绕开了
|
|
39
lslqtz OP @otakustay 首次访问 HSTS 也能被劫持。
301 和 HSTS 第二次访问都会使用缓存 |
 |
42
valkjsaaa 2017-01-27 03:56:26 +08:00
我怀疑 HSTS 有一个作用是如果你的子域名被劫持了，实际上还是可以盗取 Cookie 的，所以想要安全，最好全站 HSTS 。这个 301 就搞不定了吧？
|
|
43
lslqtz OP @valkjsaaa Cookie 不一定是泛域的，子域名的确是需要 HSTS ，但是实际上除了裸域和 www ，对大部分人来说子域的需求不是那么大。
|
 |
44
msg7086 2017-01-29 13:55:44 +08:00 1
考虑用 307 而不是 301 。
HPKP 必须包含一个备用密钥，否则 HPKP 直接不生效。 HSTS 就是在安全性和灵活性之间选择了安全性，而你说的跳转大法则是相反，在安全性和灵活性之间选择了灵活性。 这些东西就是些 trade off 而已，根据需要来选择就好了。 你问有没有意义，当然是有的，而且和你关系不大，因为你不需要这个级别的安全性，所以感受不到其意义。 |
|
46
msg7086 2017-01-31 01:37:36 +08:00
@lslqtz HPKP 和 HSTS 要解决的问题是不太一样的。
比如你打开 HPKP 以后，我仍然可以在任何一个公共 Wifi 上劫持你的 301 请求。 |
 |
49
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.
|
|
50
lslqtz OP @Williamp 如果是通过响应头发送的不能阻止降级攻击，而且缓存也能够实现相同的效果（强制缓存多久，然后就不会向服务器请求响应）
|
|
51
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.
|
 |
52
kcats 2020-01-18 14:56:41 +08:00
我在想为啥不是浏览器直接优先发起 https 请求呢? 如果 https 失败, 再请求 http
|
Select Language