目录

十四章

14.1 本章学习的内容

14.2 什么是 SSL/TLS

14.2.1 Alice 在 Bob 书店买书

14.2.2 客户端与服务器

14.2.3 АSSL/TLS 承载HTTP

14.2.4 SSL/TLS的工作

14.2.5 SSL/TLS也可以保护其他的协议

14.2.6 密码套件

14.2.7 SSL 与 TLS 的区别

14.3 使用 SSL/TLS 进行通信

14.3.1 层次化的协议TLS 协议

        1 TLS 记录协议

        2 TLS 握手协议

        2-1 握手协议

        2-2 密码规格变更协议

        2-3 警告协议

        2-4 应用数据协议应用数据协议

14.3.2 1 TLS 记录协议

14.3.3         2-1 握手协议

        (1) ClientHello （客户端→服务器）

(2) ServerHello (客户端←服务器)

(3) Certificate (客户端←服务器)

(4) ServerKeyExchange (客户端←服务器)

(5) CertificateRequest (客户端←服务器)

(6) ServerHelloDone (客户端←服务器)

(7) Certificate (客户端→服务器)

(8) ClientKeyExchange (客户端→服务器）

        小测验 1 预备主密码的加密                （答案见 14.7 节）

(9) CertificateVerify (客户端→服务器)

(10) ChangeCipherSpec (客户端→服务器)

(11) Finished (客户端→服务器)

(12) ChangeCipherSpec (客户端一服务器)

(13) Finished (客户端←服务器)

(14)切换至应用数据协议

14.3.4 2-2密码规格变更协议

14.3.5 2-3 警告协议

14.3.6 2-4应用数据协议

14.3.7 主密码

主密码的计算

主密码的目的

14.3.8 TLS中使用的密码技术小结

14.4 对SSL/TLS的攻击

14.4.1 对各个密码技术的攻击

14.4.2 OpenSSL 的心脏出血漏洞

14.4.3 SSL 3.0 的漏洞与 POODLE 攻击

14.4.4 FREAK攻击与密码产品出口管制

14.4.5 对伪随机数生成器的攻击

14.4.6 利用证书的时间差进行攻击

14.5 SSL/TLS用户的注意事项

14.5.1 不要误解证书的含义

14.5.2 密码通信之前的数据是不受保护的

14.5.3 密码通信之后的数据是不受保护的

14.6 本章小结

        小测验2 SSL/TLS的基础知识                        （答案见 14.7 节）

14.7 小测验的答案

        小测验 1 的答案：预备主密码的加密                （14.3.3 节）

        小测验 2 的答案: SSL/TLS的基础知识                （14.6 节）

---

十四章

14.1 本章学习的内容

        本章中我们将学习SSL/TLS的相关知识。

        SSL/TLS 是世界上应用最广泛的密码通信方法。比如说，当在网上商城中输入信用卡号时，我们的 Web 浏览器就会使用 SSL/TLS 进行密码通信。使用 SSL/TLS 可以对通信对象进行认证，还可以确保通信内容的机密性。

        本章首先将介绍一些 SSL/TLS 的运用场景，然后再介绍使用 SSL/TLS 的通信步骤和攻击方法。

        SSL/TLS 中综合运用了本书中所学习的对称密码、消息认证码、公钥密码、数字签名、伪随机数生成器等密码技术,大家可以在阅读本章内容的同时对这些技术进行复习。严格来说,SSL ( Secure Socket Layer)与TLS ( Transport Layer Security )是不同的, TLS 相当于是SSL 的后续版本。不过，本章中所介绍的内容，大多是 SSL 和 TLS两者兼备的，因此除具体介绍通信协议的部分以外，都统一写作 SSL/TLS。

        SSL/TLS 是一种在 Web 服务器中广泛使用的协议，在现代 Web 技术中具有极其重要的意义。因此, IPA密码技术评估项目CRYPTREC在平衡SSL/TLS的安全性和可用性(互联性)的基础上，发布了一份 SSL/TLS 服务器配置方法——《SSL/TLS 密码配置指南》。

14.2 什么是 SSL/TLS

        和之前一样,我们还是通过 Alice 和 Bob 的故事来看一看 SSL/TLS 的运用场景。

14.2.1 Alice 在 Bob 书店买书

        Bob 书店是 Alice 经常光顾的一家网店，因为在 Bob 书店她可以搜索到新出版的图书，还可以通过信用卡快速完成支付,购买的书还能快递到家,真的很方便。

        有一天，Alice 读了一本关于网络信息安全的书，书上说“互联网上传输的数据都是可以被窃听的”。Alice感到非常担心，自己在购买新书的时候输入的信用卡号会不会被窃听呢?

        Alice看到 Bob书店的网站下面写着一行字:“在以 https://开头的网页中输入的信息将通过SSL/TLS 发送以确保安全”。

        的确,输入信用卡号的网页的URL是以https://开头的,而不是一般的http://。此外,在浏览这个网页时, Alice的Web浏览器上还会显示一个小锁头的图标,看上去好像挺安全的。

        但 Alice心想，就算写着“通过 SSL/TLS发送”我也不放心啊，到底在我的Web浏览器和Bob 书店的网站之间都发生了哪些事呢？

        本章将要介绍的技术--SSL/TLS就可以解答Alice的疑问。当进行SSL/TLS通信时，Web 浏览器上就会显示一个小锁头的图标。

14.2.2 客户端与服务器

        首先，我们将Alice和Bob书店的通信过程整理成示意图(图14-1)。     

        Alice 和 Bob 书店之间的通信，实际上是 Alice 所使用的 Web 浏览器和 Bob 书店的 Web 服务器之间的通信。Web 浏览器是 Alice 的计算机上运行的一个程序，而 Web 服务器则是在 Bob书店的计算机上运行的一个程序,它们都遵循一种叫作 HTTP ( HyperText Transfer Protocol,超文本传输协议）的协议（protocol）来进行通信。其中，Web 浏览器称为 HTTP 客户端，Web 服务器称为 HTTP 服务器。

        当Alice点击网页上的链接或者输入URL时, Web浏览器就会通过网络向Web服务器发送一个“我要浏览这个网页”的请求(request)。

        Web 服务器则将请求的网页内容发送给Web浏览器，以便对请求作出响应(response)。服务器和客户端之间所进行的处理就是请求和响应的往复。HTTP可以认为是在HTTP客户端与HTTP 服务器之间进行请求和响应的规范。

        Alice向Bob书店发送信用卡号也是使用HTTP来完成的(图14-2)。 Alice输入信用卡号之   后按下提交按钮，这时客户端（Web 浏览器）就会将信用卡号作为 HTTP请求发送给服务器。服务器则会将“生成订单”的网页作为HTTP响应返回给客户端。

        不过，如果直接发送请求的话，信用卡号就很可能被窃听。下一节我们将探讨针对这种风险的对策。

14.2.3 АSSL/TLS 承载HTTP

        当 Web 浏览器发送信用卡号时，信用卡号的数据会作为客户端请求发送给服务器。如果通信内容被窃听者 Eve所窃取, Eve就会得到信用卡号。

        于是，我们可以用 SSL (Secure Socket Layer） 或者 TLS (Transport Layer Security)作为对通信进行加密的协议,然后在此之上承载HTTP (图14-3)。通过将两种协议进行叠加,我们就可以对HTTP的通信(请求和响应)进行加密,从而防止窃听。通过SSL/TLS进行通信时,1URL不是以http://开头,而是以https://开头。

        以上就是SSL/TLS的简单介绍。

14.2.4 SSL/TLS的工作

       在大致了解了SSL/TLS之后,我们来整理一下SSL/TLS到底负责哪些工作。我们想要实现的是通过本地的Web浏览器访问网络上的Web服务器,并进行安全的通信。用本章开头的例子来说就是, Alice希望通过Web 浏览器向 Bob书店发送信用卡号。在这里，我们有几个必须要解决的问题。

        (1) Alice 的信用卡号和地址在发送到 Bob 书店的过程中不能被窃听。

        (2) Alice的信用卡号和地址在发送到Bob书店的过程中不能被篡改。

        (3)确认通信对方的 Web 服务器是真正的Bob书店。

        在这里，(1)是机密性的问题，(2)是完整性的问题，而(3)则是认证的问题。

        为了解决这些问题，让我们在密码学家的工具箱中找一找。

        要确保机密性,可以使用对称密码。由于对称密码的密钥不能被攻击者预测,因此我们使用伪随机数生成器来生成密钥。若要将对称密码的密钥发送给通信对象,可以使用公钥密码或者 Diffie-Hellman 密钥交换。

        要识别篡改,对数据进行认证,可以使用消息认证码。消息认证码是使用单向散列函数来实现的。

        要对通信对象进行认证,可以使用对公钥加上数字签名所生成的证书。

        好，工具已经找齐了，下面只要用一个“框架”(framework)将这些工具组合起来就可以了。SSL/TLS 协议其实就扮演了这样一种框架的角色。

14.2.5 SSL/TLS也可以保护其他的协议

        刚才我们提到用SSL/TLS承载HTTP通信,这是因为HTTP是一种很常用的协议。其实SSL/TLS 上面不仅可以承载 HTTP，还可以承载其他很多协议。例如，发送邮件时使用的 SMTP( Simple Mail Transfer Protocol,简单邮件传输协议)和接收邮件时使用的POP3 (Post OfficeProtocol,邮局协议)都可以用SSL/TLS进行承载。在这样的情况下, SSL/TLS就可以对收发的邮件进行保护。

        用 SSL/TLS 承载 HTTP、SMTP 和 POP3 的结构如图 14-4 所示。一般的电子邮件软件都可以完成发送和接收邮件这两种操作,其实是同时扮演了SMTP客户端和POP3客户端这两种角色。

14.2.6 密码套件

        SSL/TLS提供了一种密码通信的框架,这意味着SSL/TLS中使用的对称密码、公钥密码、数字签名、单向散列函数等技术，都是可以像零件一样进行替换的。也就是说，如果发现现在所使用的某个密码技术存在弱点,那么只要将这一部分进行替换就可以了。

        尽管如此，也并不是说所有的组件都可以自由选择。由于实际进行对话的客户端和服务器必须使用相同的密码技术才能进行通信,因此如果选择过于自由,就难以确保整体的兼容性。为此, SSL/TLS就像事先搭配好的盒饭一样,规定了一些密码技术的“推荐套餐”,这种推荐套餐称为密码套件(cipher suite)。

14.2.7 SSL 与 TLS 的区别

        本章中我们是将 SSL 和 TLS 作为一个整体（SSL/TLS)来对待的。

        SSL (Secure Socket Layer，安全套接层)是 1994年由网景（Netscape)公司设计的一种协议,并在该公司的Web浏览器Netscape Navigator中进行了实现。随后,很多Web浏览器都采用了这一协议，使其成为了事实上的行业标准。SSL已经于 1995 年发布了 3.0 版本，但在2014年， SSL 3.0 协议被发现存在可能导致POODLE攻击(14.4.3 节)的安全漏洞(CVE-20143566)，因此SSL3.0 已经不安全了。

        TLS ( Transport Layer Security,传输层安全)是IETF在SSL 3.0的基础上设计的协议。在1999年作为RFC 2246发布的TLS 1.0,实际上相当于SSL 3.1。

        2006 年，TLS 1.1 以 RFC 4346 的形式发布，这个版本中增加了针对 CBC 攻击的对策，并加入了AES对称密码算法。TLS 1.2 中新增了对 GCM (8.5 节)、CCM认证加密(AuthenticatedEncryption)的支持，此外还新增了 HMAC-SHA256，并删除了 IDEA 和 DES，将伪随机函数(PRF )改为基于SHA-256来实现。

14.3 使用 SSL/TLS 进行通信

        下面我们来介绍一下使用SSL/TLS进行通信的步骤。对技术细节不感兴趣的读者,可以直接跳到14.4节。顺便提一下,本节的内容是基于TLS 1.2 (RFC5246)编写的,因此我们不使用SSL/TLS这一名称，而是直接写作 TLS。

14.3.1 层次化的协议TLS 协议

        是由 TLS 记录协议(TLS record protocol )和 TLS 握手协议(TLS handshakeprotocol)这两层协议叠加而成的。位于底层的TLS 记录协议负责进行加密，而位于上层的TLS握手协议则负责除加密以外的其他各种操作。上层的TLS握手协议又可以分为4个子协议。TLS协议的层次结构如图14-5所示。

下面我们先来简单介绍一下其中各个协议的功能。

        1 TLS 记录协议

        TLS 记录协议位于 TLS 握手协议的下层，是负责使用对称密码对消息进行加密通信的部分。

        TLS 记录协议中使用了对称密码和消息认证码，但是具体的算法和共享密钥则是通过后面将要介绍的握手协议在服务器和客户端之间协商决定的。

        2 TLS 握手协议

        TLS 握手协议分为下列 4个子协议：握手协议、密码规格变更协议、警告协议和应用数据协议。下面我们按顺序逐一介绍。

        2-1 握手协议

        握手协议是 TLS 握手协议的一部分，负责在客户端和服务器之间协商决定密码算法和共享密钥。基于证书的认证操作也在这个协议中完成。它是4个子协议中最复杂的一个。

        这个协议大致相当于下面这段对话。

        客户端: “你好。我能够理解的密码套件有RSA/3DES,或者DSS/AES,请问我们使用哪一种密码套件来通信呢？”

        服务器：“你好。我们就用 RSA/3DES 来进行通信吧，这是我的证书。”

        在服务器和客户端之间通过握手协议协商一致之后，就会相互发出信号来切换密码。负责发出信号的就是下面要介绍的密码规格变更协议。

        2-2 密码规格变更协议

        密码规格变更协议是TLS握手协议的一部分,负责向通信对象传达变更密码方式的信号。简单地说,就跟向对方喊“1、2、3!”差不多。

        这个协议所发送的消息，大致相当于下面的对话。

        客户端：“好，我们按照刚才的约定切换密码吧。1、2、3！”

        当协议中途发生错误时，就会通过下面的警告协议传达给对方。

        2-3 警告协议

        警告协议是 TLS 握手协议的一部分。警告协议负责在发生错误时将错误传达给对方。这个协议所发送的消息，大致相当于下面的对话。

        服务器: “刚才的消息无法正确解密哦!”

        如果没有发生错误，则会使用下面的应用数据协议来进行通信。

        2-4 应用数据协议应用数据协议

        是TLS握手协议的一部分。应用数据协议是将TLS上面承载的应用数据传达给通信对象的协议。

        下面我们按照相同的顺序,更加详细地介绍一下TLS协议。

14.3.2 1 TLS 记录协议

        TLS 记录协议负责消息的压缩、加密以及数据的认证，其处理过程如图 14-6 所示。

        首先，消息被分割成多个较短的片段（fragment），然后分别对每个片段进行压缩。压缩算法需要与通信对象协商决定。

        接下来,经过压缩的片段会被加上消息认证码,这是为了保证完整性,并进行数据的认证。通过附加消息认证码的 MAC值，可以识别出篡改。与此同时，为了防止重放攻击，在计算消息认证码时,还加上了片段的编号。单向散列函数的算法,以及消息认证码所使用的共享密钥都需要与通信对象协商决定。

        再接下来,经过压缩的片段再加上消息认证码会一起通过对称密码进行加密。加密使用CBC 模式，CBC模式的初始化向量(IV)通过主密码(master secret)(14.3.7 节)生成，而对称密码的算法以及共享密钥需要与通信对象协商决定。

        最后，上述经过加密的数据再加上由数据类型、版本号、压缩后的长度组成的报头(header)就是最终的报文数据。其中,数据类型为TLS记录协议所承载的4个子协议(握手协议、密码规格变更协议、警告协议、应用数据协议）的其中之一。

14.3.3         2-1 握手协议

        握手协议是 TLS 握手协议的一部分，负责生成共享密钥以及交换证书。其中，生成共享密钥是为了进行密码通信，交换证书是为了通信双方相互进行认证。

        握手协议这一名称中的“握手”(handshake)，是服务器和客户端在密码通信之前交换一些必要信息这一过程的比喻。

        由于握手协议中的信息交换是在没有加密的情况下进行的（即使用“不加密”这一密码套件），也就是说，在这一协议中所收发的所有数据都可能被窃听者 Eve 窃听，因此在这一过程中必须使用公钥密码或者 Diffie-Hellman 密钥交换。

        握手协议的过程如图14-7所示。

        下面我们来详细讲解握手协议中所交换的消息。为了便于大家理解,我们以人类对话的形式来描述客户端和服务器之间的信息交换。

        (1) ClientHello （客户端→服务器）

        客户端向服务器发送 ClientHello 消息。

        客户端: “你好。我能理解的密码套件有RSA/3DES,或者 DSS/AES,请问我们使用哪一种密码套件进行通信呢？”

        关于 ClientHello 具体发送了怎样的字节序列，在 SSL/TLS 协议规范中是有定义的，但本书中不会涉及这些内容。简单来说,客户端会向服务器发送下列信息。

        ⚪可用的版本号

        ⚪当前时间

        ⚪客户端随机数

        ⚪会话 ID

        ⚪可用的密码套件清单

        ⚪可用的压缩方式清单

        为什么要发送“可用的版本号”“可用的密码套件清单”和“可用的压缩方式清单”呢？因为不同的客户端（Web浏览器)所支持的方式不同，具体使用哪一种方式来通信，需要和服务器进行协商。

        “当前时间”在基本的 TLS 中是不使用的，但上层协议中有可能会使用这一信息。“客户端随机数”是一个由客户端生成的不可预测的随机数，我们在后面的步骤中需要用到它。

        “会话 ID”是当客户端和服务器希望重新使用之前建立的会话（通信路径）时所使用的信息。

(2) ServerHello (客户端←服务器)

        对于客户端发送的ClientHello消息,服务器会返回一个ServerHello消息。

        服务器: “你好。我们就用RSA/3DES来进行通信吧。”

        服务器会将下列信息随ServerHello消息一起发送出去。

        ⚪使用的版本号当

        ⚪ 前时间

         ⚪服务器随机数

        ⚪会话 ID

        ⚪使用的密码套件

        ⚪使用的压缩方式

        服务器根据客户端在 ClientHello 消息中发送过来的信息确定通信中使用的“版本号”“密码套件”和“压缩方式”。

        “当前时间”在基本的TLS中是不使用的,但上层协议中有可能会使用这一信息。

        “服务器随机数”是一个由服务器生成的不可预测的随机数。这个随机数必须与客户端生成的随机数无关，我们在后面的步骤中需要用到它。

(3) Certificate (客户端←服务器)

        服务器发送 Certificate 消息。

        服务器：“好，这是我的证书。”

        通过Certificate消息,服务器会向客户端发送下列信息。

        证书清单

        证书清单是一组 X.509v3 证书序列，首先发送的是服务器(发送方)的证书，然后会按顺序发送对服务器证书签名的认证机构的证书。

        客户端会对服务器发送过来的证书进行验证。当以匿名方式通信时,不发送Certificate消息。

(4) ServerKeyExchange (客户端←服务器)

        服务器发送ServerKeyExchange消息。 

        服务器: “我们用这些信息来进行密钥交换吧。”

        当Certificate消息不足以满足需求时,服务器会通过ServerKeyExchange消息向客户端发送一些必要信息。具体所发送的信息内容会根据所使用的密码套件而有所不同。

        当不需要这些信息时，将不会发送 ServerKeyExchange 消息。

(5) CertificateRequest (客户端←服务器)

        服务器发送CertificateRequest消息。

        服务器：“对了，请给我看一下你的证书吧。”

        CertificateRequest消息用于服务器向客户端请求证书,这是为了进行客户端认证。通过这一消息，服务器会向客户端发送下列信息。

       ⚪ 服务器能够理解的证书类型清单

        ⚪服务器能够理解的认证机构名称清单

        当不使用客户端认证时,不会发送CertificateRequest消息。

(6) ServerHelloDone (客户端←服务器)

        服务器发送ServerHelloDone消息。

        服务器：“问候到此结束。”

        这一消息表示从 ServerHello 消息开始的一系列消息的结束。

(7) Certificate (客户端→服务器)

        客户端发送Certificate消息。

        客户端：“这是我的证书。”

        当步骤（5) 中服务器发送了 CertificateRequest 消息时，客户端会将自己的证书同 Certificate消息一起发送给服务器。

        服务器读取客户端的证书并进行验证。

        当服务器没有发送 CertificateRequest 消息时，客户端不会发送 Certificate 消息。

