计算机网络7——网络安全3 互联网使用的安全协议

前面几节所讨论的网络安全原理都可用在互联网中，目前在网络层、运输层和应用层都有相应的网络安全协议。下面分别介绍这些协议的要点。

一、网络层安全协议

1、IPsec 协议族概述

我们在第4章的4.8.1节中讨论虚拟专用网VPN时，提到在 VPN 中传送的信息都是经过加密的。现在我们就要介绍提供这种加密服务的IPsec。

IPsec 并不是单一的协议，而是能够在IP层提供互联网通信安全的协议族(不太严格的名词“IPsec 协议”也常见到)。实际上，IPsec包含了一个通用框架和若干加密算法，具有相当的灵活性和可扩展性。IPsec允许通信双方从中选择合适的算法和参数(例如，密钥长度)，以及是否使用鉴别。为保证互操作性，IPsec规定其所有的实现都必须包含Psec所推荐的全部加密算法。

IPsec 就是“IP安全(security)”的缩写。在很多RFC 文档中已给出了详细的描述。在这些文档中，最重要的就是描述IP安全体系结构的RFC4301(目前是建议标准)和提供IPsec 协议族概述的 RFC6071。

IPsec 协议族中的协议可划分为以下三个部分:

• IP安全数据报格式的两个协议:鉴别首部AH(Authentication Header)协议和封装安全有效载荷 ESP(Encapsulation Security Payload)协议。
• 有关加密算法的三个协议。
• 互联网密钥交换 IKE(Intermet Key Exchange)协议。

下面我们要重点介绍IP安全数据报的格式，以便了解IPsec怎样提供网络层的安全通信。AH协议提供源点鉴别和数据完整性，但不能保密。而ESP协议比AH协议复杂得多，它提供源点鉴别、数据完整性和保密。IPsec支持IPv4和IPv6。在IPv6中，AH 和 ESP 都是扩展首部的一部分。AH协议的功能都已包含在ESP协议中，因此使用ESP协议就可以不使用 AH 协议。下面我们将不再讨论AH 协议，而只介绍ESP协议的要点。

使用ESP或AH协议的IP数据报称为IP安全数据报(或IPsec 数据报)，它可以在两台主机之间、两个路由器之间或一台主机和一个路由器之间发送。

IP 安全数据报有以下两种不同的工作方式。
第一种工作方式是运输方式(transpont mode)。运输方式是在整个运输层报文段的前后分别添加若干控制信息，再加上IP首部，构成IP安全数据报(见图(a))。
第二种工作方式是隧道方式(tunnel mode)。隧道方式是在原始的IP 数据报的前后分别添加若干控制信息，再加上新的IP首部，构成一个IP 安全数据报(见图 (b))。

无论使用哪种方式，最后得出的IP安全数据报的I首部都是不加密的。只有使用不加密的 IP 首部，互联网中的各个路由器才能识别 I 首部中的有关信息，把IP 安全数据报在不安全的互联网中进行转发，从源点安全地转发到终点。所谓“安全数据报”是指数据报的数据部分是经过加密的，并能够被鉴别的。通常把数据报的数据部分称为数据报的有效载荷(payload)。

由于目前使用最多的就是隧道方式，因此下面的讨论只限于隧道方式。

2、安全关联

在发送 IP安全数据报之前，在源实体和目的实体之间必须创建一条网络层的逻辑连接，即安全关联 SA (Security Association)。这样，传统的互联网中无连接的网络层就变为了具有逻辑连接的一个层。安全关联是从源点到终点的单向连接，它能够提供安全服务。如要进行双向安全通信，则两个方向都需要建立安全关联。假定某公司有一个公司总部和一个在外地的分公司。总部需要和这个分公司以及在各地出差的n个员工进行双向安全通信。在这种情况下，一共需要创建(2+2n)条安全关联 SA。在这些安全关联 SA 上传送的就是 IP 安全数据报。
图(a)是安全关联SA的示意图。公司总部和分公司都各有一个负责收发IP 数据报的路由器R1和R2(通常就是公司总部和分公司的防火墙中的路由器)，而公司总部与分公司之间的安全关联 SA 就是在路由器 R1和R2之间建立的。当然，路由器R1和R2都必须预先装有IPsec。现假定公司总部的主机H1要和分公司的主机H2通过互联网进行安全通信。

