5.1.1 SSL协议工作原理SSL协议处于互联网多层协议集的传输层上，运行在TCP/IP协议之上而在其他高层协议（如HTTP、Telnet、FTP和IMAP等）之下，如图5-1所示。

在建立一次SSL连接之前，首先建立TCP/IP连接。

SSL协议可以让应用层协议透明地加以应用。

运行时，支持SSL协议的服务器可以同一个支持SSL协议的客户机彼此认证自己，还允许这两个机器之间建立安全的加密连接，同时保证信息在传输过程中的完整性。

SSL协议可以分为4个子协议：SSL握手协议、SSL更改密码规程协议、SSL报警协议和SSL记录协议，其中最重要的两个协议是握手协议和记录协议。

SSL记录协议定义了数据传送的格式，它位于一些可靠的传输层协议之上（如TCP），用于各种更高层协议的封装。

SSL握手协议位于SSL记录协议之上，并被SSL记录协议所封装。

它描述建立安全连接的过程，在客户和服务器传送应用层数据之前，该协议允许服务器与客户机之间协商加密算法和会话密钥，完成通信双方的身份验证等功能。

图5-1 SSL协议的分层结构5.1.2 SSL记录协议SSL记录协议（Record Protocol）定义了传输的格式，包括记录头和记录数据格式的规定。

发送方记录层的工作过程如图5-2所示：图5-2 记录层的工作过程1.记录层从上层接收到任意大小的应用层数据块，把数据快分成不超过214字节的分片。

2.记录层用当前的会话状态中给出的压缩算法静分片压缩成一个压缩快，压缩操作是可选的。

3.每个会话都有相应“加密规格”指定了对称加密算法和MAC算法。

记录层用指定的MAC算法对压缩块计算MAC，用指定的对称加密算法加密压缩块和MAC，形成密文块。

4.对密文块添加SSL记录头，然后送到传输层，传输层受到这个SSL记录层数据单元后，记上TCP报头，得到TCP数据包。

图5-3 SSL记录协议中数据项的格式5.1.3 SSL握手协议图5-4 SSL建立新会话时的握手过程1）建立新会话时的握手过程握手协议用于数据传输之前。

它可以进行服务器与客户之间的身份鉴别，同时通过服务器和客户协商，决定采用的协议版本、加密算法，并确定加密数据所需的对称密钥，随后采用公钥加密技术产生共享机密信息（例如对称密钥）。

每次连接，握手协议都要建立一个会话。

会话中包含了一套可在多次会话中使用的加密安全参数，从而减轻了每次建立会话的负担。

然而，必须指出的是，SSL中的每次连接时，在握手协议中产生的对称密钥都是独特的，这种每次更换密钥的方法显然在更大程度上确保了系统的不易攻破性。

根据是否验证对方的证书，SSL的握手过程可以分为以下三种验证模式：客户和服务器都被验证；只验证客户机，不验证服务器，这是Internet上使用最广泛的形式；客户和服务器都不验证，也称为完全匿名模式。

SSL握手协议建立一个新的会话的过程如图5-4所示，具体如下：阶段1：确定一些相关参数，包括协议版本、会话ID、加密规格、压缩算法和初始随机数（1）客户端发送client_hello消息给服务器，向服务器传送客户端支持的SSL协议的版本号、加密算法的种类、MAC算法的种类、会话标识、密码属性（如hash块的大小），以及其他服务器和客户端之间通信所需要的各种信息。

（2）服务器以server_hello向客户应答，服务器端传选定的SSL协议的版本号、加密算法的种类、MAC算法的种类、密码属性及其他相关信息。

阶段2：服务器端发送自身证书（或临时公钥）及证书请求，最后发送hello阶段结束信号。

（3）如果需要验证服务器，服务器将发送certificate消息。

服务器首先建立一个随机数，然后对这个随机数进行数字签名，将这个含有签名的随机数和服务器的证书，放在certificate 消息中发送给客户端。

若不需要验证服务器证书，服务器发送包含其临时公钥的server_key_exchange消息。

（4）若服务器需要验证客户，则发送certificate_request消息（5）服务器发送hello_done消息，表示双方握手过程中的hello阶段结束。

阶段3：客户端验证服务器端证书、发送自身证书、交换对称密钥。

（6）客户利用服务器传过来的信息验证服务器的合法性，发送certificate_verify消息，确定验证通过。

服务器的合法性包括：证书是否过期，发行服务器证书的CA是否可靠，发行者证书的公钥能否正确解开服务器证书的“发行者的数字签名”，服务器证书上的域名是否和服务器的实际域名相匹配。

如果合法性验证没有通过，通信将断开；如果合法性验证通过，则将继续进行下一步。

（7）客户端先随机产生一个用于后面通信的预主密码（pre-master-key），然后用服务器的公钥（从服务器的证书中获得）对其加密，再将加密后的预主密码通过client_key_exchange 消息传给服务器。

（8）如果服务器要求客户的身份认证（在握手过程中为可选），客户端会首先建立一个随机数，然后对这个随机数进行数字签名，将这个含有签名的随机数和客户自己的证书放在certificate消息中，发送给服务器端。

如果客户端没有证书，则会回应no_certificate告警。

阶段4：双方确定加密规格，结束握手协议。

（9）客户端向服务器端发出chenge_cipher_spec信息，指明后面的数据通信将“预主密码”为对称密钥，同时向服务器发送finished消息，表示完成了与服务器的握手。

