SSL / TLS协议最初是为浏览器开发的，后来成为所有安全Internet通信的事实上的标准。 现在，它用于对部署在云中的虚拟基础架构进行远程管理，用于将客户付款明细从电子商务服务器传输到支付处理器（例如PayPal和Amazon），用于将本地数据发送到云存储，在即时通讯程序中保存对应关系，并在移动应用程序中进行服务器身份验证iOS和Android。

交换高度敏感的信息需要最大的安全性的情况列表非常令人印象深刻。 在本文中，我们将研究在实践中如何确保这些通信的安全性。

-SSL / TLS协议：他们想要最好的...
-...但结果还是一如既往：SSL / TLS证书验证失败的示例
-SSL / TLS协议的逻辑漏洞
-其他常见的SSL / TLS协议实施漏洞
-SSL / TLS协议漏洞的根本原因
-将一勺蜂蜜放在一桶焦油中

SSL / TLS协议：我们想要最好的...

从理论上讲，安全的SSL / TLS协议连接应确保客户端和服务器软件通信的机密性，可靠性和完整性，即使在网络中存在主动的高级攻击者的情况下：当网络完全被敌人占领时，DNS也会中毒，访问点和路由器，交换机WiFi由攻击者控制； 除其他事项外，控制SSL / TLS后端的攻击者。 此外，当客户端软件尝试连接到合法服务器时，攻击者可以更改服务器的网络地址（例如，通过DNS中毒），并且可以将客户端重定向到其恶意服务器，而不是合法服务器。

众所周知，在如此恶劣的条件下，通信的安全性完全取决于建立连接时服务器提供的加密证书的验证是否足够。 包括实现一组密码（ciphersuite）的充分性，客户端和服务器在交换数据时会使用这些密码。 为了使SSL / TLS连接完全安全，客户端软件除其他外，必须仔细验证：

• 当前认证机构签发的证书；
• 有效期尚未到期（或证书尚未被撤销）；
• 证书中列出的名称列表包含您要连接的域。

...但结果还是一如既往：失败的SSL / TLS证书验证示例

但是，在许多对通信安全至关重要的应用程序和库中，验证SSL / TLS证书（甚至是高级验证证书[4] EV-SSL）的过程是完全不成功的。 在所有流行的操作系统中：Linux，Windows，Android和iOS。 在易受攻击的软件，库和中间件服务中，可以区分以下几点[1]：

• Amazon的EC2 Java库和所有基于它的基于云的前端客户端。
• 亚马逊和贝宝（PayPal）的交易SDK，负责将付款细节从站点（部署了在线商务基础设施的站点）传递到支付网关。
• 集成的“购物篮”，例如osCommerce，ZenCart，Ubercart和PrestaShop，它们根本无法验证证书。
• 移动软件用来显示内容相关广告的AdMob代码。
• 接口前端组件ElephantDrive和FilesAnywhere，负责与云存储进行交互。
• Pusher Android库和所有使用Pusher API来控制即时消息传递的软件（例如GitHub的Gaug.es）。
• Apache HttpClient（3.x版）; Apache Libcloud 以及与Apache ActiveMQ服务器的所有客户端连接等。
• Java SOAP中间件服务，包括Apache Axis，Axis 2，Codehaus XFire； 以及基于这些中间件服务构建的所有软件。
• Elastic Load Balancing API工具
• WebSocket的Weberknecht实现。
• 以及所有基于上面列出的库和中间件服务构建的移动软件（要了解什么是中间件服务，请参见图1）； 包括托管服务提供商Rackspace的iOS客户端。

图1.什么是中间件服务

此外，在[2]中，甚至列出了一百多个易受攻击的移动应用程序（见图2）。 包括：Android的Google Cloud Messaging，Angie的列表业务中心密码，AT＆T全球网络客户端，CapitalOne Spark Pay，Cisco OnPlus（远程访问），Cisco技术支持，Cisco WebEx，Cisco WebEx密码，Dominos Pizza，E-Trade，Freelancer ，Google Earth，Huntington Mobile（银行），Intuit Tax在线会计师，iTunes Connect，Microsoft Skype，Oracle Now，Pinterest，SafeNet（VPN客户端），西南航空，Uber，美国银行-Access Online，WesternUnion，WordPress，Yahoo！ 财经，雅虎！ 邮寄