(8) ClientKeyExchange (客户端→服务器）

        客户端发送 ClientKeyExchange 消息。

        客户端：“这是经过加密的预备主密码。”

        当密码套件中包含 RSA 时，会随 ClientKeyExchange 消息一起发送经过加密的预备主密码。当密码套件中包含Diffie-Hellman密钥交换时，会随 ClientKeyExchange 消息一起发送 Diffie-Hellman 的公开值。

        预备主密码（pre-master secret）是由客户端生成的随机数，之后会被用作生成主密码的种子。这个值会在使用服务器的公钥进行加密后发送给服务器。预备主密码的生成方法我们将稍后介绍。

        根据预备主密码，服务器和客户端会计算出相同的主密码，然后再根据主密码生成下列比特序列（密钥素材）。

        ⚪对称密码的密钥

         ⚪消息认证码的密钥

         ⚪对称密码的CBC模式中使用的初始化向量(IV)

        小测验 1 预备主密码的加密                （答案见 14.7 节）

        客户端是用服务器的公钥对预备主密码进行加密的，那么客户端又是什么时候得到服务器的公钥的呢？

(9) CertificateVerify (客户端→服务器)

        客户端发送CertificateVerify消息。

        客户端: “我确实是客户端证书的持有者本人。”

        客户端只有在服务器发送CertificateRequest消息时才会发送CertificateVerify消息。这个消息的目的是向服务器证明自己的确持有客户端证书的私钥。

        为了实现这一目的，客户端会计算“主密码”和“握手协议中传送的消息”的散列值，并加上自己的数字签名后发送给服务器。

(10) ChangeCipherSpec (客户端→服务器)

        客户端发送ChangeCipherSpec消息。

        客户端：“好，现在我要切换密码了。”

        实际上, ChangeCipherSpec消息并不是握手协议的消息,而是密码规格变更协议的消息。在 ChangeCipherSpec 消息之前，客户端和服务器之间已经交换了所有关于密码套件的信息,因此在收到这一消息时,客户端和服务器会同时切换密码。

        在这一消息之后，TLS 记录协议就开始使用双方协商决定的密码通信方式了。

(11) Finished (客户端→服务器)

        客户端发送 Finished 消息。

        客户端：“握手协议到此结束。”

        由于已经完成了密码切换，因此 Finished 消息是使用切换后的密码套件来发送的。实际负责加密操作的是 TLS 记录协议。

        Finished 消息的内容是固定的，因此服务器可以将收到的密文解密，来确认所收到的Finished 消息是否正确。通过这一消息，就可以确认握手协议是否正常结束，密码套件的切换是否正确。

(12) ChangeCipherSpec (客户端一服务器)

        这次轮到服务器发送 ChangeCipherSpec 消息了。

        服务器：“好，现在我要切换密码了。”

(13) Finished (客户端←服务器)

        和客户端一样，服务器也会发送 Finished 消息。

        服务器：“握手协议到此结束。”

        这一消息会使用切换后的密码套件来发送。实际负责加密操作的是 TLS 记录协议。

(14)切换至应用数据协议

        在此之后,客户端和服务器会使用应用数据协议和TLS记录协议进行密码通信。

        从结果来看，握手协议完成了下列操作。

        ⚪客户端获得了服务器的合法公钥,完成了服务器认证

        ⚪服务器获得了客户端的合法公钥,完成了

        ⚪客户端认证(当需要客户端认证时)

        ⚪客户端和服务器生成了密码通信中使用的共享密钥

        ⚪客户端和服务器生成了消息认证码中使用的共享密钥

        在 4 个子协议中，握手协议是最复杂的，下面我们来看看剩下的 3 个子协议。

14.3.4 2-2密码规格变更协议

        TLS的密码规格变更协议( change cipher spec protocol )是 TLS 握手协议的一部分,用于密码切换的同步。

        那么为什么这个协议不叫密码规格开始协议，而是要叫作密码规格变更协议呢？这是因为即便在密码通信开始之后,客户端和服务器也可以通过重新握手来再次改变密码套件。也就是说,在最开始的时候,客户端和服务器是使用“不加密”这一密码套件进行通信的,因此通信内容没有进行加密。

14.3.5 2-3 警告协议

        TLS的警告协议( alert protocol )是TLS握手协议的一部分,用于当发生错误时通知通信对象。当握手协议的过程中产生异常,或者发生消息认证码错误、压缩数据无法解压缩等问题时,会使用该协议。

14.3.6 2-4应用数据协议

        应用数据协议是 TLS 握手协议的一部分，用于和通信对象之间传送应用数据。

        当TLS 承载 HTTP 时，HTTP 的请求和响应就会通过 TLS 的应用数据协议和 TLS 记录协议来进行传送。

14.3.7 主密码

        主密码是 TLS 客户端和服务器之间协商出来的一个秘密的数值。这个数值非常重要，TLS密码通信的机密性和数据的认证全部依靠这个数值。主密码是一个48字节(384比特)的数值,例如：

        3A D9 A9 E7 59 03 FC 41 E4 06 DD CA

         59 93 CF CC CO 7E 16 E3 D2 43 12 3A

        B5 AB 6E DB 05 AD 3C 37 58 2A AC 71

        85 OD 7D AE 95 B8 2D BO 9A 28 66 14

主密码的计算

        主密码是客户端和服务器根据下列信息计算出来的。

        ⚪预备主密码

        ⚪客户端随机数

        ⚪服务器随机数

        当使用RSA公钥密码时,客户端会在发送ClientKeyExchange消息时,将经过加密的预备主密码一起发送给服务器。

        当使用 Diffie-Hellman 密钥交换时，客户端会在发送 ClientKeyExchange 消息时，将 DiffieHellman的公开值一起发送给服务器。根据这个值,客户端和服务器会各自生成预备主密码。关于客户端和服务器为什么能够生成出相同的值，请参见 11.5.2 节的内容。

        客户端随机数和服务器随机数的作用相当于防止攻击者事先计算出密钥的盐。

        当根据预备主密码计算主密码时，需要使用基于密码套件中定义的单项散列函数（如 SHA256）来实现的伪随机函数（Pseudo Random Function，PRF）。

主密码的目的

        主密码用于生成下列 6种信息。

        ⚪对称密码的密钥（客户端→服务器）

        ⚪对称密码的密钥（客户端←服务器）

        ⚪消息认证码的密钥（客户端→服务器）

        ⚪消息认证码的密钥（客户端一服务器）

        ⚪对称密码的 CBC 模式所使用的初始化向量（客户端→服务器）

        ⚪对称密码的 CBC 模式所使用的初始化向量（客户端一服务器）

14.3.8 TLS中使用的密码技术小结

        这里我们将 TLS 中使用的密码技术按各协议整理成了表 14-1 和表 14-2。

14.4 对SSL/TLS的攻击

        下面我们来思考一下与SSL/TLS相关的攻击。

14.4.1 对各个密码技术的攻击

        针对SSL/TLS中使用的各个密码技术的攻击,会直接成为对SSL/TLS的攻击。例如,如果能够找到SSL/TLS中使用的对称密码的弱点,就相当于找到了SSL/TLS通信机密性的弱点。

        然而, SSL/TLS作为框架的特性也正是在这里能够得以体现。SSL/TLS并不依赖于某种特定的密码技术,当发现某种对称密码存在弱点时,今后只要选择不包含该对称密码的密码套件就可以了。这就好像一台机器的某个零件损坏时，只要更换这个损坏的零件就可以了。

14.4.2 OpenSSL 的心脏出血漏洞

        2014年, Google的Neel Mehta发现了广泛使用的密码学工具包OpenSSL 中存在一个bug,这个漏洞称为心脏出血(HeartBleed)。心脏出血并不是SSL/TLS协议本身的漏洞，而是OpenSSL 这一实现上的漏洞。

        具体来说，由于 OpenSSL 在 TLS 心跳扩展功能中对于请求的数据大小没有进行检查，从而导致误将内存中与该请求无关的信息返回给请求者，这就是心脏出血漏洞。攻击者通过访问使用了包含该漏洞的OpenSSL 的服务器，就可以在一定范围内窃取服务器上的信息。

        这一漏洞公布时，全世界有相当多的服务器都受到了影响，据称当时有 17% 的 SSL/TLS 服务器都具有这一漏洞。由于这一漏洞会造成原本需要安全通信的服务器上的数据泄露,因此成为了一个急需应对的严重问题。

        要应对这一漏洞，可以将OpenSSL 更新到已消除心脏出血漏洞的版本，或者加上禁用心跳扩展的选项重新编译OpenSSL。详情请参见 CVE-2014-0160。

14.4.3 SSL 3.0 的漏洞与 POODLE 攻击

        2014 年, Google 的 Bodo Möller、 Thai Duong 和 Krzysztof Kotowicz 发表了一篇题为 ThisPOODLE Bites: Exploiting The SSL 3.0 Fallback 的论文（Security Advisory )②，其中描述了一种针对SSL 3.0 漏洞的攻击——POODLE 攻击。

        SSL 3.0 中对 CBC 模式加密时的分组填充操作没有进行严格的规定，而且填充数据的完整性没有受到消息认证码的保护，POODLE攻击正是利用了这一漏洞来窃取秘密信息的。POODLE 攻击的本质就是我们前面在 CBC模式的介绍中提到的填充提示攻击（4.4.5 节)。

        更严重的问题是，在某些条件下，攻击者可以将通信协议的版本从 TLS 强制降级到 SSL3.0。也就是说，尽管有些服务器使用了 TLS 协议，但仍然有可能被强制降级到 SSL 3.0，导致存在遭受 POODLE 攻击的风险。

        因此,要有效抵御POODLE攻击,必须禁用SSL 3.0,详情请参见CVE-2014-3566.

