HTTPS真的就是安全的象征吗？HTTPS检查工具带来的安全威胁
在很多人印象中，HTTPS就是安全的象征，而为了对这些“安全”的流量进行检查，很多安全产品，包括杀毒软件和防火墙都具备HTTPS检查的功能，通过这样的功能排除其中的安全威胁。然而近日US-CERT却发布了一则预警，TA17-075A，对部分HTTPS检查产品发出安全预警，提到部分SSL/TLS拦截软件未能执行有效验证，或者未能充分传递验证状态，这可能被第三方发动中间人攻击。
US-CERT为什么要发出这个预警呢？让我们来捋一捋最近发生的一些事情。
US-CERT专家发文称SSL检查有风险
首先是2015年初的时候，Superfish和PrivDog这两款SSL检查工具因为没能正确验证SSL引起了US-CERT专家的重视。专家称因为没能正确验证SSL，导致用户系统容易被攻击者进行HTTPS嗅探。
接连几个SSL检查工具被曝存在相似问题后，US-CERT专家Will Dormann决定深入探究这个问题，发表了《SSL检查的风险》一文，其中指出了一些问题：
1. 许多人并不了解SSL和TSL的功能；
2. SSL检查产品比他想象的流行得多；
3. 许多有SSL检查能力的应用都存在一些漏洞，可给用户带来风险；
4. 即便SSL检查做得跟浏览器一样安全，也会给用户带来一定风险。
下面我们一一来讲。
背景知识
SSL和TLS的目的主要有两个：一是认证与客户端通信的服务器，二是加密客户端与服务器之间发送的数据。有些人可能认为SSL和TLS能够实现端到端加密，这种观点是不对的。SSL和TLS只有在点到点的情况下才能实现安全认证和加密。我们先来看个例子，在本例中的点到点通信也可以被认为是端到端的通信：
客户端能够验证安全通信，但只能和其通信的下一个点进行验证。在上面的例子当中，客户端直接和目标系统建立SSL/TLS连接。客户端软件通过系统上的大量根证书来验证它连接的系统。至于这个系统是不是用户预期的目标系统就是需要另作讨论的话题了。
当用户在浏览器当中加载受HTTPS保护的网站时，浏览器实际上只会验证两件事：网站是否提供了证书；证书是不是浏览器信任的根证书CA机构颁发的。实际上我们是在相信每个根CA机构都已尽全力来验证你要连接的服务器的身份。但是实际上有时候根CA机构会被骗。我们还相信每个根CA机构都能够保护自己的系统。但是实际上有时候根CA会被盗用。
有关这些问题的更多细节，请参阅Moxie Marlinspike的博客文章《SSL与真实的未来》。
我们上面提到的Superfish和Privdog有什么问题呢？它们会安装一个新的受信根证书。
请注意这里使用术语“可信”。 我们不是在讨论PGP和GPG应用程序使用的信任网络的任何内容，在PGP中的“可信”是指使用个别密钥的信任级别。 而“受信任的根CA证书”只是可以由客户端软件使用而不产生警告。 它与用户对某事物的“信任”毫无关系。简单来说，有了这个证书，客户端软件就不会发出安全警告提示你证书有问题。
这两个工具都会安装受信的根CA证书，不过好消息是他们的证书都明确写明是来源于Superfish和Privdog。如果有软件要把证书冒充成是由“VeriSign”等大机构发布的，写成“VeriSign.”我们也无法防范。
假定有这样一个场景，有人通过HTTPS访问一家网站（因为要给出诸如用户名和密码这样的敏感信息），装了PrivDog或者Superfish。如果浏览器不对证书合法性作警告，最多也就意味着与用户通讯的系统，获得了受信root CA机构的证书，SuperFish和Privdog就是其中之一。
如果有人想要验证某个证书是否由“真正”的证书机构发布的，比如说想要查看证书发行机构的指纹，所需的步骤在每个浏览器当中也各有不同。有些浏览器，比如微软的IE，如果要查看证书还得先接受该证书，因此即便是安全专家可能也很难判断是不是他想要连接的主机。
Superfish和Privdog这种主机层面的软件仅仅是SSL检查产品的一部分。Dormann发现，许多网络层面的应用和设备也能进行SSL检查。安全网关、防火墙、数据丢失防护（DLP）产品和其他许多应用似乎都加入了SSL检查的大军。当然了，网络管理员要检查受SSL/TLS保护的浏览可能有多种多样的原因，但是很多人可能都没有注意到，那些软件的SSL检查能力还不如浏览器，会带来什么样的安全隐患不言而喻。我们来看看这个图：
在上图的通信过程中，客户端只能验证自己是在与SSL检查软件通信。客户端并不清楚SSL检查软件用了什么技术验证SSL证书。而且更重要的是，SSL检查软件跟目标系统之间还有没有额外的点，客户端无法确定。SSL检查软件跟目标服务器之间是否有攻击者存在？客户端无法知晓。由于这种不透明，客户端只能相信SSL检查软件每一步都做到位了。但很不幸，SSL检查软件并没有。
常见的SSL错误
分析了SSL检查软件之后，Dormann等人总结了这些软件经常犯的一些错误：
1. 上游证书有效性验证不充分
风险：客户端无法知晓所连站点是否合法正规
2. 未告知客户端上游证书验证结果
风险：客户端无法知晓所连站点是否合法正规
3. 证书规范名称字段信息过载
说明：有些SSL检查软件会通过证书的CN字段，试图将上游证书的有效性传递给客户端。比如说，Komodia的SSL Digestor如果验证服务器端提供的证书无效，就会在证书的CN字段开头加上“verify_fail”字样。这个技术其实会带来很多问题。最明显的错误就是传递给用户的错误信息跟证书无效的原因没有关系。
风险：客户端系统的用户可能不知道为什么证书验证没有通过，或者甚至不知道验证没通过。攻击者可以利用主题替代方案名称（SAN）字段令证书认证某一特定域，这样浏览器就不会发出警告。
4. 用应用层反馈证书有效性
说明：有些SSL检查工具会将网页内容（比如HTML）提供给客户端，并描述证书的问题。但客户端软件确定和展示证书的一般机制可能还是会提示证书没有问题。
在很多人印象中，HTTPS就是安全的象征，而为了对这些“安全”的流量进行检查，很多安全产品，包括杀毒软件和防火墙都具备HTTPS检查的功能，通过这样的功能排除其中的安全威胁。然而近日US-CERT却发布了一则预警，TA17-075A，对部分HTTPS检查产品发出安全预警，提到部分SSL/TLS拦截软件未能执行有效验证，或者未能充分传递验证状态，这可能被第三方发动中间人攻击。
US-CERT为什么要发出这个预警呢？让我们来捋一捋最近发生的一些事情。
US-CERT专家发文称SSL检查有风险
首先是2015年初的时候，Superfish和PrivDog这两款SSL检查工具因为没能正确验证SSL引起了US-CERT专家的重视。专家称因为没能正确验证SSL，导致用户系统容易被攻击者进行HTTPS嗅探。
接连几个SSL检查工具被曝存在相似问题后，US-CERT专家Will Dormann决定深入探究这个问题，发表了《SSL检查的风险》一文，其中指出了一些问题：
1. 许多人并不了解SSL和TSL的功能；
2. SSL检查产品比他想象的流行得多；
3. 许多有SSL检查能力的应用都存在一些漏洞，可给用户带来风险；
4. 即便SSL检查做得跟浏览器一样安全，也会给用户带来一定风险。 本文来自无奈人生安全网
下面我们一一来讲。
背景知识
SSL和TLS的目的主要有两个：一是认证与客户端通信的服务器，二是加密客户端与服务器之间发送的数据。有些人可能认为SSL和TLS能够实现端到端加密，这种观点是不对的。SSL和TLS只有在点到点的情况下才能实现安全认证和加密。我们先来看个例子，在本例中的点到点通信也可以被认为是端到端的通信：
客户端能够验证安全通信，但只能和其通信的下一个点进行验证。在上面的例子当中，客户端直接和目标系统建立SSL/TLS连接。客户端软件通过系统上的大量根证书来验证它连接的系统。至于这个系统是不是用户预期的目标系统就是需要另作讨论的话题了。
当用户在浏览器当中加载受HTTPS保护的网站时，浏览器实际上只会验证两件事：网站是否提供了证书；证书是不是浏览器信任的根证书CA机构颁发的。实际上我们是在相信每个根CA机构都已尽全力来验证你要连接的服务器的身份。但是实际上有时候根CA机构会被骗。我们还相信每个根CA机构都能够保护自己的系统。但是实际上有时候根CA会被盗用。 copyright 无奈人生
有关这些问题的更多细节，请参阅Moxie Marlinspike的博客文章《SSL与真实的未来》。
我们上面提到的Superfish和Privdog有什么问题呢？它们会安装一个新的受信根证书。
请注意这里使用术语“可信”。 我们不是在讨论PGP和GPG应用程序使用的信任网络的任何内容，在PGP中的“可信”是指使用个别密钥的信任级别。 而“受信任的根CA证书”只是可以由客户端软件使用而不产生警告。 它与用户对某事物的“信任”毫无关系。简单来说，有了这个证书，客户端软件就不会发出安全警告提示你证书有问题。
这两个工具都会安装受信的根CA证书，不过好消息是他们的证书都明确写明是来源于Superfish和Privdog。如果有软件要把证书冒充成是由“VeriSign”等大机构发布的，写成“VeriSign.”我们也无法防范。
假定有这样一个场景，有人通过HTTPS访问一家网站（因为要给出诸如用户名和密码这样的敏感信息），装了PrivDog或者Superfish。如果浏览器不对证书合法性作警告，最多也就意味着与用户通讯的系统，获得了受信root CA机构的证书，SuperFish和Privdog就是其中之一。
如果有人想要验证某个证书是否由“真正”的证书机构发布的，比如说想要查看证书发行机构的指纹，所需的步骤在每个浏览器当中也各有不同。有些浏览器，比如微软的IE，如果要查看证书还得先接受该证书，因此即便是安全专家可能也很难判断是不是他想要连接的主机。 本文来自无奈人生安全网
Superfish和Privdog这种主机层面的软件仅仅是SSL检查产品的一部分。Dormann发现，许多网络层面的应用和设备也能进行SSL检查。安全网关、防火墙、数据丢失防护（DLP）产品和其他许多应用似乎都加入了SSL检查的大军。当然了，网络管理员要检查受SSL/TLS保护的浏览可能有多种多样的原因，但是很多人可能都没有注意到，那些软件的SSL检查能力还不如浏览器，会带来什么样的安全隐患不言而喻。我们来看看这个图：
在上图的通信过程中，客户端只能验证自己是在与SSL检查软件通信。客户端并不清楚SSL检查软件用了什么技术验证SSL证书。而且更重要的是，SSL检查软件跟目标系统之间还有没有额外的点，客户端无法确定。SSL检查软件跟目标服务器之间是否有攻击者存在？客户端无法知晓。由于这种不透明，客户端只能相信SSL检查软件每一步都做到位了。但很不幸，SSL检查软件并没有。
常见的SSL错误
分析了SSL检查软件之后，Dormann等人总结了这些软件经常犯的一些错误：
1. 上游证书有效性验证不充分 无奈人生安全网
风险：客户端无法知晓所连站点是否合法正规
2. 未告知客户端上游证书验证结果
风险：客户端无法知晓所连站点是否合法正规
3. 证书规范名称字段信息过载
说明：有些SSL检查软件会通过证书的CN字段，试图将上游证书的有效性传递给客户端。比如说，Komodia的SSL Digestor如果验证服务器端提供的证书无效，就会在证书的CN字段开头加上“verify_fail”字样。这个技术其实会带来很多问题。最明显的错误就是传递给用户的错误信息跟证书无效的原因没有关系。
风险：客户端系统的用户可能不知道为什么证书验证没有通过，或者甚至不知道验证没通过。攻击者可以利用主题替代方案名称（SAN）字段令证书认证某一特定域，这样浏览器就不会发出警告。
4. 用应用层反馈证书有效性
说明：有些SSL检查工具会将网页内容（比如HTML）提供给客户端，并描述证书的问题。但客户端软件确定和展示证书的一般机制可能还是会提示证书没有问题。
内容来自无奈安全网