CN101860546A

CN101860546A - 一种改进ssl握手协议的方法

Info

Publication number: CN101860546A
Application number: CN 201010204035
Authority: CN
Inventors: 吴卿; 张奇锋; 倪永军; 周兴武; 金恭华; 赵俊杰; 郁伟炜; 吴鹏; 曾虹
Original assignee: Hangzhou Dianzi University
Current assignee: Hangzhou Dianzi University
Priority date: 2010-06-18
Filing date: 2010-06-18
Publication date: 2010-10-13

Abstract

本发明涉及一种改进SSL握手协议的方法。现有的握手协议方法安全性不高。本发明方法首先由安全套接层的客户端向服务器端发出一个消息；发出该消息以后，客户端等待响应；其次客户端收到响应之后，服务器端把证书序列发给客户端，服务器端选择性的设置是否认证客户端；客户端如果没有递交具有可以签名功能的证书，则握手失败，客户端如果递交了具有可以签名功能的证书，则客户端发送消息来证书认证；最后客户端向服务器端发送消息通知服务器端，服务器端也会发送消息，标志着下面将进入应用层数据传输阶段。本发明方法使握手过程中的消息交换方式更加安全，从而提高了客户端与服务器端之间传输的安全性。

Description

一种改进SSL握手协议的方法

技术领域

本发明属于网络安全领域，具体涉及一种改进网络通信中SSL握手协议的方法。

背景技术

SSL(安全套接层)协议为基于TCP/IP的客户服务器应用程序提供了客户端和服务器的鉴别、数据完整性及信息机密性等安全措施。SSL是被设计用来保证通信双方的信息安全的一个协议，它依赖于可靠的TCP传输层来传输和接收数据。

SSL协议的特点是独立于上层的应用层协议(如：HTTP，FTP，TELNET等)，这些应用层协议可以透明地使用SSL协议。SSL协议可以协商一个对称加密算法和会话密钥，同时可以在通信之前认证服务器的合法性。所有的应用层的数据都是加密后传输的。

SSL协议提供了一种“管道式安全”，它具有三个特征：

1)管道是保密的，保密性是递过使用加密技术来保证的，在通过一个简单的握手过程之后获得一个共同的密钥，作为对称加密算法的密钥。

2)管道是认证过的，服务器端总是需要把自己的证书递交给客户端，以便客户端对服务器进行认证。服务器可以选择是否需要客户端递交证书。

3)管道是可靠的，消息的传输包含了消息完整性检查(使用MAC，MessageAuthentication Code)，其中使用到摘要算法来计算消息的MAC。

SSL协议实际上由两个协议层构成，位于下面的一层为SSL记录协议(SSLRecord Protocol)，其上为SSL控制协议(SSL Control Protocols)。SSL记录协议用于封装上层发送和接收的所有数据，当然包括SSL控制协议的数据。SSL控制协议主要包括：SSL握手协议、SSL报警协议等。握手协议在客户机和服务器间执行以建立安全的连接，客户机和服务器必须就它们使用的SSL协议版本、双方理解的加密算法和密钥达成一致。报警协议是SSL记录层所支持的一种内容类型(ContentType)，它用来表示消息错误的严重程度及其内容描述。

SSL的握手过程是建立SSL的主要加密和安全参数的过程，它是SSL的控制协议执行的控制功能。

SSL握手层的作用是客户方和服务器通过数次交互，协商加密算法及确定会话密钥，同时完成客户方对服务器的身份认证。SSL握手协议包含以下两个阶段。

1)建立私密性通信信道阶段(第一阶段)

整个过程包括：Hello阶段，客户机向服务器发送Client Hello消息，服务器向客户机发送Server Hello消息；密钥交换阶段，客户机和服务器之间建立主密钥；会话密钥生成阶段，客户机送出Client Master Key并和服务器建立会话密钥；服务器证实阶段，采用RSA密钥交换算法时执行此步骤，此阶段交换的消息为Server Certificate。

2)客户认证阶段(第二阶段)

该阶段的主要任务是服务器对客户进行认证，此时服务器已经被认证了它要求客户机的证书，客户机以Client Certificate进行响应。此阶段交换的信息为Request Certificate和Client Certificate。当客户机通过送会话ID作为加密文本表示完成了认证，客户机和服务器各自交换消息ClientFinished和Server Finished。

