概述

TFTP（Trivial File Transfer Protocol）即简单文件传送协议。

TFTP客户端模块提供了使用TFTP协议进行文件上传和下载功能，为了实现上的简单，TFTP协议使用UDP协议进行文件的传输。

与FTP相比，TFTP不具有复杂的交互存取接口和认证控制，适用于客户机和服务器之间不需要复杂交互的环境。例如，系统启动时使用TFTP获取系统内存映像。为了保持报文长度短小，TFTP在UDP（User datagram Protocol）基础上实现。

当前设备实现了TFTP客户端功能，没有提供TFTP的服务器端功能。使用TFTP协议的客户端功能可以进行文件上传和下载。

TFTP协议的基本概念

• 操作码

  TFTP报文的头2个字节表示操作码，其取值和含义如下：

  • 1：Read request (RRQ)，表示读请求

  • 2：Write request (WRQ)，表示写请求

  • 3：Data (DATA)，表示数据

  • 4：Acknowledgment (ACK)，表示肯定应答

  • 5：Error (ERROR)，表示出错

• 文件模式

  TFTP传输文件有两种模式：

  • 二进制模式：用于传输程序文件

  • ASCII码模式：用于传输文本文件

目前设备只能使用二进制模式传输文件。

TFTP的基本原理

• TFTP不提供用户名和口令

  因为TFTP初始设计是用于系统引导进程的，所以它不提供用户名和口令。

• TFTP协议传输

  TFTP协议传输由客户端发起。

  • 当需要下载文件时，由客户端向TFTP服务器发送读请求包，然后从服务器接收数据包，并向服务器发送确认。

  • 当需要上传文件时，由客户端向TFTP服务器发送写请求包，然后向服务器发送数据包，并接收服务器的确认。

概述

FTP（File Transfer Protocol）在TCP/IP协议族中属于应用层协议，是文件传输标准。主要功能是向用户提供本地和远程主机之间的文件传输，尤其在进行版本升级、日 志下载和配置保存等业务操作时，广泛地使用FTP功能。FTP协议基于相应的文件系统实现。

FTP采用C/S（Client/Server）结构，如图1-1所示。

图1-1  FTP采用的Client/Server结构

• FTP Server：运行于设备上的FTP服务。提供远程客户端访问和操作的功能，用户可以通过FTP客户端程序登录到设备上，访问设备上的文件。
• FTP Client：FTP的客户端。提供本地设备对远程服务器的文件进行操作的命令。用户在PC上通过终端程序或Telnet程序与作为FTPClient的设备建立连接后，可以输入FTP命令建立与远程FTP Server的连接并访问远程主机上的文件，对远程主机上的文件进行操作。

FTP连接的建立

FTP采用2个TCP连接来传输文件：控制连接和数据连接。其中控制连接用于连接控制端口，传输控制命令；数据连接用于连接数据端口。在控制连接建立后，数据连接通过控制端口的命令建立起连接，进行数据的传输。

FTP连接的建立分为主动模式和被动模式，两者的区别在于数据连接是由服务器发起还是由客户端发起。缺省情况下采用主动模式，用户可以通过命令切换。

主动模式下，当客户端存在防火墙时，由于数据连接是由服务器发起，数据连接可能会发生问题。被动模式下，这个问题得到了解决。主动模式有利于对FTP服务器的管理，不利于对客户端的管理；被动模式则相反。

缺省情况下，服务器的端口21用于传输控制命令，端口20用于传输数据。

主动模式下FTP连接建立

FTP连接主动模式建立过程如图1-2所示。

图1-2  FTP连接主动模式建立过程

1. 服务器打开端口21启动监听，等待连接。
2. 客户端发起控制连接的建立请求，服务器响应连接，控制连接建立。
3. 客户端通过控制连接发送PORT命令，将客户端数据连接的临时端口号告诉服务器。
4. 服务器的20号端口与客户端建立起数据连接。

被动模式FTP连接建立

FTP连接被动模式建立过程如图1-3所示。

图1-3  FTP连接被动模式建立过程

1. 服务器打开端口21启动监听，等待连接。
2. 客户端发起控制连接的建立请求，服务器响应连接，控制连接建立。
3. 客户端通过控制连接发送命令字PASV，告知服务器处于被动模式。
4. 服务器回应，将服务器数据连接的临时端口号告诉客户端。
5. 客户端与服务器的临时端口建立起数据连接。

说明：