14.4.4 FREAK攻击与密码产品出口管制

        2015年,一些研究者发现SSL/TLS中存在一个漏洞,利用这一漏洞的攻击被称为FREAK攻击。FREAK是Factoring RSA Export Keys(出口级RSA密钥质因数分解)的缩写,其攻击方法是强制SSL/TLS服务器使用一种名为 RSA Export Suites 的强度较低的密码套件。要实现FREAK攻击,除了需要SSL/TLS服务器具有该漏洞,同时还需要用户的Web浏览器(HTTP客户端)接受使用RSA Export Suites来进行通信。

        美国曾经将密码算法和软件作为武器来看待，因此历史上一度禁止将“高强度密码软件”出口到国外(密码产品出口管制),直到20世纪90年代后半期这一政策才有所缓和。RSAExport Suites就是一种配合当时的环境而故意弱化的密码套件。RSA Export Suites中使用了512比特的RSA和40比特的DES,这一组合在当时还勉强够用,然而到了现在已经绝对不应该使用了。但实际上,现在全世界还有很多Web服务器允许使用RSA Export Suites,就连OpenSSL等SSL/TLS工具包在实现上也没有禁用RSA Export Suites,这使得FREAK攻击成为了可能。

        FREAK攻击也是一种中间人攻击,当浏览器与Web服务器协商SSL/TLS的密码套件时(此时的通信内容还没有被加密),攻击者Mallory可以介入其中,强制双方使用RSA ExportSuites。如果浏览器和Web服务器双方都具备该漏洞,那么它们便会按照Mallory的指示开始使用 RSA Export Suites进行通信。通常情况下，在密码套件确定之后，双方的通信就开始加密，这时 Mallory 应该无法窃听其中的内容，然而由于 RSA Export Suites 的强度非常低，因此Mallory可以暴力破解共享密钥，从而能够对本应安全传输的数据进行解密。这一漏洞的编号为CVE-2015-0204在密码产品出口管制实行20年之后,FREAK漏洞的威胁显现出来。