（10）服务器检验客户证书和签名随机数的合法性，发送certificate_verify消息。

具体的合法性验证包括：客户的证书使用日期是否有效，为客户提供证书的CA是否可靠，发行CA的公钥能否正确解开客户证书的发行CA的数字签名，检查客户的证书是否在证书撤销列表（CRL）中。

检验如果没有通过，则通信立刻中断；如果验证通过，则服务器将用自己的私钥解开加密的“预主密码”，然后执行一系列步骤来产生通信使用的主密码（master-key）（客户端也将通过同样的方法产生相同的主密码）。

（11）服务器向客户端发出change_cipher_spec信息，指明后面的数据通信将使用预主密码为对称密钥，同时发送finished消息，通知客户端服务器端的握手过程结束。

（12）SSL的握手部分结束，SSL安全通道的数据通信开始，客户和服务器开始使用相同的对称密钥进行数据通信，同时进行通信完整性的检验。

2）恢复一个已存在会话时的握手过程由上可以看出，SSL协议的握手过程是非常好使的，为了减少握手过程的交互次数，以及对网络带宽的占用，可将双方经过完整握手过程建立起来的会话状态记录下来。

在以后连接时，采用会话重用技术恢复会话过程，免去会话参数的协商。

SSL握手协议恢复一个已存在的会话的过程如图5-5所示。

客户端发送client_hello消息给服务器，其中的session id是要恢复的会话的标识，服务器在会话缓存中检查是否有这个会话标识：若有，服务器将在相应的会话状态下建立一个新的连接，服务器发送含有session id的server_hello；若没有，服务器会生成一个新的session id，建立一个新的会话过程。

当通过恢复一个会话建立一个连接时，这个新的连接将继承这个会话状态下的压缩算法、加密规格和预主密码。

但该连接会产生新的随机数和通信密码。

图5-5 SSL恢复一个已存在会话时的握手过程5.1.4 SSL协议的缺陷根据以上内容可知，SSL协议所采用的加密算法和认证算法使它具有一定的安全性，能够在一定程度上抵抗某些攻击。

除此之外SSL协议具备很强的灵活性，在浏览器中大都建有SSL功能。

但是SSL协议也有很多缺陷，具体如下：（1）密钥管理问题设计一个安全秘密的密钥交换协议是很复杂的，因此，SSL握手协议中客户机和服务器在互相发送自己能够支持的加密算法时，是以明文传送的，存在被攻击修改的可能。

（2）加密强度问题服务器证书分为高端和低端两种，高端证书加密强度比低端证书高。

SSL通信中具体达到的加密强度与客户操作系统、浏览器版本、网络服务器的所采用的证书等因素相关。

如许多客户的系统不支持128位强度的加密链接，即便服务器证书可以支持128位，客户端也自动降低加密强度，除非他采用了支持SCG技术的服务器证书（强制型），方可实现128位加密强度。

因此，客户机的性能将会影响到SSL的安全性。

（3）数字签名问题SSL协议对握手之后的通信内容没有数字签名功能，即没有抗否认服务。

若要增加数字签名功能，则需要在协议中打“补丁”。

这样做，在用于加密密钥的同时又用于数字签名，这在安全上存在漏洞。

后来PKI体系完善了这种措施，即双密钥机制，将加密密钥和数字签名密钥二者分开，成为双证书机制。

这是PKI完整的安全服务体系。

（4）必须建立在可靠连接基础上SSL协议的底层协议仅限于TCP协议。

由于SSL要求有TCP通道，所以对于使用UDP 协议的DNS类型的应用场合是不适合的。

（5）多方通信表现欠佳由于SSL的连接本质上是一对一的，所以在通信方只有两个的情况下它会工作的很好。

在多对多的环境中，它的表现欠佳。

5.2.2 双重签名双重签名是SET协议中的一个重要技术。

生成双重签名的流程如图5-7所示。

假设持卡人为C，商家为M，银行支付网关为B，则双重签名的生成过程如下：图5-7 双重签名生成过程（1）产生发订购信息OI（Order Information）和支付指令PI（Payment Information）。

（2）产生OI、PI的摘要H(OI)，H(PI)。

（3）连接H(OI)和H(PI)得到OP，（4）生成OP的摘要H(OP)，（5）用C的RSA私钥K cp签名H(OP)，得到sign[H(OP)]，称为双重签名。

通过一系列交互和加解密过程，M将获得的数据包括OI、H(P1)和sign[H(OP)]，B将获得的数据包括PI、H(OI)和sign[H(OP)] 。

下面以M为例，介绍验证双重签名的过程。

C验证双重签名的过程与此相似，不再赘述。

M验证双重签名的过程如图5-8所示，具体如下：图5-8 双重签名验证过程（1）用收到的OI，生成H' (OI)（2）将H' (OI)与接收到的摘要H (PI)连接生成OP（3）得到OP'的摘要H (OP')（4）用C公钥K cu解开Sign[H(OP)]，得到H(OP)（5）比较H (OP')与H(OP)是否相同。

如果相同，则表示数据完整且未被篡改。

在交易中持卡人发往银行的支付指令是通过商家转发的，双重签名避免了交易的过程中商家窃取持卡人的信用卡信息，也避免了行跟踪持卡人的行为，侵犯消费者隐私；同时还不影响商家和银行对持卡人所发信息的合理的验证，以及银行和商家之间的沟通，保证当商家同意持卡人的购买请求后再让银行给商家付费。