发明内容

本发明针对SSL握手流程及其存在的安全漏洞，提供一种改进网络通信中SSL握手协议的方法。

本发明解决其技术问题所采用的关键点是：对SSL握手流程的分析后，针对其容易受到的密钥交换方式的攻击、密钥交换算法的攻击、会话重用机制的攻击、丢弃ChangeCipherSpec消息的攻击、认证消息语义的不清晰独立性攻击这几方面来解决目前SSL握手协议中存在的安全漏洞。

本发明解决上述技术问题所采取的技术方案为：

步骤(1)安全套接层(SSL)的客户端(Client)向服务器端(Server)发出的第一个消息是Client Hello；发出Client Hello以后，客户端等待一个Server Hello响应。

步骤(2)客户端收到Server Hello之后，Server把自己的证书序列发给Client，证书序列中包括从Server的证书到根证书的证书链；Server选择性的设置是否认证Client，如果选择需要认证，则需要Client递交证书，Server向Client发起证书认证请求(Certificate Request)，然后发送消息ServerHello Done，等待Client的响应。如果选择不需要认证，则跳转至步骤(1)。

步骤(3)Client接收到Server Hello Done消息后，可能接收到ClientCertificate消息，这个消息只在Server需要Client递交证书时才发送该消息。如果Client没有递交具有可以签名功能的证书，则Client将向Server发送一个No Certificate的警告，Server则向Client返回一个握手失败的消息通知握手失败。

如果Client递交了具有可以签名功能的证书之后，则Client发送Certificate verify消息用来证书认证。这实质上就是Client对Certificate.signature.md_hash或者Certiftcate.signature.sha_hash使用自己的私钥签名后传输给Server，Server接收到该签名后可以使用Client递交的证书中包含的公开密钥来检验该签名，如果签名正确，表明证书有效。

在这里，需要协商公开密钥算法来加密消息，使用RSA算法加密的数据结构为：

struct{

select(KeyExchangeAlgorithm){

case rsa：EncryptedPreMasterSecret；

case difie_hellman：ClientDifieHellmanPublic；

case fortezza_dms：FortezzaKeys；

}exchange_keys；

}ClientKeyExchange；

struct{

Public-key-encrypted PreMasterSecre；

Pre-master secret；

}EncryptedPreMasterSecret；

KeyExchangeAlgorithm用于对称加密算法密钥交换的公开密钥算法。

PreMasterSecret数据结构中包含的random是Client所产生，以后用来产生Master secrete。这个master_secret就是通过公开密钥算法交换后，在Client和Server共同拥有的一个密码，它将被用于产生对称加密算法和摘要算法的密钥。

步骤(4)Client向Server发送ChangeCipherSpec消息通知Server，下一步的信息记录传输采用协商好的算法和密钥。Finished消息的发送是紧接着ChangeCipherSpec消息的发送的，其作用是确认以上步骤的密钥和认证过程是成功的。Finished消息是第一个使用刚才协商好的算法和密钥的消息，发送该消息之后，握手双方都将立即进入应用层数据的传输阶段。

然后Server也会发送ChangeCipherSpec和Finished消息，这是Server发送给Client的最后一个握手消息，标志着下面将进入应用层数据传输阶段。

本发明的有益效果为：通过本方法，Client向Server发起握手过程的时候，改进的SSL握手协议将使握手过程中的消息交换方式更加安全，从而提高了Client与Server之间传输的安全性。

具体实施方式

一种改进SSL握手协议的方法，包括如下步骤：

步骤(1)安全套接层(SSL)的客户端(Client)向服务器端(Server)发出的第一个消息是Client Hello；发出Client Hello以后，客户端等待一个Server Hello响应；这里SSL握手协议可能会受到密钥交换方式的攻击，需要对其进行改进。

SSL握手协议主要负责用于客户机和服务器之间会话的加密参数。ClientHello消息和Sever Hello消息中的密码组参数的第一个元素是密钥交换方法。SSL协议支持如下密钥交换方法：

RSA：用接收者的RSA公钥加密的密钥，必须拥有接收者公钥的公钥证书。

固定Diffie-Hellman：Diffie-Hellman密钥交换包含认证中心签发的Diffie-Hellman公钥参数的服务器证书。