公司总部主机H1发送给分公司主机H2的IP数据报，必须先经过公司总部的路由器R1。然后经IPsec的加密处理后，成为IP 安全数据报。这样就把原始的IP 数据报隐藏在 IP 安全数据报中了。IP安全数据报经过互联网中很多路由器的转发，最后到达分公司的路由器R2，路由器R2对IP安全数据报解密，还原出原始的数据报，传送到终点主机H2。从逻辑上看IP安全数据报在安全关联 SA 上传送，就好像通过一个安全的隧道。这就是“隧道方式”这一名词的来源。如果总部的主机H1要和总部的另一台主机H3通信，由于都在公司内部，不需要加密，因此不需要建立安全关联。H1发出的IP 数据报只需通过总部内部的路由器R1转发一次即可送到 H3。如果H1要上网查看天气预报，同样不需要建立安全关联，而是发送IP 数据报，经过路由器R1转发到互联网中的下一个路由器，最后到达互联网中预报气象的服务器。

若公司总部的主机H1要和某外地业务员的便携机H2进行安全通信，则情况将稍有不同(如图 (b)所示)。可以看出，这时公司总部的路由器R1和外地业务员的便携机 H2建立安全关联 SA(即路由器和主机之间的安全关联)。公司总部H1发送的IP数据报，通过路由器R1后，就变成了IP安全数据报。经过互联网中许多路由器的转发，最后到达H2。可以看出，现在是在路由器R1和业务员的便携机H2之间构成了一个安全隧道。外地业务员利用事先安装在便携机H2中的IPsec对IP安全数据报进行鉴别和解密，还原H1发来的IP 数据报。

建立安全关联 SA 的路由器或主机，必须维护这条 SA的状态信息。我们以图 7-18中的安全关联 SA为例，说明其状态信息应包括的项目:

• 一个32位的连接标识符，称为安全参数索引SPI(SecurityParameter Index)。
• 安全关联 SA 的源点和终点的 IP 地址(即路由器 R, 和 R,的 IP 地址)。
• 所使用的加密类型(例如，DES或AES)
• 加密的密钥。
• 完整性检查的类型(例如，使用报文摘要 MD5或SHA-1的报文鉴别码 MAC)。
• 鉴别使用的密钥。

当路由器R1要通过 SA 发送IP安全数据报时，就必须读取 SA 的这些状态信息，以便知道如何把 IP 数据报进行加密和鉴别。

3、IP 安全数据报的格式

下图是IP安全数据报的格式。下面以隧道方式为例，结合各字段的作用，讨论一下IP 安全数据报是怎样构成的。图中的数字1至6表示IP 安全数据报构成的先后顺序。

1. 首先在原始的IP数据报(也就是ESP的有效载荷)后面添加ESP尾部。ESP尾部有三个字段。第一个字段是填充字段，用全0填充。第二个字段是填充长度(8位)，指出填充字段的字节数。为什么要进行填充呢?这是因为在进行数据加密时，通常都要求数据块长度是若干字节(例如，4字节)的整数倍。当I数据报长度不满足此条件时，就必须用0进行填充。每个0为一个字节长。虽然填充长度(8位)的最大值是255，但实际上，填充很少会用到这个最大值。ESP尾部最后一个字段是“下一个首部”(8位)。这个字段的值指明，在接收端，ESP的有效载荷应交给哪个协议来处理。如上图所示，IP安全数据报有三个首部。现在ESP尾部中的“下一个首部”显然就是指ESP的有效载荷中的“原始的IP首部”，IP的协议值是4，因此“下一个首部”应填入的数值是4。如果不是隧道方式而是运输方式，则“ESP的有效载荷”就应当是TCP或UDP报文段,“下一个首部”的值也要改为另外的数值。
2. 按照安全关联SA指明的加密算法和密钥，对“ESP的有效载荷(即原始的IP 数据报)+ESP 尾部”(见上图中的“加密的部分”)进行加密。
3. 对“加密的部分”完成加密后，就添加ESP首部。ESP首部有两个 32 位字段。第一个字段存放安全参数索引SPI。通过同一个SA的所有IP安全数据报都使用同样的SPI值第二个字段是序号，鉴别要用到这个序号，它用来防止重放攻击。请注意，当分组重传时序号并不重复。
4. 按照 SA 指明的算法和密钥，对“ESP首部+加密的部分”(见上图中的“鉴别的部分”)生成报文鉴别码 MAC。
5. 把所生成的报文鉴别码MAC添加在ESP尾部的后面，和ESP首部、ESP的有效载荷、ESP尾部一起，构成IP安全数据报的有效载荷。
6. 生成新的 IP 首部，通常为 20 字节长，和普通的IP 数据报的首部的格式是一样的。需要注意的是，首部中的协议字段的值是50，表明在接收端，首部后面的有效载荷应交给ESP 协议来处理。