14.4.5 对伪随机数生成器的攻击

        1995年,加州大学伯克利分校的研究生David Wagner和Ian Goldberg发现了NetscapeNavigator浏览器的一个bug"。而且他们并没有阅读浏览器的源代码,而是通过一般人都可以得到的程序文件找出这个bug的。他们将这个bug的危险性进行了广泛的告知。一这个 bug 存在于伪随机数生成器中。由于 SSL 中使用的伪随机数生成器的种子都在时间和进程编号等可预测的范围内，因此所得到的密钥范围实际上非常小。

14.4.6 利用证书的时间差进行攻击

        SSL/TLS中,客户端会使用服务器证书对服务器进行认证。在这个过程中,客户端需要使用合法认证机构的公钥对证书所附带的数字签名进行验证。

        正如我们在第 10 章所提到的那样，要验证证书需要使用最新版的 CRL(证书作废清单)。而 Web 浏览器如果没有获取最新版的 CRL，即便使用 SSL/TLS 也无法保证通信的安全。

14.5 SSL/TLS用户的注意事项

        SSL/TLS是我们经常使用的一种密码通信方式,但并不是说只要使用SSL/TLS就是绝对安全的。

14.5.1 不要误解证书的含义

        在SSL/TLS中，我们能够通过证书对服务器进行认证。然而这里的认证，只是确认了通信对象是经过认证机构确认的服务器,而并不能确认是否可以和该通信对象进行安全的在线购物交易。说得更直白些,就是即便对方拥有合法的证书,也不代表你就可以放心地发送信用卡号,因为仅通过SSL/TLS是无法确认对方是否在从事信用卡诈骗的。

        此外,认证机构所进行的本人身份确认也分为不同的等级,需要仔细确认一下认证机构的业务规则。

        为了提高 SSL运用的可靠性，一个名为CA/Browser论坛的组织制定了 EV SSL证书( Extended Validation Certificate )规范,详情请参见http://www.cabforum.org/。