瞬时Diffie-Hellman：用于创建瞬时(临时)的密钥。Diffie-Hellman公钥早交换时使用发送者的RSA或者DSS私钥签名，接收者使用相应的公钥验证签名。

匿名Diffie-Hellman：使用基本的Diffie-Hellman算法，没有认证。

Fortezza：为Fortezza模式定义的技术。

SSL握手协议中提供了完全匿名密钥交换方式，SSL提供这种匿名密钥交换方式的目的是使协议能够应用在协议双方都没有证书的情况下，以增强协议的实用性。但是这种方法容易受到中间人攻击，攻击者可以使用匿名Diffie-Hellman与双方进行会话。如果客户端不能提供身份认证或者不能获得服务器证书的有效性检验，攻击者利用这种中间人攻击的方法就可以完全偷听会话内容。

因此，对SSL握手协议做以下修改：去掉完全匿名的密钥交换方式，应用Kerberos认证协议来进行客户端和服务器的双向认证。最后，客户端和服务器共享一个密钥，该密钥可以用于加密在他们之间传输的消息，或者交换新的随机会话密钥。

步骤(2)客户端收到Server Hello之后，Server把自己的证书序列发给Client，证书序列中包括从Server的证书到根证书的证书链；Server选择性的设置是否认证Client，如果选择需要认证，则需要Client递交证书，Server向Client发起证书认证请求(Certificate Request)，然后发送消息ServerHello Done，等待Client的响应。如果选择不需要认证，则跳转至步骤(1)；

struct{

select(KeyExchangeAlgorithm){

case rsa：EncryptedPreMasterSecret；

case difie_hellman：ClientDifieHellmanPublic；

case fortezza_dms：FortezzaKeys；

}exchange_keys；

}ClientKeyExchange；

struct{

Public-key-encrypted PreMasterSecre；

Pre-master secret；

}EncryptedPreMasterSecret；

服务器用server_key_exchange消息来发送临时公共密钥参数，客户使用这些公开参数和服务器交换密钥，获得共享的主密钥。协议规定可以使用多种密钥交换算法，例如RSA算法和Diffie-Hellman算法。可是“密钥交换算法”类型这个域，并不在服务器对公开参数的签名中，这样攻击者可以滥用服务器对DH参数的签名来欺骗客户，使之认为服务器发送了对RSA参数的签名。这时，通信双方认为已经成功协商了一个密码族，事实上它们各自认定的密码族却是不同的。攻击者使用密码族反转攻击，使服务器使用临时的DH密钥交换，而客户使用临时的RSA密钥交换。客户将使用假的RSA参数加密pre_master_secret发送给服务器。这样，攻击者可以容易地还原pre_master_secret，此后的通信安全将被击溃。

这种安全缺陷也可以通过协议实现者的特殊处理加以避免。协议实现者需要在接收到key_exchange消息时仔细检查公开参数域的长度，这样就能够区分所使用的密钥交换算法，从而避免这种攻击。

SSL握手协议为了减少通讯开销采用了会话重用机制，即协议的参与者不必完成一个完整的握手过程来协商会话密钥，可以重用先前的会话中已经商定的秘密消息pre_master_secert，只要重新交换两个临时随机数，就可以分别利用pre_master_secert生成新的会话密钥和MAC秘密。这样做的目的是减少协议的通讯开销，但是同时也给攻击者带来了可趁之机。如果SSL协议是使用在诸如Telnet应用等会话时间比较长的环境中时，就可能存在安全问题，特别是在协议参与方协商了安全强度较弱的密码算法时，攻击者就可能有时间进行会话密钥的穷搜攻击。

因此，改进协议中对一个会话应该设置一定的超时限制。当会话持续时间超过这个限制时，服务器应当向客户发送一条消息(可以使用hello_request消息)，强迫协议双方重新发起一个完整的握手过程。

步骤(4)Client向Server发送ChangeCipherSpec消息通知Server，下一步的信息记录传输采用协商好的算法和密钥。Finished消息的发送是紧接着ChangeCipherSpec消息的发送的，其作用是确认以上步骤的密钥和认证过程是成功的。该消息是第一个使用刚才协商好的算法和密钥的消息。发送该消息之后，握手双方都将立即进入应用层数据的传输阶段。

