安全套接层
(SSL)
协议
19808016
常欣
一．协议的起源
随着计算机网络技术向整个经济社会各层次延伸，整个社会表现对
Internet
、
Intranet
、
Extranet
等使用的更大的依赖性。随着企业间信息交互的不断增加，任何一种网络应用和增值服务的使用程度将取决于所使用网络的信息安全有无保障，网络安全已成为现代计算机网络应用的最大障碍，也是急需解决的难题之一。
由于
Web
上有时要传输重要或敏感的数据，因此
Netscape
公司在推出
Web
浏览器首版的同时，提出了安全通信协议
SSL(Secure Socket Layer),
目前已有
2.0
和
3.0
版本。
SSL
采用公开密钥技术。其目标是保证两个应用间通信的保密性和可靠性
,
可在服务器和客户机两端同时实现支持。目前，利用公开密钥技术的
SSL
协议，并已成为
Internet
上保密通讯的工业标准。现行
Web
浏览器普遍将
HTTP
和
SSL
相结合，从而实现安全通信。
二．协议概述
安全套接层协议
(SSL)
是在
Internet
基础上提供的一种保证私密性的安全协议。它能使客户
/
服务器应用之间的通信不被攻击者窃听，并且始终对服务器进行认证，还可选择对客户进行认证。
SSL
协议要求建立在可靠的传输层协议
(
例如：
TCP)
之上。
SSL
协议的优势在于它是与应用层协议独立无关的。高层的应用层协议
(
例如：
HTTP
，
FTP
，
TELNET
。。。。。。
)
能透明的建立于
SSL
协议之上。
SSL
协议在应用层协议通信之前就已经完成加密算法、通信密钥的协商以及服务器认证工作。在此之后应用层协议所传送的数据都会被加密，从而保证通信的私密性。
通过以上叙述，
SSL
协议提供的安全信道有以下三个特性：
?
私密性。因为在握手协议定义了会话密钥后，所有的消息都被加密。
?
确认性。因为尽管会话的客户端认证是可选的，但是服务器端始终是被认证的。
?
可靠性。因为传送的消息包括消息完整性检查
(
使用
MAC)
。
三．协议规范
SSL
协议由
SSL
记录协议和
SSL
握手协议两部分组成。
1.
SSL
记录协议：
在
SSL
协议中，所有的传输数据都被封装在记录中。记录是由记录头和长度不为
0
的记录数据组成的。所有的
SSL
通信包括握手消息、安全空白记录和应用数据都使用
SSL
记录层。
SSL
记录协议包括了记录头和记录数据格式的规定。
1)
SSL
记录头格式：
SSL
的记录头可以是两个或三个字节长的编码。
SSL
记录头的包含的信息包括：记录头的长度、记录数据的长度、记录数据中是否有粘贴数据。其中粘贴数据是在使用块加密算法时，填充实际数据，使其长度恰好是块的整数倍。最高位为
1
时，不含有粘贴数据，记录头的长度为两个字节，记录数据的最大长度为
32767
个字节；最高位为
0
时，含有粘贴数据，记录头的长度为三个字节，记录数据的最大长度为
16383
个字节。
当数据头长度是三个字节时，次高位有特殊的含义。次高位为
1
时，标识所传输的记录是普通的数据记录；次高位为
0
时，标识所传输的记录是安全空白记录
(
被保留用于将来协议的扩展）。
记录头中数据长度编码不包括数据头所占用的字节长度。记录头长度为两个字节的记录长度的计算公式：记录长度＝
((byte[0] & 0x7f) << 8)) | byte[1]
。其中
byte[0]
、
byte[1]
分别表示传输的第一个、第二个字节。记录头长度为三个字节的记录长度的计算公式：记录长度＝
((byte[0] & 0x3f) << 8)) | byte[1]
。其中
byte[0]
、
byte[1]
的含义同上。判断是否是安全空白记录的计算公式：
(byte[0] & 0x40) != 0
。粘贴数据的长度为传输的第三个字节。
2)
SSL
记录数据的格式：
SSL
的记录数据包含三个部分：
MAC
数据、实际数据和粘贴数据。
MAC
数据用于数据完整性检查。计算
MAC
所用的散列函数由握手协议中的
CIPHER
－
CHOICE
消息确定。若使用
MD2
和
MD5
算法，则
MAC
数据长度是
16
个字节。
MAC
的计算公式：
MAC
数据＝
HASH[
密钥，实际数据，粘贴数据，序号
]
。当会话的客户端发送数据时，密钥是客户的写密钥
(
服务器用读密钥来验证
MAC
数据
)
；而当会话的客户端接收数据时，密钥是客户的读密钥
(
服务器用写密钥来产生
MAC
数据
)
。序号是一个可以被发送和接收双方递增的计数器。每个通信方向都会建立一对计数器，分别被发送者和接收者拥有。计数器有
32
位，计数值循环使用，每发送一个记录计数值递增一次，序号的初始值为
0
。
2.
SSL
握手协议：
SSL
握手协议包含两个阶段，第一个阶段用于建立私密性通信信道，第二个阶段用于客户认证。
1)
第一阶段：
第一阶段是通信的初始化阶段，通信双方都发出
HELLO
消息。当双方都接收到
HELLO
消息时，就有足够的信息确定是否需要一个新的密钥。若不需要新的密钥，双方立即进入握手协议的第二阶段。否则，此时服务器方的
SERVER
－
HELLO
消息将包含足够的信息使客户方产生一个新的密钥。这些信息包括服务器所持有的证书、加密规约和连接标识。若密钥产生成功，客户方发出
CLIENT
－
MASTER
－
KEY
消息，否则发出错误消息。最终当密钥确定以后，服务器方向客户方发出
SERVER
－
VERIFY
消息。因为只有拥有合适的公钥的服务器才能解开密钥。下图为第一阶段的流程：
|
发出
CLIENT
－
MASTER
－
KEY
消息
|
等待
CLIENT
－
MASTER
－
KEY
消息
|
|
需要注意的一点是每一通信方向上都需要一对密钥，所以一个连接需要四个密钥，分别为客户方的读密钥、客户方的写密钥、服务器方的读密钥、服务器方的写密钥。
2)
第二阶段：
第二阶段的主要任务是对客户进行认证，此时服务器已经被认证了。服务器方向客户发出认证请求消息：
REQUEST
－
CERTIFICATE
。当客户收到服务器方的认证请求消息，发出自己的证书，并且监听对方回送的认证结果。而当服务器收到客户的认证，认证成功返回
SERVER
－
FINISH
消息，否则返回错误消息。到此为止，握手协议全部结束。
3.
典型的协议消息流程：
|
消息名
|
方向
|
内容
|
|
不需要新密钥
|
|
CLIENT
－
HELLO
|
C
－
>S
|
challenge, session_id, cipher_specs
|
|
SERVER
－
HELLO
|
S
－
>C
|
connection-id, session_id_hit
|
|
CLIENT
－
FINISH
|
C
－
>S
|
E
client_write_key
[connection-id]
|
|
SERVER-VERIFY
|
S
－
>C
|
E
server_write_key
[challenge]
|
|
SERVER
－
FINISH
|
S
－
>C
|
E
server_write_key[
session_id]
|
|
需要新密钥
|
|
CLIENT
－
HELLO
|
C
－
>S
|
challenge, cipher_specs
|
|
SERVER
－
HELLO
|
S
－
>C
|
connection-id,server_certificate,cipher_specs
|
|
CLIENT
－
MASTER
－
KEY
|
C
－
>S
|
E
server_public_key[
master_key]
|
|
CLIENT
－
FINISH
|
C
－
>S
|
E
client_write_key[
connection-id]
|
|
SERVER
－
VERIFY
|
S
－
>C
|
E
server_write_key[
challenge]
|
|
SERVER
－
FINISH
|
S
－
>C
|
E
server_write_key[
new_session_id]
|
|
需要客户认证
|
|
CLIENT
－
HELLO
|
C
－
>S
|
challenge, session_id, cipher_specs
|
|
SERVER
－
HELLO
|
S
－
>C
|
connection-id, session_id_hit
|
|
CLIENT
－
FINISH
|
C
－
>S
|
E
client_write_key
[connection-id]
|
|
SERVER-VERIFY
|
S
－
>C
|
E
server_write_key
[challenge]
|
|
REQUEST
－
CERTIFICATE
|
S
－
>C
|
E
server_write_key[
auth_type,challenge']
|
|
CLIENT
－
CERTIFICATE
|
C
－
>S
|
E
client_write_key[
cert_type,client_cert,response_data]
|
|
SERVER
－
FINISH
|
S
－
>C
|
E
server_write_key[
session_id]
|
四．相关技术：
1.
加密算法和会话密钥：
如前所述，加密算法和会话密钥是在握手协议中协商并有
CIPHER
－
CHOICE
指定的。现有的
SSL
版本中所用到的加密算法包括：
RC4
、
RC2
、
IDEA
和
DES
，而加密算法所用的密钥由消息散列函数
MD5
产生。
RC4
、
RC2
是由
RSA
定义的，其中
RC2
适用于块加密，
RC4
适用于流加密。下述为
CIPHER
－
CHIOCE
的可能取值和会话密钥的计算：
SSL_CK_RC4_128_WITH_MD5
SSL_CK_RC4_128_EXPORT40_WITH_MD5
SSL_CK_RC2_128_CBC_WITH_MD5
SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5
SSL_CK_IDEA_128_CBC_WITH_MD5
KEY-MATERIAL-0 = MD5[ MASTER-KEY, "0", CHALLENGE, CONNECTION-ID ]
KEY-MATERIAL-1 = MD5[ MASTER-KEY, "1", CHALLENGE, CONNECTION-ID ]
CLIENT-READ-KEY = KEY-MATERIAL-0[0-15]
CLIENT-WRITE-KEY = KEY-MATERIAL-1[0-15]
SSL_CK_DES_64_CBC_WITH_MD5
KEY-MATERIAL-0 = MD5[ MASTER-KEY, CHALLENGE, CONNECTION-ID ]
CLIENT-READ-KEY = KEY-MATERIAL-0[0-7]
CLIENT-WRITE-KEY = KEY-MATERIAL-0[8-15]
SSL_CK_DES_192_EDE3_CBC_WITH_MD5
KEY-MATERIAL-0 = MD5[ MASTER-KEY, "0", CHALLENGE, CONNECTION-ID ]
KEY-MATERIAL-1 = MD5[ MASTER-KEY, "1", CHALLENGE, CONNECTION-ID ]
KEY-MATERIAL-2 = MD5[ MASTER-KEY, "2", CHALLENGE, CONNECTION-ID ]
CLIENT-READ-KEY-0 = KEY-MATERIAL-0[0-7]
CLIENT-READ-KEY-1 = KEY-MATERIAL-0[8-15]
CLIENT-READ-KEY-2 = KEY-MATERIAL-1[0-7]
CLIENT-WRITE-KEY-0 = KEY-MATERIAL-1[8-15]
CLIENT-WRITE-KEY-1 = KEY-MATERIAL-2[0-7]
CLIENT-WRITE-KEY-2 = KEY-MATERIAL-2[8-15]
其中
KEY-MATERIAL-0[0-15]
表示
KEY-MATERIAL-0
中的
16
个字节，
KEY-MATERIAL-0[0-7]
表示
KEY-MATERIAL-0
中的头
8
个字节，
KEY-MATERIAL-1[8-15]
表示
KEY-MATERIAL-0
中的第
9
个字节到第
15
个字节。其他类似形式有相同的含义。
"0"
、
"1"
表示数字
0
、
1
的
ASCII
码
0x30
、
0x31
。
2.
认证算法：
认证算法采用
X
。
509
电子证书标准，通过使用
RSA
算法进行数字签名来实现的。
1)
服务器的认证：
在上述的两对密钥中，服务器方的写密钥和客户方的读密钥、客户方的写密钥和服务器方的读密钥分别是一对私有、公有密钥。对服务器进行认证时，只有用正确的服务器方写密钥加密
CLIENT-HELLO
消息形成的数字签名才能被客户正确的解密，从而验证服务器的身分。
若通信双方不需要新的密钥，则它们各自所拥有的密钥已经符合上述条件。若通信双方需要新的密钥。首先服务器方在
SERVER-HELLO
消息中的服务器证书中提供了服务器的公有密钥，服务器用其私有密钥才能正确的解密由客户方使用服务器的公有密钥加密的
MASTER-KEY
，从而获得服务器方的读密钥和写密钥。
2)
客户的认证：
同上，只有用正确的客户方写密钥加密的内容才能被服务器方用其读密钥正确的解开。当客户收到服务器方发出的
REQUEST-CERTIFICATE
消息时，客户首先使用
MD5
消息散列函数获得服务器方信息的摘要，服务器方的信息包括：
KEY-MATERIAL-0
、
KEY-MATERIAL-1
、
KEY-MATERIAL-2
、
CERTIFICATE-CHALLENAGE-DATA(
来自于
REQUEST-CERTIFICATE
消息
)
、服务器所赋予的证书
(
来自于
SERVER-HELLO)
消息。其中
KEY-MATERIAL-1
、
KEY-MATERIAL-2
是可选的，与具体的加密算法有关。然后客户使用自己的读密钥加密摘要形成数字签名，从而被服务器认证。
五．与
SET
协议的比较
在当今的电子商务中使用最为广泛的两种安全协议是
SSL
协议和
SET
协议。以下就两种协议在电子商务方面的应用作一比较。
1.
SET
协议概述：
SET
协议
(Secure Electronic Transaction
，安全电子交易
)
是由
VISA
和
MasterCard
两大信用卡公司于
1997
年
5
月联合推出的规范。
SET
主要是为了解决用户、商家和银行之间通过信用卡支付的交易而设计的，以保证支付信息的机密、支付过程的完整、商户及持卡人的合法身份、以及可操作性。
SET
中的核心技术主要有公开密匙加密、电子数字签名、电子信封、电子安全证书等。
SET
能在电子交易环节上提供更大的信任度、更完整的交易信息、更高的安全性和更少受欺诈的可能性。
SET
协议用以支持
B to C
（
Businessto Consumer
）这种类型的电子商务模式，即消费者持卡在网上购物与交易的模式。
SET
交易分三个阶段进行
:
?
在购买请求阶段，用户与商家确定所用支付方式的细节；
?
在支付的认定阶段，商家会与银行核实
,
随着交易的进展，他们将得到付款；
?
在受款阶段，商家向银行出示所有交易的细节，然后银行以适当方式转移货款。
如果不是使用借记卡，而直接支付现金，商家在第二阶段完成以后的任何时间即可以供货支付。第三阶段将紧接着第二阶段进行。用户只和第一阶段交易有关，银行与第二、三阶段有关，而商家与三个阶段都要发生关系。每个阶段都涉及到
RSA
对数据加密，以及
RSA
数字签名。使用
SET
协议，在一次交易中，要完成多次加密与解密操作，故要求商家的服务器有很高的处理能力。
2.
协议比较：
事实上，
SET
和
SSL
除了都采用
RSA
公钥算法以外，二者在其他技术方面没有任何相似之处。而
RSA
在二者中也被用来实现不同的安全目标。
SET
协议比
SSL
协议复杂，因为
SET
不仅加密两个端点间的单个会话，它还非常详细而准确地反映了卡交易各方之间存在的各种关系。
SET
还定义了加密信息的格式和完成一笔卡支付交易过程中各方传输信息的规则。事实上，
SET
远远不止是一个技术方面的协议，它还说明了每一方所持有的数字证书的合法含义，希望得到数字证书以及响应信息的各方应有的动作，与一笔交易紧密相关的责任分担。
SET
实现起来非常复杂，商家和银行都需要改造系统以实现互操作。另外
SET
协议需要认证中心的支持。
SET
是一个多方的报文协议，它定义了银行、商家、持卡人之间的必须的报文规范，与此同时
SSL
只是简单地在两方之间建立了一条安全连接。
SSL
是面向连接的，而
SET
允许各方之间的报文交换不是实时的。
SET
报文能够在银行内部网或者其他网络上传输，而
SSL
之上的卡支付系统只能与
Web
浏览器捆绑在一起。
两者相比最不安全的可以说是
SSL
，实际上当初它并不是为支持电子商务而设计的，后来为了克服其局限性在其基础上发展了
PKI
。然而就当初的设计目的而言，
SSL
和它的继任者
— —
传输层安全协议（
the transport layer security protocol
）的功能完成的非常圆满。很多银行和电子商务解决方案提供商还在谈论着使用
SSL
构建更多的安全支付系统，但是如果没有经裁剪的客户方软件的话，基于
SSL
的系统是不能到像
SET
这种专用银行卡支付协议所能达到的安全性的。
六．前景展望
就我个人观点来说，
SSL
协议与
SET
协议之争类似于
IP
与
ATM
之争。
IP
协议的应用非常广泛，实现简单成本低廉，但服务质量没有保证。
ATM
实现复杂，需要对现有的设备和应用进行改造，成本高昂，但对服务质量有保证。结果是
ATM
迟迟不能推出成熟的规范，
IP
设备迅速抢占市场。随着应用需求的增加和扩展，对服务质量要求的呼声也日益高涨。这时
CISCO
等厂商也提出
IP
上的
QoS
，并且通过扩展
IP
协议实现对
QoS
的支持。所以评价一种技术的前景，最重要的就是这种技术能不能在现有的条件下占有市场。至于这种技术是不是先进、是不是有好的扩展性等等相对来说处于次要地位。从已有的应用份额、实现成本、技术支持等影响市场占有率的最重要的因素来看，
SSL
协议已经占据了有利的形势。我对
SSL
协议的发展充满乐观。
参考文献：
1. Netscape Communication Corp Kipp E.B. Hickman
：
The SSL Protocol. Feb, 9th, 1995
2. CCITT. Recommendation X.509: "The Directory - Authentication Framework". 1988.
3. RSA Laboratories. PKCS #1: RSA Encryption Standard, Version 1.5, November 1993.
4. R. Rivest. RFC 1321: The MD5 Message Digest Algorithm. April 1992.
5.
陆首群
:
剖析
SET. 1998
posted on 2006-12-26 17:37
游子 阅读(1471)
评论(0) 编辑 收藏 引用 所属分类:
软件