14.5.2 密码通信之前的数据是不受保护的

        SSL/TLS仅对通信过程中的数据进行保护,而无法保护通信前的数据。

        例如，当 Alice 在公司访问一个受 SSL/TLS 保护的网站时，Alice 向该网站发送的个人信息是受到保护的，对通信线路进行窃听的 Eve 无法获取这些个人信息。然而,如果当Alice在浏览器中输入这些信息时,背后有人偷看的话, SSL/TLS就无法保护 Alice的个人信息了。

14.5.3 密码通信之后的数据是不受保护的

        SSL/TLS也无法保护通信之后的数据。

        例如, Alice 向 Bob网上书店发送了自己的信用卡号。在通信过程中,信用卡号是受到SSL/TLS 保护的。然而，当信用卡号发送到 Bob 书店的服务器之后情况又如何呢？对于 Bob 书店如何管理所收到的信用卡号, SSL/TLS是完全无法得知的。

        如果 Bob 书店将客户的信用卡号随意存放在 Web 服务器上的话，就会发生客户信用卡号泄露的风险。

        综上,“由于使用了SSL/TLS,因此可以放心地发送信用卡号”这种说法把情况过分简化了。严格来说,应该是“由于使用了SSL/TLS,因此信用卡号不会在通信过程中被第三方获取”,而信用卡号在通信之前被偷窥,以及在通信之后被窃取,或者被网上书店本身恶意使用等可能性还是存在的。

