在上图的通信过程中，客户端只能验证自己是在与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访问数据的并不一定是人。客户端可能是用JSON数据跟服务器通信的某个应用。这个问题还可能导致SSL有效性提示不一致。
5. 根据UA HTTP头决定何时验证证书
说明：有些软件会根据客户端提供的UA HTTP头选择性决定验证上游证书的时间。这个技术可能是和上面的步骤一起使用的。
风险：使用这种机制就会导致部分客户端都不能收到证书认证信息。
6. 预警之前建立通信
说明：有些SSL检查工具检测到证书错误后，会先把客户端请求发送到服务器，然后再给用户发警告信息。
风险：攻击者可能可以查看或修改敏感信息。
7. 使用相同根证书
说明：有些SSL检查应用每次安装的时候都使用相同的受信根证书。
风险：攻击者可能获得这些应用的私钥，并且用这个受信根证书来给所有访问网站签名。
Dormann认为，即便SSL检查应用不存在上述任何问题，客户端还是无法获知该应用信任了哪些根证书。使用SSL检查软件将阻碍或者完全阻止客户端成功验证其通信的服务器。
后来Dormann用自己信任的中间人代理虚拟机CERT Tapioca检测，发现有至少58个HTTPS检查工具都存在上述安全问题。
基于上述的研究，来自密歇根大学、伊利诺伊大学厄本那-香槟分校、Mozilla、Cloudflare、Google、加州大学伯克利分校的研究人员决定对外界HTTPS拦截进行全面的研究，量化其流行程度和对现实世界安全的影响。
流量监控研究人员首先对总体流量进行分析，通过三种渠道分别监控来自用户的流量，然后分辨用户是否使用了HTTPS流量监测工具。怎么进行分辨呢？比如有一些安全产品在拦截流量后会修改User-Agent，研究人员进行分析就可以分辨哪些流量经过拦截，哪些没有被拦截。他们发现Firefox更新连接有4.0%遭到拦截，6.2%的电商网站流量被拦截，10.9%的Cloudflare流量被拦截，这比之前估计的比例要高。
A. Firefox更新服务器
相比其他浏览器，Firefox流量被拦截的比例更低，原因就在于Firefox有自带的证书存储，而IE、Chrome、Safari浏览器都使用了系统默认的证书存储空间。因此，有些杀毒软件如Avast不会拦截Firefox的流量。在企业环境中，尽管可以额外在Firefox的证书管理中添加证书，但这还是会增加麻烦，因此很多IT管理员就索性不再拦截Firefox流量。
研究人员还观察到一些地理差异，比如危地马拉有15%的Firefox更新服务器流量被拦截，这比全球的平均比例要高3-4倍，原因是危地马拉的移动运营商COMCEL处理了34.6%的更新流量而运营商对32.9%的流量进行了拦截。格陵兰拦截率排在第二，主要是因为一个名为TELE Greenland的运营商的AS(自治系统)导致的，其中将近一般的流量都被Fortigate中间盒拦截。排名第三的韩国是使用手机最多的国家之一，大量的流量加上运营商AS系统中的拦截导致其拦截率较高。
B. 电商网站