临时端口为随机产生。

概述

Telnet（Telecommunication Network Protocol）起源于1969年的ARPANET，是一种最早的Internet应用，Telnet提供了一种通过终端远程登录到服务器的方式，呈现一个交互式操作界面。用户可以先登录到一台主机，然后再通过Telnet的方式远程登录到网络上的其他主机上去，而不需要为每一台主机都连接一个硬件终端，然后对设备进行配置和管理。

Telnet协议的基本概念

• NVT

  即网络虚拟终端（Network Virtual Terminal）。是一种双向的虚拟设备，连接的双方都必需把它们各自的物理终端同NVT之间进行转换。Telnet协议可以工作在任何主机（例如，任何操作系统）或任何终端之间正是由于使用了统一的NVT。

  NVT是虚拟设备，对于连接的双方，即客户机和服务器，都必须把它们的物理终端和NVT进行相互转换。也就是说，不管客户进程终端是什么类型，操作系统必须把它转换为NVT格式。同时，不管服务器进程的终端是什么类型，操作系统必须能够把NVT格式转换为终端所能够支持的格式。

  物理终端与NVT的转换模型如图1-4所示。

  图1-4  物理终端与NVT的转换模型
  
  

• NVT ASCII

  即7比特的ASCII字符集。发送时，每个7比特的字符的最高比特位加0后，以8比特的格式发送。网间网协议族使用的字符集是NVTASCII。例如FTP、SMTP等。

• IAC

  Telnet通信的两个方向都是采用带内信令的方式，字节0xFF叫做IAC（Interpret AsCommand），即作为命令来解释。该字节后面的一个字节代表命令。

  以下列出设备用到的命令及其含义：

  • SE：子选项结束

  • SB：子选项开始

  • WILL：选项协商

  • WONT：选项协商

  • DO：选项协商

  • DONT：选项协商

  • IAC：其后面的一个字节作为命令来解释

• Telnet连接

  一个Telnet连接就是一个用来传输带有Telnet控制信息数据的TCP连接。

• Telnet的C/S模式

  Telnet采用客户端/服务器模式。如图1-5显示了Telnet客户端和服务器连接的示意图。

  图1-5  Telnet连接的示意图
  
  

  通过该示意图，可知：

  • Telnet使用的传输协议为TCP。

  • Telnet连接的任何回显信息，最终都会输出到终端上。

  • 服务器进程直接与“伪终端设备”交互。

  • 客户端和服务器通过一条TCP连接来传输命令和数据。

  • 客户端登录到服务器上。

Telnet工作原理

Telnet协议可以工作在任何主机或者任何终端之间。因为，无论客户终端是什么类型，操作系统都会把它转换成NVT格式；同时，操作系统也会将NVT格式转换成服务器终端所支持的类型。那么，可以屏蔽具体的客户端和终端类型，简单地认为Telnet双方都连接在NVT上。

说明：

Telnet采用对称性模型，因此理论上一个Telnet连接的每一端都必须有一个NVT。

Telnet连接的两端，通过“WILL、WONT、DO、DONT”请求来进行选项协商，从而确定Telnet服务的具体内容。这些选项包括回显、改变命令字符集、行方式等。

本节从以下几个方面介绍Telnet的工作原理：

• Telnet中的请求

  Telnet连接的任何一方都可以主动发起请求。请求的含义和用法如表1-2所示。

  表1-2  Telnet中的请求的使用

  发送方发出请求	含义	接受方应答
  		WILL	WONT	DO	DONT
  WILL	发送方想激活选项	－	－	接收方同意	接收方不同意
  WONT	发送方想禁止选项	－	－	－	接收方必须同意(1)
  DO	发送方想让接收方激活选项	接收方同意	接收方不同意	－	－
  DONT	发送方想让接收方禁止选项	－	接收方必须同意(1)	－	－

  说明：

  发起方发送“选项失效”请求（WONT和DONT）时，接收方必须同意；

  发起方发送一些“选项有效”的请求，接收方可以接受或者拒绝这些请求：

  • 如果接受请求，则选项立即生效；

  • 如果拒绝请求，则选项不生效，而发送方仍然能保留NVT的特性。

• 选项协商

  选项协商由3个字节组成，如下：

  < IAC, WILL/DO/WONT/DONT之一,选项代码>

  下面举例说明Telnet中如何进行选项协商。

  例如：服务器想跟客户端请求激活“远程流量控制”（选项标识是33），客户端表示同意激活该选项。两者交互的命令如下：

  • 服务器：< IAC,WILL,33 >

  • 客户端：< IAC,DO,33 >