14.6 本章小结

        本章中,我们学习了SSL/TLS的相关知识,了解了客户端和服务器通过交换一些必要信息来实现密码通信的过程。

        SSL/TLS是将对称密码、公钥密码、单向散列函数、消息认证码、伪随机数生成器、数字签名等技术相结合来实现安全通信的。此外, SSL/TLS还可以通过切换密码套件来使用强度更高的密码算法。

        我们在使用Web浏览器时并不会意识到SSL/TLS的详细工作过程,但我们可以知道,为了保证安全性, SSL/TLS采用了非常复杂的机制。

        下一章就是本书的最后一章了,我们将重新回顾一下本书中所介绍的密码技术,并针对现实中存在的威胁,探讨一下密码技术能够应对以及不能应对的内容。

        小测验2 SSL/TLS的基础知识                        （答案见 14.7 节）

        下列说法中,请在正确的旁边画⚪,在错误的旁边画×。

        (1)使用SSL/TLS可以确保通信的机密性。

        (2)在SSL/TLS中,使用数字签名技术来认证通信双方的身份。

        (3)在SSL/TLS中,由于使用了公钥密码或者密钥交换技术,因此伪随机数生成器的品质低一点也没有关系。

        (4)在SSL/TLS中,由于公钥是服务器发送的,因此客户端无需持有任何公钥就可以对服务器进行认证。

        (5)使用 SSL/TLS的公司是可信的,因此可以放心地发送信用卡号。