当分公司的路由器R2收到IP安全数据报后，先检查首部中的目的地址。发现目的地址
就是R2，于是路由器R2就继续处理这个IP安全数据报。

路由器R2找到IP首部的协议字段值(现在是 50)，就把IP 首部后面的所有字段(即IP安全数据报的有效载荷)都用ESP协议进行处理。先检查ESP首部中的安全参数索引SPI,以确定收到的数据报属于哪一个安全关联 SA(因为路由器R2可能有多个安全关联)。路由器 R2接着计算报文鉴别码MAC，看是否和 ESP尾部后面添加的报文鉴别码 MAC相符如是，即知收到的数据报的确是来自路由器R1。再检验ESP首部中的序号，以证实有无被入侵者重放。接着要用和这个安全关联SA 对应的加密算法和密钥，对已加密的部分进行解密。再根据ESP尾部中的填充长度，去除发送端填充的所有0，还原出加密前的ESP有效载荷，也就是 H发送的原始 IP 数据报。

根据解密后得到的ESP尾部中“下一个首部”的值(现在是4)，把ESP的有效载荷交给IP来处理。当找到原始的IP首部中的目的地址是主机H2的IP地址时，就把整个的IP数据报传送给主机H2。整个IP数据报的传送过程到此结束。

请注意，在上图的“原始的IP首部”中，是用主机H1和H2的IP 地址分别作为源地址和目的地址，而在IP 安全数据报的“新的 IP 首部”中，是使用路由器 R1和 R2的 IP 地址分别作为源地址和目的地址(这是图(a)所示的情况)。但如果是图 (b)所示的情况IP安全数据报不经过另一个路由器R1，那么在IP安全数据报的“新的IP 首部”中，要用路由器R1和主机H2的IP地址分别作为IP安全数据报的源地址和目的地址。

从以上的讨论可以看出，设想有一个IP安全数据报在互联网中被某人截获，如果截获者不知道此安全数据报的密码，那么他只能知道这是一个从路由器R1发往路由器R2的IP数据报，但却无法看懂其有效载荷中的数据含义。如果截获者篡改了数据报的源地址，那么安全数据报的鉴别功能可以保证源地址的真实性。假定截获者故意删除了安全数据报中的一些字节，但由于接收端的路由器R2能够进行完整性检验，就不会接收这种含有差错的信息。如果截获者试图进行重放攻击，那么由于安全数据报使用了有效的序号，使得重放攻击也无法得逞。

4、lPsec 的其他构件

前面已经提到过，发送IP安全数据报的实体可能要用到很多条安全关联SA。那么这些SA存放在什么地方呢?这就要提及IPsec的一个重要构件，叫作安全关联数据库SAD(Security Association Database)。所有需要运行IPsec 的站点都必须有 SAD。当主机要发送 IP安全数据报时，就要在SAD中查找相应的SA，以便获得必要的信息，来对该IP安全数据报实施安全保护。同样，当主机要接收IP安全数据报时，也要在SAD中查找相应的SA，以便获得信息来检查该分组的安全性。