在这个步骤中，SSL握手协议完成阶段有一个小的疏漏，即在Finished消息中没有对ChangeCipherSpec消息的认证保护。在接收到该消息之前，当前的密码族概不加密、不作MAC保护，在接收到ChangeCipherSpec消息之后，记录层才开始对通信数据进行加密和完整性保护。假如只对密码族进行认证而不加密，易被攻击者截获并删除该消息，致使通信双方将不再更新当前的密码族，即不再对传送的数据作MAC认证或加密。由于商定的密码族不起作用，攻击者在通信双方不知道的情况下，可以随心所欲地篡改会话数据。

如果对通信双方商定的密码族进行加密，该攻击就不容易实现了。因为客户发送的Finished消息是加密的，而服务器期望接收的Finished消息是不加密的，攻击者为了得到认证码，不仅需要剥掉该消息的认证码，还要获得会话加密密钥。因此，只有当系统使用弱的密码算法时，攻击者才有可能进行密钥穷举搜索获得成功。避免上述攻击的根本方法，是将ChangeCipherSpec加入到Finished消息的消息认证计算中。

SSL协议认证的目的是建立协议参与双方之间的共享秘密，协议的消息含义应该遵循清晰独立性原则，即每条消息都要能够表达出它想表达的含义，消息的解释应该只依赖与消息本身而不是协议的上下文。但是在协议的描述中，并没有在遵循这个原则上花费心思，例如，协议中许多地方都要求计算“所有以前握手消息”的Hash值，这种要求是模糊和武断的，正是由于这种模糊性，才导致change_cipher_suite攻击和key_exchange algorithm攻击。协议中应当明确指出需要对哪些关键消息以及消息中的哪些关键部分进行认证。

对于上述缺陷，做如下改进。在client finished消息和server finished消息中加入对ChangeCipherSpec这个消息的认证。将server_key_exchange消息的结构进行修改如下：

Enum{diffie_hellman，rsa}KeyExchangeAlgorithm；

struct{

KeyExchangeAlgorithm type；

select(type){

case rsa：

ServerRSAParama params；

Signature signed_params；

case difie_hellman：

ServerDHParams params；

Signature signed_params

}；

}ServerKeyExchange；

从以上五方面对SSL握手协议中的安全漏洞进行改进，使得SSL握手协议具有更好的安全性。

Claims

1.一种改进SSL握手协议的方法，其特征在于该方法包括如下步骤：

步骤(1)安全套接层的客户端向服务器端发出第一个消息Client Hello；发出该消息以后，客户端等待一个Server Hello响应；

步骤(2)客户端收到Server Hello之后，服务器端把自己的证书序列发给客户端，证书序列中包括从服务器端的证书到根证书的证书链；服务器端选择性的设置是否认证客户端，如果选择需要认证客户端，则需要客户端递交证书，服务器端向客户端发起证书认证请求，然后发送消息Server Hello Done，等待客户端的响应；如果选择不需要认证客户端，则跳转至步骤(1)；

步骤(3)客户端接收到Server Hello Done消息后，如果客户端没有递交具有可以签名功能的证书，则客户端将向服务器端发送一个No Certificate的警告，服务器端则向客户端返回一个握手失败的消息通知握手失败；

如果客户端递交了具有可以签名功能的证书之后，则客户端发送Certificate verify消息用来证书认证，这实质上就是客户端对Certificate.signature.md_hash或者Certiftcate.signature.sha_hash使用自己的私钥签名后传输给服务器端，服务器端接收到该签名后可以使用客户端递交的证书中包含的公开密钥来检验该签名，如果签名正确，表明证书有效；

步骤(4)客户端向服务器端发送ChangeCipherSpec消息通知服务器端，下一步的信息记录传输采用协商好的算法和密钥，Finished消息的发送是紧接着ChangeCipherSpec消息的发送的，其作用是确认以上步骤的密钥和认证过程是成功的；Finished消息是第一个使用刚才协商好的算法和密钥的消息，发送该消息之后，握手双方都将立即进入应用层数据的传输阶段；

然后服务器端也会发送ChangeCipherSpec和Finished消息，这是服务器端发送给客户端的最后一个握手消息，标志着下面将进入应用层数据传输阶段。