14.7 小测验的答案

        小测验 1 的答案：预备主密码的加密                （14.3.3 节）

        客户端是在收到服务器发送的Certificate消息时获得服务器的公钥的。Certificate消息中包含服务器的证书,而服务器的证书就是服务器的公钥再加上认证机构的数字签名所组成的。

        小测验 2 的答案: SSL/TLS的基础知识                （14.6 节）

       ⚪(1)使用SSL/TLS可以确保通信的机密性。

        ⚪（2) 在 SSL/TLS 中，使用数字签名技术来认证通信双方的身份。

        ×（3) 在 SSL/TLS 中，由于使用了公钥密码或者密钥交换技术，因此伪随机数生成器的品质低一点也没有关系。成器的品质很低,攻击者就可能预测出所生成的共享密钥。因此,必须使用具备不可预测性的伪随机数生成器。SSL/TLS 中的确使用了公钥密码或者密钥交换技术来生成共享密钥，但如果伪随机数生

        ×（4) 在 SSL/TLS 中，由于公钥是服务器发送的，因此客户端无需持有任何公钥就可以对服务器进行认证。为了对服务器发送过来的证书进行认证,客户端需要持有对该证书签名的认证机构的合法公钥,因此,客户端在不持有任何公钥的情况下,是无法对服务器进行认证的。

        ×(5)使用SSLTLS的公司是可信的,因此可以放心地发送信用卡号。即便使用了SSLTLS,也不能说该公司就是可信的。