• 子选项协商

  在主机之间传递选项时，除了一个选项代码外，可能还需要其他更多的信息。例如，要求对方指定终端类型，则对方必须回应一个用ASCII字符串表示的终端类型。

  子选项协商的格式如下：

  < IAC,SB,选项代码,子选项内容信息,IAC,SE>

  一次完整的子选项协商过程如下：

  • 发送方发送一个带有选项代码的DO/WILL命令来请求激活该选项。

  • 接收方发送一个带有选项代码的WILL/DO命令来同意激活该选项。

    至此，双方都同意使用该选项。

    其中一方通过SB命令后跟子选项代码，并且以SE结尾来开始子选项协商。

  • 对方同样以SB命令后跟子选项代码和相关协商信息，并且以SE结尾来回应子选项协商。

  • 另一方回应DO/WILL命令来同意该子选项。

  如果没有其他子选项需要协商，则本次协商结束。

  说明：

  上述过程假设接收方同意发送方的请求。实际应用中，接收方根据需要，在任何时候都可以拒绝发送方的请求。

  下面举一个终端类型协商的示例。

  例如：客户端要激活本地的“终端类型”（选项标识是24）选项；服务器同意；服务器会发出询问客户端的终端类型的请求；客户端于是向服务器发送其终端类型为“DELLPC机”。两者交互的命令如下：

  • 客户端：< IAC, WILL, 24 >

  • 服务器：< IAC, DO, 24 >

  • 服务器：< IAC, SB, 24, 1, IAC, SE >

  • 客户端：< IAC, SB, 24, 0,‘D’,‘E’,‘L’,‘L’,‘P’,‘C’, IAC, SE >

  说明：

  • 只有DO类型的发送端可以发送请求。

  • 只有WILL类型的发送端可以发送实际的类型信息。

  终端类型信息不能以自动方式发送，而只能是以<请求－响应>的方式。

  终端类型信息是NVT ASCIIString字符串类型。该类型编码不区分大小写的差别。

• 操作方式

  Telnet协议规定有4种操作方式。

  • 半双工

  • 一次一个字符

  • 一次一行

  • 行方式

设备中提供的Telnet服务

设备提供的Telnet服务包括：

• Telnet Server

  用户在PC上运行Telnet客户端程序登录到设备，对设备进行配置管理。

• Telnet Client

  用户在PC上通过终端仿真程序或Telnet客户端程序建立与设备的连接后，再执行telnet命令登录到其它设备，对其进行配置管理。如图1-6所示，SwitchA此时既作为Telnet Server，也同时提供Telnet Client服务。

  图1-6  提供Telnet Client服务
  
  

概述

SSH是Secure Shell（安全外壳）的简称，标准协议端口号22。

Telnet缺少安全的认证方式，而且传输过程采用TCP进行明文传输，存在很大的安全隐患。单纯提供Telnet服务容易招致DoS（Denyof Service）、主机IP地址欺骗、路由欺骗等恶意攻击。

随着人们对网络安全的重视，传统的Telnet和FTP通过明文传送密码和数据的方式，已经慢慢不被人接受。SSH（SecureShell）是一个网络安全协议，通过对网络数据的加密，解决了这个问题。它在一个不安全的网络环境中，提供了安全的远程登录和其他安全网络服务。

SSH通过TCP进行数据交互，它在TCP之上构建了一个安全的通道。另外SSH服务除了支持标准端口22外，还支持其他服务端口，以防止受到非法攻击。

SSH支持Password认证、DSA认证和RSA认证，对数据进行DES、3DES、AES等加密，有效防止了对密码的窃听，保护了数据的完整性和可靠性，保证了数据的安全传输。特别是对于RSA和DSA认证的支持，对称加密和非对称加密的混合应用，密钥的安全交换，最终实现了安全的会话过程。

由于SSH数据加密传输，认证机制更加安全，SSH已经越来越被广泛使用，成为了当前最重要的网络协议之一。

SSH协议有两个版本：SSH1（SSH1.5）协议和SSH2（SSH2.0）协议，两者是不同的协议，不兼容。SSH2.0在安全、功能和性能上均比SSH 1.5有优势。

设备支持STelnet的客户端和服务器端，以及SFTP的客户端和服务器端，均支持SSH1（SSH1.5）协议和SSH2（SSH2.0）协议。