图2.易受攻击的移动应用程序列表中的一小部分

SSL / TLS逻辑漏洞

所有这些软件和许多其他软件的SSL / TLS连接都容易受到广泛的MiTM攻击。 同时，即使没有伪造证书，也没有窃取服务器用于签名证书的私钥，通常也可以进行MiTM攻击。 可以通过仅利用检查客户端软件侧SSL / TLS证书的过程中存在的逻辑漏洞来执行MiTM攻击。 结果，MiTM攻击者可以例如收集授权令牌，信用卡号，名称，地址等。 -来自使用脆弱的付款处理Web应用程序的任何商人。

使用AdMob示例代码将其应用程序连接到AdMob帐户的移动软件供应商也容易受到攻击-他们使攻击者能够捕获凭据并获得对其所有Google服务的访问权限。 例如，由于对Trillian和AIM等信使中证书的验证不正确，MiTM攻击者可以窃取所有Google服务（包括Gmail），Yahoo！的登录凭据。 以及Windows Live服务（包括SkyDrive）。 影响现代非浏览器Web软件的其他漏洞包括：比较主机名时使用不正确的正则表达式； 忽略证书验证结果； 意外或故意关闭验证。 [1]

其他常见的SSL / TLS协议实施漏洞

当然，我们不应该忘记，即使SSL / TLS协议的实施过程中没有逻辑错误（除非有人仍然相信它），也可以通过窃取私钥[12]（使用0day-诸如键盘，浏览器，操作系统，实用程序和固件之类的漏洞[3]； 通过破坏BGP路由[10]； 或通过硬件（参见图3）[8]和/或软件[9]旁路通道攻击SSL / TLS。

图3.硬件旁路上的SSL攻击

此外，攻击者可以执行实际上不可见的MiTM攻击，从而滥用SSLSessionCache类中实现的SSL / TLS会话缓存机制。 该机制仅在初始连接时检查证书的有效性。 从设备删除证书后，它也无法正确取消通信会话。 此外，在重新启动Android设备后（通过“重新启动”或“关闭电源”选项），您可以继续查看某些应用程序的加密流量，这些应用程序在重新启动后并未启动，但在重新启动之前可以正常工作。 因此，例如与谷歌地图发生。 在[2]中，描述了由于这些缓存缺陷，攻击者如何为用户完全透明地设置和删除“隐形证书”，然后与任何应用程序建立网络连接。

图4.易受攻击的加密回顾

SSL / TLS协议实施中的其他常见漏洞包括易受攻击的加密（请参见图4）[5]，GCM重用（Galois /计数器模式；使用Galois身份验证的计数器）[6]，使用CNG的技巧（CryptoAPI-NG） ）在Schannel中（参见图5）[7]，对信任链[2]的不正确验证，对主机名[11]的不正确验证。

图5. CNG技巧：从Schannel中获取秘密

对信任链的不正确验证是一种情况，其中Web应用程序绝对接受任何指示正确主机名的证书，而不检查与它签名的证书颁发机构。 这使您可以拦截和解密密码和/或信用卡号。 甚至在某些情况下还会注入恶意代码。 在Android软件中，例如，当创建自定义的X509TrustManger接口而忽略CertificateException异常时，此漏洞会渗透。 或当软件开发人员将对SslErrorHandler.proceed（）方法的调用插入WebViews组件的代码中时。 [2]

不正确的主机名验证是一种情况，当Web应用程序接受证书而未确保此证书来自的主机在受信任的主机列表中时。 在Android软件中，例如，当创建HostnameVerifier接口时，此漏洞就会渗透，该接口在任何情况下都将返回TRUE。 或当软件开发人员将对SslErrorHandler.proceed（）方法的调用插入WebViews组件的代码中时。 [2]

SSL / TLS协议漏洞的根本原因

