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
|