在检查Firefox流量时，研究人员调查了处理100K个连接的AS系统中拦截率最高、设备指纹出现次数最多的前25个。其中发现的机构包括金融公司、政府部门和教育机构。除了一家银行以外，前25个AS中24个都降低了安全性。12个使用了出口级的密码套件，可能被中间人攻击。
存在问题的安全产品和厂商如下图：
在论文结尾，研究人员针对目前HTTPS拦截的现状提出了几点意见：
安全社区需要达成共识我们需要社区共识。安全社区对是否应该允许HTTPS拦截几乎没有共识。一方面，Chrome和Firefox通过允许本地安装根证书绕过限制。而与此同时，采用新的协议特征来进行更安全的拦截的讨论又在IETF这样的标准化小组里遭到了大量反对。
想要找到长久有效的解决方案，安全社区必须要在“拦截检查是否合理”这一问题上达成共识。
应该考虑验证发生的环节许多HTTPS安全功能希望通过混合HTTP和TLS层来实现端到端的连接，并通过在浏览器代码中实现HTTPS功能，而不是在TLS库中。例如，为了克服现有吊销证书协议的弱点，Firefox有OneCRL机制，而Chrome有CRLSets。这两种解决方案都能在典型的端到端情况下增加浏览器的安全性。然而，这些解决方案在TLS代理的存在下不提供任何保护，并且由于该解决方案不是TLS协议本身的一部分，所以TLS库不实现这些安全检查。比如，HPKP指令通过HTTP传递，而不是在TLS握手期间传递。浏览器无法对代理连接执行HPKP验证，因为它们无法访问目标证书，而代理又不会不执行验证。虽然代理有能力执行额外的验证，但却没有验证。而且在许多情况下，厂商的精力都花费在正确部署现有TLS库上，更不用说实现其他安全功能了。
如果我们希望浏览器执行额外的验证，那么代理就需要一种将连接详细信息（即服务器证书和加密参数）传递给浏览器的机制。如果要代理执行此验证，我们需要在TLS中标准化这些验证步骤，并使用流行的库。但是现在的情况是最糟糕的——任何一方都不执行严格的验证机制。
加密库需要提供安全的默认值几个代理部署了经过很少修改定制的TLS库。但这些库的默认设置是有安全问题的。默认情况下，客户端库和Web服务器应该优先考虑使其产品安全。OpenSSL最近决定删除已知的密码密码套件，这样的行为就值得赞赏。OpenSSL十年前就应该这么做了。我们的社区应该继续将默认选项限制为已经被证明安全的配置。
防毒软件供应商应该重新考虑拦截HTTPS防病毒软件在本地运行，可以访问本地文件系统，浏览器内存以及通过HTTPS加载的任何内容。由于他们可能会将TLS错误配置和RCE漏洞，我们强烈建议防病毒提供商重新考虑是否拦截HTTPS。
安全公司忽略了安全问题我们希望通过披露现有产品的漏洞，我们可以鼓励厂商修补问题。希望企业优先考虑其TLS实施的安全性，并考虑HTTPS生态系统发展的步伐以及是否能够跟上必要的更新。
不要依赖客户端配置客户端和服务器端都需要选择安全参数，而不是依靠一方来维持安全性。
管理员需要测试中间盒鼓励部署代理的管理员使用诸如Qualys SSL Lab的客户端测试https://howsmyssl.com和https://badssl.com等网站来测试其配置。
安全厂商应该更负责正是在Google研究人员发布报告后，美国计算机应急响应小组(US-CERT)加入了声浪。
US-CERT称，“HTTPS检查会削弱TLS的安全性，”而且告诉企业，如果他们需要对HTTPS进行审查，他们应该保证产品会“执行正确的TLS证书验证”。
“由于HTTPS审查会管理协议、密钥、证书，因此产品应该要执行必要的HTTPS验证。”US-CERT的警告中称。
不过也有安全专家表达了不同的看法，安全专家David Holmes在SecurityWeek发表文章，指责发布论文的研究人员。他认为拦截HTTPS的首要目标是防范恶意软件。的确，很多企业会用到HTTPS拦截检查，因为无论是现在还是将来，他们的首要威胁都是恶意软件。很多恶意软件已经开始使用HTTPS来规避检测，因此要检查恶意软件别无他法。