前面已经提到了，主机所发送的数据报并非都必须进行加密，很多信息使用普通的数据报用明文发送即可。因此，除了安全关联数据库SAD，还需要另一个数据库，这就是安全策略数据库 SPD(Security Policy Database)。SPD 指明什么样的数据报需要进行 IPsec 处理这取决于源地址、源端口、目的地址、目的端口，以及协议的类型等。因此，当一个IP 数据报到达时，SPD指出应当做什么(使用IP安全数据报还是不使用)，而SAD 则指出，如果需要使用 IP 安全数据报，应当怎样做(使用哪一个SA)。

还有一个问题，安全关联数据库SAD中存放的许多安全关联SA是怎样建立起来的呢?如果一个虚拟专用网 VPN 只有几个路由器和主机，那么用人工键入的方法就可以建立起所需的安全关联数据库 SAD。但如果一个 VPN 有好几百或几千个路由器和主机，人工键入的方法显然是不行的。因此，对于大型的、地理位置分散的系统，为了创建SAD，我们需要使用自动生成的机制，即使用互联网密钥交换IKE(InternetKeyExchange)协议。IKE 的用途就是为IP安全数据报创建安全关联 SA。

IKE是个非常复杂的协议，IKEv2是其新的版本，在2014年10月已成为互联网的正式标准TRFC 7296，STD79]。IKEv2以另外三个协议为基础:

• Oakley–是个密钥生成协议[RFC 2412]。
• 安全密钥交换机制 SKEME(Secure Key Exchange MEchanism)—是用于密钥交换的协议。它利用公钥加密来实现密钥交换协议中的实体鉴别。
• 互联网安全关联和密钥管理协议 ISAKMP (Intemmet Secure Association and Key ManagementProtocol)–用于实现IKE中定义的密钥交换，使IKE的交换能够以标准化、格式化的报文创建安全关联 SA。

关于IKE的深入介绍可参阅有关文档，如RFC4945和RFC7427(都是建议标准)

二、运输层安全协议

1、协议 TLS 的要点

当万维网能够提供网上购物时，安全问题就马上被提到桌面上来了。例如，当顾客在
不安全的互联网上购物时，他会要求得到下列安全服务：

• 顾客需要确保服务器属于真正的销售商，而不是某个冒充者。这就是应对身份进行鉴别。
• 顾客与销售商需要确保报文的内容(例如账单)在传输过程中没有被篡改。这就是应保证通信内容的数据完整性。
• 顾客与销售商需要确保诸如信用卡上的敏感信息不被泄露。这就是要有机密性。

不仅在电子商务领域，即使在我们日常上网浏览各种信息时，我们所浏览的信息也是属于个人隐私，不应作为网上的公开信息。因此，在很多情况下，客户端(浏览器)与服务器之间的通信需要使用安全的运输层协议。曾经广泛使用的运输层安全协议有两个，即:(1)安全套接字层 SSL(Secure Socket Layer)。(2)运输层安全 TLS(Transport Layer Security)。

协议 SSL是 Netscape 公司在1994年开发的安全协议，广泛应用于基于万维网的各种网络应用(但不限于万维网应用)。SSL作用在端系统应用层的HTTP和运输层之间，在TCP之上建立起一个安全通道，为通过 TCP 传输的应用层数据提供安全保障。

1995年Netscape 公司把协议SSL转交给IETF，希望能够把SSL进行标准化。1999年IETF在 SSL 3.0的基础上设计了协议 TLS 1.0(改动极少)，为所有基于 TCP的网络应用提供安全数据传输服务。为了应对网络安全的变化，IETF及时地对TLS的版本进行升级，如2006年的TLS 1.1，2008年的TLS 1.2。2014年10月，谷歌建议禁用 SSL3.0，因为其设计上有漏洞，用户的敏感信息有被窃取的可能。接着，Mozilla 和微软也发出了同样的安全通告。2018年8月IETF发布了经历了28个草案后才通过的最新版本TLS1.3IRFC8446，建议标准(不向后兼容)。在 2020年，旧版本 TLS 1.0/1.1均被废弃。目前谷歌浏览器Chrome 和火狐浏览器 Firefox 都已开始使用更加安全的协议 TLS 1.3，但不少老客户端仍未抛弃一些旧版本应当说，到目前为止协议 TLS1.2还是安全可用的，只是被发现了有潜在的安全隐患。因此，现在能够使用的运输层安全协议就只剩下协议 TLS 1.2和协议 TLS 1.3了。

