查看: 10183|回复: 6
Chrome的HSTS设置问题
本帖最后由 穿越星空 于
20:34 编辑
在chrome://net-internals/#hsts中添加域名，可强制Chrome以HTTPS方式访问域名所对应的网站，设置图如下：
122c6b9cbc1f4d.jpg (37.99 KB, 下载次数: 1)
23:48 上传
请教两个问题：
①下面两个复选框勾选是起什么作用的？
②可有办法查询所有添加的域名吗？
https anywhere 装个全自动的扩展多好
＿一方通行、
https anywhere 装个全自动的扩展多好
google就跳转&&了&&不能自定义ncr了
google就跳转&&了&&不能自定义ncr了
google所有的域名都有https加密版 我这里google的每个搜索域名都可以正常使用 没出现跳转 的情况
https anywhere 装个全自动的扩展多好
浏览器自己能实现，就不依赖扩展了，毕竟扩展是可以截获所有数据的。
＿一方通行、
google所有的域名都有https加密版 我这里google的每个搜索域名都可以正常使用 没出现跳转https:// ...
你装了https everywhere试试看打开谷歌是不是自己跳转了
你装了https everywhere试试看打开谷歌是不是自己跳转了
我这里没跳
Copyright & KaFan & All Rights Reserved.
Powered by Discuz! X3.1( 苏ICP备号 ) GMT+8,为什么我们要使用新型Web安全协议HSTS？_综合_突袭网
当前位置&:&&&& 为什么我们要使用新型Web安全协议HSTS？
热门标签：&
为什么我们要使用新型Web安全协议HSTS？
编辑：张德勇评论：
HTTP Strict Transport Security (通常简称为HSTS) 是一个安全功能，它告诉浏览器只能通过HTTPS访问当前资源, 禁止HTTP方式。
0&01. Freebuf百科：什么是Strict-Transport-Security
我摘自owasp上的一段定义：
HTTP&Strict&Transport&Security&(HSTS)&is&an&opt-in&security&enhancement&that&is&specified&by&a&web&application&through&the&use&of&a&special&response&header.&Once&a&supported&browser&receives&this&header&that&browser&will&prevent&any&communications&from&being&sent&over&HTTP&to&the&specified&domain&and&will&instead&send&all&communications&over&HTTPS.&It&also&prevents&HTTPS&click&through&prompts&on&browsers.The&specification&has&been&released&and&published&end&of&2012&as&RFC&6797&(HTTP&Strict&Transport&Security&(HSTS))&by&the&IETF.&(Reference&see&in&the&links&at&the&bottom.)
一个网站接受一个HTTP的请求，然后跳转到HTTPS，用户可能在开始跳转前，通过没有加密的方式和服务器对话，比如，用户输入或者直接。这样存在中间人攻击潜在威胁，跳转过程可能被恶意网站利用来直接接触用户信息，而不是原来的加密信息。网站通过HTTP Strict Transport Security通知浏览器，这个网站禁止使用HTTP方式加载，浏览器应该自动把所有尝试使用HTTP的请求自动替换为HTTPS请求。
0&02. 我们为什么需要开启Strict-Transport-Security &
想想这样一种场景：
有的网站开启了https，但为了照顾用户的使用体验（因为用户总是很赖的，一般不会主动键入https，而是直接输入域名, 直接输入域名访问，默认就是http访问）同时也支持http访问，当用户http访问的时候，就会返回给用户一个302重定向，重定向到https的地址，然后后续的访问都使用https传输,这种通信模式看起来貌似没有问题，但细致分析，就会发现种通信模式也存在一个风险，那就是这个302重定向可能会被劫持篡改，如果被改成一个恶意的或者钓鱼的https站点，然后，你懂得，一旦落入钓鱼站点，数据还有安全可言吗？
对于篡改302的攻击，建议服务器开启HTTP Strict Transport Security功能，这个功能的含义是：
&当用户已经安全的登录开启过htst功能的网站 (支持hsts功能的站点会在响应头中插入：Strict-Transport-Security) 之后，支持htst的浏览器(比如chrome. firefox)会自动将这个域名加入到HSTS列表，下次即使用户使用http访问这个网站，支持htst功能的浏览器就会自动发送https请求（前提是用户没有清空缓存，如果清空了缓存第一次访问还是明文，后续浏览器接收到服务器响应头中的Strict-Transport-Security，就会把域名加入到hsts缓存中，然后才会在发送请求前将http内部转换成https），而不是先发送http，然后重定向到https，这样就能避免中途的302重定向URL被篡改。&&进一步提高通信的安全性。&&&
上面是我自己的理解，下面是owasp中文站点关于hsts的描述：
HSTS的作用是强制客户端（如浏览器）使用HTTPS与服务器创建连接。服务器开启HSTS的方法是，当客户端通过HTTPS发出请求时，在服务器返回的超文本传输协议响应头中包含Strict-Transport-Security字段。非加密传输时设置的HSTS字段无效。
比如，/ 的响应头含有Strict-Transport-Security: max-age=; includeSubDomains。这意味着两点：
在接下来的一年（即秒）中，浏览器只要向或其子域名发送HTTP请求时，必须采用HTTPS来发起连接。比如，用户点击超链接或在地址栏输入 / ，浏览器应当自动将 http 转写成 https，然后直接向 / 发送请求。
在接下来的一年中，如果
服务器发送的TLS证书无效，用户不能忽略浏览器警告继续访问网站。
HSTS可以用来抵御SSL剥离攻击。SSL剥离攻击是中间人攻击的一种，由Moxie Marlinspike于2009年发明。他在当年的黑帽大会上发表的题为&New Tricks For Defeating SSL In Practice&的演讲中将这种攻击方式公开。SSL剥离的实施方法是阻止浏览器与服务器创建HTTPS连接。它的前提是用户很少直接在地址栏输入https://，用户总是通过点击链接或3xx重定向，从HTTP页面进入HTTPS页面。所以攻击者可以在用户访问HTTP页面时替换所有https://开头的链接为http://，达到阻止HTTPS的目的。
HSTS可以很大程度上解决SSL剥离攻击，因为只要浏览器曾经与服务器创建过一次安全连接，之后浏览器会强制使用HTTPS，即使链接被换成了HTTP
另外，如果中间人使用自己的自签名证书来进行攻击，浏览器会给出警告，但是许多用户会忽略警告。HSTS解决了这一问题，一旦服务器发送了HSTS字段，用户将不再允许忽略警告。
0&03. Strict-Transport-Security的一些不足
用户首次访问某网站是不受HSTS保护的。这是因为首次访问时，浏览器还未收到HSTS，所以仍有可能通过明文HTTP来访问。解决这个不足目前有两种方案，一是浏览器预置HSTS域名列表，Google Chrome、Firefox、Internet Explorer和Spartan实现了这一方案。二是将HSTS信息加入到域名系统记录中。但这需要保证DNS的安全性，也就是需要部署域名系统安全扩展。截至2014年这一方案没有大规模部署。
由于HSTS会在一定时间后失效（有效期由max-age指定），所以浏览器是否强制HSTS策略取决于当前系统时间。部分操作系统经常通过网络时间协议更新系统时间，如Ubuntu每次连接网络时，OS X Lion每隔9分钟会自动连接时间服务器。攻击者可以通过伪造NTP信息，设置错误时间来绕过HSTS。解决方法是认证NTP信息，或者禁止NTP大幅度增减时间。比如Windows 8每7天更新一次时间，并且要求每次NTP设置的时间与当前时间不得超过15小时
0&04. 我的一些测试
目标域名： (这个站点不支持hsts功能) 同盾科技的风险控制管理系统(打个软广，同盾科技，基于大数据，专注反欺诈)。
第一次访问：在浏览器地址栏键入：
这个域名并不在chrome浏览器的hsts的缓存中，也不在hsts中的preload list中(像facebook、twitter等网站已经内置在preload list中，所以每次请求这些站点的时候浏览器都会自动将http 转换成htttps)，所以不会在发送请求前将http转换成https请求。
我们来把这个站点手动加入到chrome浏览器的hsts缓存中：
在未清空chrome浏览器历史记录的前提下，我们再次访问这个站点：
可以看到，一个307 响应码，这是chrome浏览器的内部转换，将http转换成https后再发送请求。
备注：为什么我们要求在未清空chrome浏览器的缓存前访问呢？
因为如果清空了chrome浏览器的缓存之后，我们手动加入到hsts缓存中的域名就会被清除，也就不会看到预期的效果了。
我们先清空chrome浏览器的缓存，然后在浏览器的地址栏中键入 &
可以看到(支付宝)这个站点并没有在chrome 浏览器的内置的preload list中，所以第一次访问的时候，chrome浏览器并不会将http转换成https。
而是由前端的F5的负载均衡(BigIP)器将http请求重定向到https请求。
我们继续看看这次请求的其他响应：
可以看到支付宝站点服务器是支持hsts功能的，在其响应头中插入了：Strict-Transport-Security，并且设置这个头部的有效期，只要不手动清空缓存，那么在这个有效期内，chrome浏览器都会将所有发送这个站点的http请求在内部转换成https再发送出去。
浏览器在收到带有Strict-Transport-Security响应头的报文后，就会将这个站点加入到hsts缓存中，下次以http访问的时候就会被自动转换成https。
我们这时查看以下hsts的缓存中是不是有了
正如你所见：已经被加入到了chrome浏览器的缓存中。
这时候在未清空浏览器缓存的前提下再次访问 &
看到了吧，熟悉的307响应码，浏览器做了内部转换，将http转换成https。
脸书是已经加入到chrome浏览器hsts preload list中的。
注意到没，信息很详细哦！
看看我大百度呢？
清空chrome浏览器缓存，在地址栏键入：
很遗憾，我大百度也不在chrome hsts preload list中。
在看看这次请求中的其他响应报文呢：
也没有看到 Strict-Transport-Security的影子。HSTS详解 - 简书
1. 缘起：启用HTTPS也不够安全
有不少网站只通过HTTPS对外提供服务，但用户在访问某个网站的时候，在浏览器里却往往直接输入网站域名（例如），而不是输入完整的URL（例如），不过浏览器依然能正确的使用HTTPS发起请求。这背后多亏了服务器和浏览器的协作，如下图所示。
图1：服务器和浏览器在背后帮用户做了很多工作
简单来讲就是，浏览器向网站发起一次HTTP请求，在得到一个重定向响应后，发起一次HTTPS请求并得到最终的响应内容。所有的这一切对用户而言是完全透明的，所以在用户眼里看来，在浏览器里直接输入域名却依然可以用HTTPS协议和网站进行安全的通信，是个不错的用户体验。
一切看上去都是那么的完美，但其实不然，由于在建立起HTTPS连接之前存在一次明文的HTTP请求和重定向（上图中的第1、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粉墨登场了。
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年，即秒。
includeSubDomains是可选参数，如果包含它，则意味着当前域名及其子域名均开启HSTS保护。
preload是可选参数，只有当你申请将自己的域名加入到浏览器内置列表的时候才需要使用到它。关于浏览器内置列表，下文有详细介绍。
2.2 让浏览器直接发起HTTPS请求
只要在服务器返回给浏览器的响应头中，增加Strict-Transport-Security这个HTTP Header（下文简称HSTS Header），例如：
Strict-Transport-Security: max-age=; includeSubDomains
就可以告诉浏览器，在接下来的秒内（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等主流浏览器均在使用。
6. 一些Tips
Tips 1：如何配置HSTS
很多地方都可以进行HSTS的配置，例如反向代理服务器、应用服务器、应用程序框架，以及应用程序中自定义Header。你可以根据实际情况进行选择。
常见的是在代理服务器中进行配置，以Nginx为例，只需在配置文件中加上下面这条指令即可：add_header Strict-Transport-Security "max-age=; includeSubDomains"
不过需要特别注意的是，在生产环境下使用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周（秒）
必须包含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运用到自己的项目中。支持 HSTS 比你想象的更容易。
由于服务器管理员没能正确设置&，现今大量的 HTTPS 流量都能被轻松劫持。
HSTS 是一个被当前大多数 Web 浏览器所支持的 Web 安全策略，它可以帮助 Web 管理员保护他们的服务器和用户避免遭到 HTTPS 降级、中间人攻击和 Cookie 劫持等 HTTPS 攻击的危害。
95%&的 HTTPS 连接处于风险中
据最近的&&报告数据显示，当前多达 95% 的服务器所运行的 HTTPS 没有正确地设置 HSTS 或其它配置，以至于将 HTTPS 连接暴露于上述攻击风险之中。
更值得注意的是，Netcraft 在三年前进行的同样扫描，不正确配置的 HSTS 比例仍同现在一样。这表明 Web 管理员们并没有学会或被告知如何正确地设置 HSTS。
针对这些不安全的站点的最容易的攻击场景是 HTTPS 降级攻击，攻击者可以选择多种方式来迫使一个看起来安全的 HTTPS 连接根本不使用数据加密或使用更弱的算法，这样攻击者就可以进行数据窃取了。
据安全研究人员称，在这 95% 的没有正确设置 HSTS 的站点中，有很多银行和金融机构的网站。
你可以通过下面一行配置激活你的 HSTS
不需要费脑筋，你只需要将下述的一行配置添加到你的 HTTPS 服务器配置中即可实现 HSTS。
[crayon-58d7b39acaa inline="true" ]Strict-Transport-Security: max-age=;
[crayon-58d7b39acaa inline="true" ]Strict-Transport-Security: max-age=;
这一行可以让服务器告诉浏览器仅通过 HTTPS 连接来访问其内容，其策略有效期为长达一年的最大有效时间。
当上述配置生效后，即便用户在他的浏览器中输入 URL 时写了 &http://&前缀，浏览器仍将会自动切换&https://&。
更多关于 HTTPS 及 HSTS 的技术实现细节，请参阅以下文章：