1、不安全的SSL：过于广泛的信任证书

证书颁发机构（CA）为每个公开密钥发放一个数字证书，证书对于通用网络通信工具是必需的，而盗用证书颁发机构的数量正在不断增加，这导致即使由CA签名的证书也可能是恶意的，当程序默认接受由CA颁发的证书而屏蔽了安全校验逻辑，拥有盗用证书的攻击者可能会拦截这些CA的SSL/TLS信息流进行中间人攻击。本文以JAVA语言源代码为例，分析“不安全的SSL：过于广泛的信任证书”缺陷产生的原因以及修复方法。详见 CWE ID 297: Improper Validation of Certificate with HostMismatch (http://cwe.mitre.org/data/definitions/297.html)。

2、“不安全的SSL：过于广泛的信任证书”的危害

基于恶意证书提供给相关系统的信任可能允许欺骗或重定向攻击。从2018年1月至2019年9月，CVE中共有3条漏洞信息与其相关。漏洞如下：

CVE
概述

CVE-2019-13050
sks-keyserver 代码通过 SKS 1.2.0 密钥服务器网络和 GnuPG 2.2.16 之间的交互，使得 GnuPG 密钥服务器配置引用SKS密钥服务器网络上的主机存在风险。由于证书垃圾邮件攻击，从此网络检索数据可能会导致持续拒绝服务。

CVE-2018-10936
在版本42.2.5之前的postgresql-jdbc中发现了一个弱点。如果未向驱动程序提供主机名验证程序，则可以提供SSL工厂而不检查主机名。这可能导致攻击者可以为错误的主机提供证书而伪装成可信服务器的情况，只要它拥有可信CA签名即可。

3、示例代码

3.1 缺陷代码

上述代码是建立URL连接并读取连接的输入流数据。在代码行第22行按照字符串的内容创建URL对象，第23行调用 openConnection() 方法返回一个URLConnection实例，该实例表示URL引用的远程对象连接。第24~29行读取连接的输入流内容。代码中使用默认的 URLConnection 建立了 SSL/TLS连接，URLConnection所使用的 SSLSocketFactory 未进行处理，它对Android默认密钥库中存在的所有CA签名的证书将全部信任。

使用代码卫士对上述示例代码进行检测，可以检出“不安全的SSL：过于广泛的信任证书”缺陷，显示等级为高，从跟踪路径中可以分析出数据的污染源以及数据流向。在代码行第23报出缺陷，如图1所示：

图1：“不安全的SSL：过于广泛的信任证书”检测示例

3.2 修复代码

在上述修复代码中，在第29行返回了指定为TLS协议的安全套接字对象sslContext，第30行初始化 sslContext 对象，第33行设置连接对象的套接字工厂为基于TLS协议的安全套接字工厂。以上操作使用了基于安全套接字的类，借助这些类可以使用相关的安全协议进行通信，能可靠地检测网络字节流中的错误，并且可以选择对数据进行加密或对通信进行身份验证。使用代码卫士对修复后的代码进行检测，可以看到已不存在“不安全的SSL：过于广泛的信任证书”缺陷。如图2所示：

4、如何避免“不安全的SSL：过于广泛的信任证书”

不要直接使用默认的 URLConnection 建立 SSL/TLS连接，建议使用HttpsURLConnection 进行替代，并对证书进行判断和处理。

文章原文链接:https://www.anquanke.com/post/id/186597