STelnet是Secure Telnet的简称，使得用户可以从远端安全登录到设备，提供交互式配置界面，所有交互数据均经过加密，实现安全的会话。

SFTP是Secure FTP的简称，使得用户可以从远端安全地登录到设备上进行文件管理，这样使远程系统升级等需要文件传送的地方，增加了数据传输的安全性。同时，由于提供了客户端功能，可以在本设备上安全FTP到远程设备，进行文件的安全传输。

SSH的基本概念

• SFTP

  SFTP（SSH File Transfer Protocol）。在一个传统不安全的网络环境中，服务器通过对客户端的认证及双向的数据加密，为网络文件传输提供了安全的服务。

• SCP

  SCP（Secure Copy）。在一个传统不安全的网络环境中，服务器通过对客户端的认证及双向的数据加密，为网络文件传输提供了安全的服务。

• STelnet

  一种安全的Telnet服务。在一个传统不安全的网络环境中，服务器通过对客户端的认证及双向的数据加密，为网络终端访问提供了安全的服务。

• RSA认证

  RSA（Revest-Shamir-Adleman Algorithm）身份认证是基于客户端私钥的一种认证方式。它是一种公开密钥加密体系，是一种非对称加密算法，其原理是基于大整数因子分解这一著名的数学难题，主要用来传递对称加密算法所使用的密钥，通过这种方法可以有效地提高加密的效率并能简化对密钥的管理。

  服务器必须检查用户是否是合法的SSH用户，检查公钥对于该用户是否合法，用户数字签名是否合法。若三者同时满足，则身份认证通过；若其中任何一项不能验证通过均告验证失败，拒绝该用户的登录请求。

• DSA认证

  DSA（Digital Signature Algorithm，数字签名算法）是由一种用于用户认证的非对称加密算法，由公钥和私钥两部分组成。

  和RSA认证相同，服务器必须检查用户是否是合法的SSH用户，检查公钥对于该用户是否合法，用户数字签名是否合法。若三者同时满足，则身份认证通过；若其中任何一项不能验证通过均告验证失败，拒绝该用户的登录请求。

  相比RSA认证，DSA认证采用数字签名算法进行加密，具有更广泛的应用性。

  • 在SSH中，很多工具仅支持使用DSA进行服务器和客户端认证。

  • 按照最新的SSH RFC定义，DSA认证比RSA更优先被选择使用。

• Password认证

  Password身份认证是基于“用户名＋口令”的一种认证方式。

  在服务器端由AAA为每一个合法用户分配一个用于登录时进行身份验证的口令，即在服务器端存在“用户名＋口令”的一一对应的关系。当某个用户请求登录时，服务器需要对用户名以及其口令分别进行鉴别，其中任何一项不能验证通过均告验证失败，拒绝该用户的登录请求。

• RSA-Password认证和DSA-Password认证

  SSH服务器可以要求客户端进行身份认证的过程中同时进行Publickey身份认证和Password身份认证，只有当两者同时满足的情况下，才认为客户端身份认证通过。

• ALL认证

  服务器可以要求客户端进行身份认证的过程中进行公钥认证或密码认证，只要满足其中一个认证，就认为客户端身份认证通过。

设备中支持的SSH特性

• 支持基本的SSH协议

  • 支持进入、外出使用不同加密算法。

  • 支持进入、外出使用不同MAC算法。

  • 支持3DES-cbc、DES、AES128（Advanced Encryption Standard）加密算法。

  • 支持HMAC-sha1验证算法。

  • 支持diffie-hellman-group1-sha1密钥交换算法。

  • 支持SSH-RSA公钥格式。

  • 支持SSH-DSA公钥格式。

  • 支持密钥重交换Key Re-Exchange：重新进行密钥协商，协商的内容包括：使用的算法、算法使用的密钥。

  • 支持Public key、Password认证方式。

• SSH支持的客户端功能

  SSH客户端功能允许用户与支持SSH Server的设备、UNIX主机等建立SSH连接。如图1-7、图1-8所示，可以建立SSH通道进行本地连接或广域网连接。

  图1-7  在局域网内建立SSH通道
  
  
  图1-8  通过广域网建立SSH通道
  
  