这些漏洞中绝大多数的根本原因是SSL / TLS库（包括JSSE，OpenSSL和GnuTLS）的API设计糟糕。 以及同样糟糕的数据传输库设计（例如cURL，Apache HttpClient和urllib），每一个都是SSL / TLS库的高级包装。 更不用说中间件服务（例如Apache Axis，Axis 2或Codehaus XFire），它们甚至是更高级别的包装程序，它们进一步增加了可怕设计的“雪球”。 这些API不是从他从SSL / TLS协议实现的低级细节中抽象出来的语言（就机密性和身份验证）与他所理解的语言（通常是远离系统编程）进行对话（通常远离系统编程），而是将这些API转储给可怜的家伙一堆低级SSL / TLS参数对他来说是不可理解的。 他们需要高级软件才能正确公开低级选项。 实现主机名验证功能，并负责解释低级操作返回的值。

结果，应用程序开发人员错误地使用了SSL / TLS API：他们错误地解释了其参数，选项，副作用和返回值的多样性。 例如[1]：

• 亚马逊的Flexible Payments Service PHP库尝试通过将CURLOPT_SSL_VERIFYHOST参数设置为TRUE（在cURL库中）来启用主机名验证。 但是，此参数的正确默认值为2；默认值为2。 如果您将其分配为TRUE，则对于分配了值1的开发人员，此参数是不可见的，依此类推。 证书验证已禁用。
• PHP库PayPal Payments Standard-遇到相同的错误； 此外，在先前的易受攻击的实施方式进行更新时（即，删除了一个错误，添加了另一个错误）。
• 另一个示例是Lynx，这是一种面向文本的浏览器。 它验证自签名证书-但仅当GnuTLS证书验证功能返回负值时。 但是，对于某些错误，此函数返回0；否则，返回0。 包括证书由不受信任的机构签署的情况。 因此，Lynx中的信任链已断开。

此外，应用程序开发人员经常误解了特定SSL / TLS库提供什么样的安全保证。 因此，在野外，可能会遇到一些临床情况，即在根本上需要安全通信（例如与支付处理器进行交互）的应用程序中，使用了一个SSL / TLS库，该库根本不检查SSL / TLS证书。 更平淡无奇，但更具杀伤力的情况是，任何中间软件层的开发人员都默默地禁用了检查SSL / TLS证书的过程（例如，他可以这样做来测试系统，而在测试之后忘记重新启用它）。 同时，使用此中间层的高级程序代码可确保执行证书验证。 T.O. SSL / TLS错误通常一次隐藏在一个或几个中间层库的深度中，这使得几乎不可能检测到此问题。

例如，在JSSE（Java安全套接字扩展）中，如果SSL客户端中的“ algorithm”字段设置为NULL或为空字符串，而不是HTTPS，则SSLSocketFactory API扩展接口将无提示地跳过检查主机名。 尽管JSSE参考指南中提到了这一事实，但是许多Java SSL协议实现都使用SSLSocketFactory而不执行主机名验证...

一汤匙蜂蜜在每桶焦油中

因此，实际上，事实证明，在大多数现代的非浏览器Web软件中，SSL / TLS证书的验证要么完全被禁用，要么被错误地实施。 图7显示了当前SSL / TLS协议漏洞的分类。 上面已经描述和/或提到了其中一些漏洞，但不是全部。 您可以通过阅读参考书目中列出的材料来熟悉所提到的但未描述的漏洞。

图6.与SSL / TLS相关的漏洞的分类

嗯，要在焦油桶中加入一小勺蜂蜜，值得注意的是，在[1]中已参考RFC详细/清晰/流行/胜任地描述了SSL的实现方式。 我们从来没有遇到过更好的描述，它在技术上是准确的，同时也是可以理解的。 同样在[1]中，分析了最常见的SSL库，并根据抽象级别（低级别/高级别）进行了分类。 全部带有伪代码的图表和简洁的算法。 详细描述了特定产品的漏洞，其中包含错误代码和错误代码。 因此，如果突然有人再次希望创建SSL / TLS框架的实现，这是“他们想要最好的，但结果却一如既往”的说法的例外，那么[1]就是一个理想的开始。