协议 TLS 的位置在运输层和应用层之间(如图7-20所示)。虽然协议 SSL 2.0/3.0均已被废弃不用了，但现在还经常能够看到把“SSL/TLS”视为TLS的同义词。这是因为协议TLS 本来就源于 SSL(但并不兼容)，而现在旧协议 SSL 被更新为新协议 TLS。

应用层使用协议TLS最多的就是HTTP，但并非仅限于HTTP。因为协议TLS是对TCP加密，因此任何在TCP之上运行的应用程序都可以使用协议TLS。例如，用于IMAP邮件存取的鉴别和数据加密也可以使用TLS。TLS提供了一个简单的带有套接字的应用程序接口 API，这和TCP的API是相似的。

当不需要运输层安全协议时，HTTP就直接使用TCP连接，这时协议TLS不起作用。由于需要使用运输层安全协议的人越来越多，因此现在相当多的网站已是全站使用运输层安全协议。例如，当我们使用百度网站浏览信息时，在浏览器的地址栏键入其官网地址www.baidu.com后(不必在前面键入 http://或 https:/)，就可以在屏幕上看到这样的响应:

可以看出，尽管用户在浏览器上没有键入https://，但百度网站总是提供安全的运输层服务。提供安全运输层服务的标志是地址栏URL中的协议部分显示出的是https，并且在其左边还有一个安全锁备的标志。在 http后面加上的s代表 security，表明是使用 HTTPS，即提供安全服务的HTTP协议(TCP的HTTPS端口号是443，而不是HTTP使用的端口号80)这时我们就可以放心和这样的网站进行通信，因为这个网站已经被鉴别了是真正的百度网站并且之后在浏览器和百度服务器之间的所有交互报文都是加密的，因而通信的机密性得到了保证。

现在我们使用某些主流浏览器访问不安全的网站时，浏览器会向用户发出“不安全“的警告。下面给出当我们键入桔梗网的网址 shu.jiegeng.com 后所看到的响应:

这就提醒我们在上网时要注意信息的安全。

协议 TLS具有双向鉴别的功能。但大多数情况下使用的是单向鉴别，即客户端(浏览器)需要鉴别服务器。也就是说，浏览器A要确信即将访问的网站服务器B是安全和可信的。这必须要有两个前提。首先，服务器B必须能够证明本身是安全和可信的。因此服务器B需要有一个证书来证明自己。现在我们假定服务器B已经持有了有效的CA证书。这正是运输层安全协议TLS的基石。其次，浏览器应具有一些手段来证明服务器B是安全和可信的。下面就来讨论这一点。

生产电脑操作系统的厂商为了方便用户，把当前获得公众信任的许多主流认证中心CA的根证书，都已内置在其操作系统中。这些根证书上都有认证中心CA的公钥$P{K}_{CA}$，而且根证书都用CA的私钥$S{K}_{CA}$进行了自签名(防止伪造)。用户为了验证要访问的服务器是否安全和可信，只要打开电脑中的浏览器(操作系统自带的或用户自己装上的)，就可查到探作系统收藏的某个根认证中心的根CA证书，并可以利用证书上的公钥$P{K}_{CA}$对B的证书进行验证。若服务器B的证书是证书链上的某个中间CA签发的，那么浏览器A也可用类似方法验证B的证书的真实性。

由于浏览器与服务器的通信方式就是以前讲过的“客户-服务器方式”，因此下面就用客户代表浏览器。

如下图所示，在客户与服务器双方已经建立了TCP连接后，就可开始执行协议 TLS.根据 RFC 8446，这里主要有两个阶段，即握手阶段和会话阶段。在握手阶段，TLS使用其中的握手协议，而在会话阶段，TLS使用其中的记录协议。下面讨论协议 TLS的要点。

我们先介绍协议 TLS的握手阶段。握手阶段要验证服务器是安全可信的，同时生成在后面的会话阶段所需的共享密钥，以保证双方交换的数据的私密性和完整性。这里要提醒读者，在刚开始执行协议 TLS时，通信双方的信道是不安全的。因此要弄清:(1)双方怎样通过不安全的信道得到会话时所需的共享密钥。这里没有采用密钥分发中心KDC来分配密钥而是采用自己生成共享密钥的方法。(2)用什么方法保证所传送数据的机密性与完整性。

三、应用层安全协议

限于篇幅，我们在这一节仅讨论应用层中有关电子邮件的安全协议。

电子邮件在传送过程中可能要经过许多路由器，其中的任何一个路由器都有可能对转发的邮件进行阅读。从这个意义上讲，电子邮件是没有什么隐私可言的。

电子邮件这种网络应用也有其很特殊的地方，这就是发送电子邮件是个即时的行为。这种行为在本质上与我们前两节所讨论的不同。当我们使用IPSec或SSL时，我们假设双方在相互之间建立起一个会话并双向地交换数据。而在电子邮件中没有会话存在。当A向B发送一个电子邮件时，A和B并不会为此而建立任何会话。而在此后的某个时间，如果B读取了该邮件，他有可能会、也有可能不会回复这个邮件。可见我们所讨论的是单向报文的安全问题。

如果说电子邮件是即时的行为，那么发送方与接收方如何才能就用于电子邮件安全的加密算法达成一致意见呢?如果双方之间不存在会话，不存在协商加密/解密所使用的算法那么接收方如何知道发送方选择了哪种算法呢?

要解决这个问题，电子邮件的安全协议就应当为每种加密操作定义相应的算法，以便用户在其系统中使用。A必须要把使用的算法的名称(或标识)包含在电子邮件中。例如，A可以选择用AES进行加密/解密，并选择用SHA-1作为报文摘要算法。当A向B发送电子邮件时，就在自己的邮件中包含与AES和SHA-1相对应的标识。B在接收到该邮件后首先要提取这些标识，然后就能知道在解密和报文摘要运算时应当分别使用哪种算法了。

加密算法在使用加密密钥时也存在同样的问题。如果没有协商过程，通信的双方如何在彼此之间知道所使用的密钥?目前的电子邮件安全协议要求使用对称密钥算法进行加密和解密，并且这个一次性的密钥要跟随报文一起发送。发信人A可以生成一个密钥并把它与报文一起发送给B。为了保护密钥不被外人截获，这个密钥需要用收信人B的公钥进行加密。总之，这个密钥本身也要被加密。

还有一个问题也需要考虑。很显然，要实现电子邮件的安全就必须使用某些公钥算法例如，我们需要对密钥加密或者对邮件签名。为了对密钥进行加密，发信人A就需要收信人B的公钥，同样为了验证被签名的报文，收信人B也需要发信人A的公钥。因此，为了发送一个具有鉴别和保密的报文，就需要用到两个公钥。但是A如何才能确认B的公钥，B又如何才能确认A的公钥呢?不同的电子邮件安全协议有不同的方法来验证密钥。

下面我们介绍在应用层为电子邮件提供安全服务的协议PGP。

PGP(Pretty Good Privacy)是 Zimmermann 于 1995 年开发的。它是一个完整的电子邮件安全软件包，包括加密、鉴别、电子签名和压缩等技术。PGP并没有使用什么新的概念，在PGP中，发件方和收件方是如何获得对方的公钥呢?当然，最安全的办法是双方面对面直接交换公钥，但在大多数情况下这并不现实。因此可以通过认证中心CA签发的证书来验证公钥持有者的合法身份。然而在PGP中不要求使用CA，而是允许用一种第三方署的方式来解决该问题。例如，如果用户A和用户B分别和第三方C已经确认对方拥有的公钥属实，则C可以用其私钥分别对A和B的公钥进行签名，为这两个公钥进行担保。当A得到一个经C签名的B的公钥时，可以用已确认的C的公钥对B的公钥进行鉴别。不过，用户发布其公钥的最常见的方式还是把公钥发布在他们的个人网页上，或仅仅通过电子邮件进行分发。PGP很难被攻破。因此在目前可以认为PGP是足够安全的。