• 支持SFTP协议

  SFTP协议基于SSH2。在一个传统不安全的网络环境中，服务器通过对客户端的认证及双向的数据加密，为网络文件传输提供了安全的服务。

  设备支持的SFTP协议有如下功能：

  • 支持SFTP客户端、服务器功能。

  • 支持使能/去使能SFTP服务器功能（默认关闭）。

  • 支持对应用户的SFTP访问默认目录设定。

• 支持SCP协议

  SCP协议基于SSH2。在一个传统不安全的网络环境中，服务器通过对客户端的认证及双向的数据加密，为网络文件传输提供了安全的服务。

  设备支持的SCP协议有如下功能：

  • 支持SCP客户端、服务器功能。

  • 支持使能/去使能SCP服务器功能（默认关闭）。

• 支持STelnet协议

  设备支持的STelnet协议有如下功能：

  • 支持STelnet客户端、STelnet服务器功能。

  • 支持使能/去使能SSH Telnet服务器功能（默认关闭）。

• SSH服务支持其他端口

  SSH协议的标准监听端口号为22，攻击者不断访问标准端口，导致带宽和服务器性能的下降，其他正常用户无法访问，这是一种DoS（拒绝服务）攻击。

  设定SSH服务端的监听端口号为其他端口，攻击者不知道SSH监听端口号的更改，有效防止攻击者对SSH服务标准端口访问消耗带宽和系统资源。正常用户通过对非标准端口的SSH服务的访问，降低DoS（拒绝服务）攻击可能性。

  SSH服务支持其他端口，有如下应用：

  • STelnet/SFTP客户端支持指定其他端口号访问。

  • SSH服务器支持监听端口号的设定。

SSH协议的基本原理

SSH采用了传统Client/Server应用模型，其安全特性通过以下方式保证。

数据加密：通过Client/Server协商交换生成的Encryption Key，实现对数据报文的对称加密，确保数据在传输过程中的机密性。

数据完整性：通过Client/Server协商交换生成的Integrity Key唯一标识一条会话链路，所有会话交互报文被IntegrityKey标识。一旦数据被第三方修改，接收方就能够检查出来，并丢弃报文，确保数据在传输过程中的完整性。

权限认证：通过提供多种认证方式，确保惟有认证通过的合法用户才能和Server进行会话，提高系统安全，同时保障合法用户的权益。

SSH处理流程

SSH连接在整个通讯过程中，经过如图1-9所示六个阶段，协商实现SSH认证安全连接，下面介绍一下SSH协商阶段的整个过程。

图1-9  SSH连接协商过程

1. 版本协商阶段

   SSH Client向Server发起TCP连接请求。TCP连接建立后，SSH Server和Client之间协商版本号。协商出匹配的版本协议，对不同版本协议走不同的状态机流程。如果版本匹配，进入密钥协商阶段；否则SSHServer断开TCP连接。

2. 算法协商

   当进入算法协商过程后，发送方向接收方发送算法协商消息包，发送方同时将随机Cookie、密钥交换的算法、主机密钥算法、支持的MAC（MessageAuthentication Code）认证方法以及支持的语言等作为消息的参数发送给接受方。

   接收方等待接收到发送方的算法协商消息后，将发送方的算法列表集合与本地算法列表集合相比较。若密钥交换算法、公钥加密算法和MAC算法当中有一项没有找到，则断开与发送方的连接，算法协商失败。

3. 密钥交换阶段

   当算法协商通过后，进入密钥交换阶段。双方开始计算会话ID。客户端随机生成一个32字节的会话密钥（sessionkey），用该密钥的前16字节异或（XOR）会话ID的16字节，后16字节不变，所得结果按MSB排列成一个MP型整数。用主机公钥和服务器公钥中模数较小的公钥进行加密，把结果按MSBfirst顺序排列成一个MP型整数，用模数较大的公钥进行加密，并把所得结果和客户端选择的加密算法、服务器传来的8字节Cookie、自身的协议标志一起发给服务器端。

   会话过程中，大数据量传输必须使用处理速度较快的对称密钥算法。对称加解密需要共享密钥，密钥交换流程目的是在不安全的通道中安全传送会话密钥。

   服务器处于等待状态，当收到客户端发送的密钥生成消息包后，服务器回送一个密钥生成消息给客户端，表示密钥交换完成，采用新的密钥进行通讯。如果失败，则返回密钥交换失败消息，并断开连接。

4. 认证阶段

   在计算出会话密钥后，SSH Server对Client进行用户身份验证。SSH Client向Server发送用户身份信息。如果SSHServer上配置该用户无需验证，则直接进入请求会话阶段；如果在SSH Server上配置对该用户进行验证，Client将采用配置的验证方法向Server提出验证请求，直到验证通过或连接超时断开。

   SSH Server提供六种验证方法：RSA、Password、RSA-Password、DSA、DSA-Password和ALL。

   • 在RSA认证方式下，用户客户端程序生成一个RSA密钥对，并将公钥部分发送给服务器端。用户发起认证请求时，客户端程序随机生成一段有私钥加密的密文并发送给服务器端，服务器端利用公钥对其进行解密，解密成功就认为用户是可信的，随机对用户授予相应得访问权限。否则，中断连接。

   • 在DSA认证方式下，用户客户端程序生成一个DSA密钥对，并将公钥部分发送给服务器端。用户发起认证请求时，客户端程序随机生成一段有私钥加密的密文并发送给服务器端，服务器端利用公钥对其进行解密，解密成功就认为用户是可信的，随机对用户授予相应得访问权限。否则，中断连接。

   • Password认证依靠AAA实现，与Telent和FTP类似，支持本地数据库和远程RADIUS服务器验证，SSH Server对来自Client的用户名/口令和预先配置的用户名/口令进行比较，如果完全匹配则验证通过。

5. 会话请求阶段

   认证完成后，客户端向服务器提交会话请求。会话请求包含shell和命令。服务器则进行等待，处理客户端的请求。在这个阶段，无论什么请求只要成功处理了，服务器都向客户端回应认证成功消息；否则回应认证失败消息，这表示认证失败。

   认证失败的原因如下：

   • 服务器处理请求失败

   • 服务器不能识别请求

6. 交互会话阶段

   会话申请成功后，连接进入交互会话模式。在这个模式下，数据在两个方向上双向传送。

   1. 客户端将要执行的命令加密后打包传给服务器。
   2. 服务器接收到报文，解密后执行该命令，并将执行的结果加密、打包、发还给客户端。
   3. 客户端将接收到的结果解密后显示到终端上。

概述

安全套接层SSL（Secure Sockets Layer）协议是在Internet基础上提供的一种保证私密性的安全协议。它能使客户端与服务器之间的通信不被攻击者窃听，并且始终对服务器进行认证，还可选择对客户端进行认证。

SSL协议与应用层协议相互独立，应用层协议（例如：HTTP，FTP）能透明的建立于SSL协议之上。SSL协议在应用层协议通信之前就已经完成加密算法、通信密钥的协商以及服务器认证工作。在此之后应用层协议所传送的数据都会被加密，从而保证通信的私密性。

协议安全机制

• 连接的私密性

  SSL利用对称加密算法对传输数据进行加密，并利用密钥交换算法—RSA（Rivest Shamir and Adleman，非对称密钥算法的一种）加密传输对称密钥算法中使用的密钥。

• 身份验证机制

  基于证书利用数字签名方法对服务器和客户端进行身份验证，其中客户端的身份验证是可选的。SSL服务器和客户端通过PKI（Public Key Infrastructure，公钥基础设施）提供的机制从CA（Certificate Authority，认证机构）获取证书。

• 内容的可靠性

  消息传输过程中使用基于密钥的MAC（Message Authentication Code，消息验证码）来检验消息的完整性。

  MAC算法是将密钥和任意长度的数据转换为固定长度数据的一种算法。

  • 发送端在密钥参与下，利用MAC算法计算出消息的MAC值，并将其加在消息之后发送给接收端。
  • 接收端利用同样的密钥和MAC算法计算出消息的MAC值，并与接收到的MAC值比较。

  如果二者相同，则报文没有改变。否则，报文在传输过程中被修改，接收端将丢弃该报文。

协议工作过程

• SSL协议结构

  如图1-10所示，SSL位于应用层和传输层之间，它可以为任何基于TCP等可靠连接的应用层协议提供安全性保证。SSL协议分为两层：底层是SSL记录协议（SSL record protocol）；上层是SSL握手协议（SSL handshake protocol）、SSL密码变化协议（SSL change cipher spec protocol）和SSL警告协议（SSLalert protocol）。

  图1-10  SSL协议栈
  
  • SSL记录协议：主要负责对上层的数据进行分块、计算并添加MAC、加密，最后把记录块传输给对方。
  • SSL握手协议：是SSL协议非常重要的组成部分，用来协商通信过程中使用的加密套件（对称加密算法、密钥交换算法和MAC算法等）、在服务器和客户端之间安全地交换密钥，实现服务器和客户端的身份验证。客户端和服务器通过握手协议建立一个会话，会话包含一组参数，主要有会话ID、对方的证书、加密套件（包括密钥交换算法、数据加密算法和MAC算法）及主密钥。
  • SSL密码变化协议：客户端和服务器端通过密码变化协议通知接收方，随后的报文都将使用新协商的加密套件和密钥进行保护和传输。
  • SSL警告协议：用来允许一方向另一方报告告警信息。消息中包含告警的严重级别和描述。

• SSL握手过程

  SSL通过握手过程在客户端和服务器之间协商会话参数，并建立会话。会话包含的主要参数有会话ID、对方的证书、加密套件（密钥交换算法、数据加密算法和MAC算法等）以及主密钥。通过SSL会话传输的数据，都将采用该会话的主密钥和加密套件进行加密、计算MAC等处理。

  不同情况下，SSL握手过程存在差异。下面将分别描述以下三种情况下的握手过程：

  • 只验证服务器的SSL握手过程

    图1-11  只验证服务器的SSL握手过程示意图
    
    如图1-11所示，只需要验证SSL服务器身份，不需要验证SSL客户端身份时，SSL的握手过程如下：

    1. SSL客户端通过Client Hello消息将它支持的SSL版本、加密算法、密钥交换算法、MAC算法等信息发送给SSL服务器。
    2. SSL服务器确定本次通信采用的SSL版本和加密套件，并通过Server Hello消息通知给SSL客户端。如果SSL服务器允许SSL客户端在以后的通信中重用本次会话，则SSL服务器会为本次会话分配会话ID，并通过Server Hello消息发送给SSL客户端。
    3. SSL服务器将携带自己公钥信息的数字证书通过Certificate消息发送给SSL客户端。
    4. SSL服务器发送Server Hello Done消息，通知SSL客户端版本和加密套件协商结束，开始进行密钥交换。
    5. SSL客户端验证SSL服务器的证书合法后，利用证书中的公钥加密SSL客户端随机生成的密钥，并通过Client Key Exchange消息发送给SSL服务器。
    6. SSL客户端发送Change Cipher Spec消息，通知SSL服务器后续报文将采用协商好的密钥和加密套件进行加密和MAC计算。
    7. SSL客户端计算已交互的握手消息（除Change Cipher Spec 消息外所有已交互的消息）的Hash值，利用协商好的密钥和加密套件处理Hash值（计算并添加MAC值、加密等），并通过Finished消息发送给SSL服务器。SSL服务器利用同样的方法计算已交互的握手消息的Hash值，并与Finished消息的解密结果比较，如果二者相同，且MAC 值验证成功，则证明密钥和加密套件协商成功。
    8. 同样地，SSL服务器发送Change Cipher Spec消息，通知SSL客户端后续报文将采用协商好的密钥和加密套件进行加密和MAC计算。
    9. SSL服务器计算已交互的握手消息的Hash值，利用协商好的密钥和加密套件处理Hash值（计算并添加MAC 值、加密等），并通过Finished消息发送给SSL客户端。SSL客户端利用同样的方法计算已交互的握手消息的Hash值，并与Finished消息的解密结果比较，如果二者相同，且MAC值验证成功，则证明密钥和加密套件协商成功。

    SSL客户端接收到SSL服务器发送的Finished消息后，如果解密成功，则可以判断SSL服务器是数字证书的拥有者，即SSL服务器身份验证成功。因为只有拥有私钥的SSL服务器才能从Client Key Exchange消息中解密得到密钥，从而间接地实现了SSL客户端对SSL服务器的身份验证。

    说明：

    • Change Cipher Spec消息属于SSL密码变化协议，其他握手过程交互的消息均属于SSL握手协议，统称为SSL握手消息。
    • 计算Hash值，指的是利用Hash算法（MD5或SHA）将任意长度的数据转换为固定长度的数据。

  • 验证服务器和客户端的SSL握手过程

    图1-12  验证服务器和客户端的SSL握手过程示意图
    
    SSL客户端的身份验证是可选的，由SSL服务器决定是否验证SSL客户端的身份。如图1-12中蓝色部分标识的内容所示，如果SSL服务器验证SSL客户端身份，则SSL服务器和SSL客户端除了只验证服务器的SSL握手过程中的消息协商密钥和加密套件外，还需要进行以下操作：

    1. SSL服务器发送CertificateRequest消息，请求SSL客户端将其证书发送给SSL服务器。
    2. SSL客户端通过Certificate消息将携带自己公钥的证书发送给SSL服务器。SSL服务器验证该证书的合法性。
    3. SSL客户端计算已交互的握手消息、主密钥的Hash值，利用自己的私钥对其进行加密，并通过Certificate Verify消息发送给SSL服务器。
    4. SSL服务器计算已交互的握手消息、主密钥的Hash值，利用SSL客户端证书中的公钥解密Certificate Verify消息，并将解密结果与计算出的Hash值比较。如果二者相同，则SSL客户端身份验证成功。

  • 恢复原有会话的SSL握手过程

    图1-13  恢复原有会话的SSL握手过程示意图
    
    协商会话参数、建立会话的过程中，需要使用非对称密钥算法来加密密钥、验证通信对端的身份，计算量较大，占用了大量的系统资源。为了简化SSL握手过程，SSL允许重用已经协商过的会话，如图1-13所示，具体过程如下：

    1. SSL客户端发送Client Hello消息，消息中的会话ID设置为计划重用的会话的ID。
    2. SSL服务器如果允许重用该会话，则通过在Server Hello消息中设置相同的会话ID来应答。这样，SSL客户端和SSL服务器就可以利用原有会话的密钥和加密套件，不必重新协商。
    3. SSL客户端发送Change Cipher Spec消息，通知SSL服务器后续报文将采用原有会话的密钥和加密套件进行加密和MAC计算。
    4. SSL客户端计算已交互的握手消息的Hash值，利用原有会话的密钥和加密套件处理Hash值，并通过Finished消息发送给SSL服务器，以便SSL服务器判断密钥和加密套件是否正确。
    5. 同样地，SSL服务器发送Change Cipher Spec消息，通知SSL客户端后续报文将采用原有会话的密钥和加密套件进行加密和MAC计算。
    6. SSL服务器计算已交互的握手消息的Hash值，利用原有会话的密钥和加密套件处理Hash值，并通过Finished消息发送给SSL客户端，以便SSL客户端判断密钥和加密套件是否正确。

基本原理

两阶段生效模式，就是通过两个阶段的操作过程配置才能生效。如图1-14所示，两阶段生效模式分两个步骤进行：

图1-14  两阶段生效模式的步骤示意图

1. 第一阶段用户输入配置命令，系统在候选数据集中进行数据类型、用户级别、操作对象检查，同时进行重复配置检查。对于语法或者语义错误的配置语句，系统将在终端上显示提示信息，提醒用户配置错误及错误原因。

2. 第二阶段用户提交配置，系统进入配置的提交阶段。系统提交候选数据集中的配置到运行数据集。

   • 如果业务生效成功，系统将该配置合并到运行数据集。

   • 如果业务生效失败，系统将提示用户配置错误的信息。用户可以重新输入配置命令修改配置，然后重新提交。

两阶段生效模式中的几个概念如下：

• 运行数据集

  系统当前运行的配置的集合。

• 候选数据集

  在两阶段生效模式的功能中，系统为每一位用户在设备的内存中创建运行数据集的镜像，即候选数据集。用户可以在其中进行配置编辑，确认编辑完成后，将配置提交至运行数据集。

合法性检查

用户在进入系统视图后，系统为每个用户分配一个候选数据集。用户在分配的候选数据集中进行配置，同时系统基于当前用户的配置，进行合法性检查。

两阶段生效模式可以检查配置是否合法，并提示用户错误信息。合法性的检查包括如下几项：

• 重复的配置

  系统会检测候选数据集中的配置是否与运行数据集中的一致。

  • 如果一致，则系统无需提交，并且提示有哪些重复的配置命令。

  • 如果不一致，则系统提交用户的配置至运行数据集。

• 数据类型不合法

• 用户级别无权执行某些命令

• 操作的对象不存在

多用户并行执行

如图1-15所示，多个用户可以对同一台设备进行并行配置。

图1-15  多用户并行执行两阶段生效模式的示意图

使用价值

两阶段生效模式具有以下使用价值：

• 用户要求对业务的配置能够整体生效。

• 用户可以预览候选数据集里面的配置。

• 用户在预览配置后发现业务配置产生错误或配置不符合用户预期时，能够立即清除未生效的配置。

• 用户要求把配置过程对现有业务的影响降到最低。