博客园  :: 首页  :: 新随笔  :: 联系 :: 订阅 订阅  :: 管理

ssl握手协议

Posted on 2011-12-23 09:53  bw_0927  阅读(1945)  评论(0)    收藏  举报

http://book.51cto.com/art/200807/82226.htm

http://www.cnblogs.com/happyhippy/archive/2007/05/14/746476.html

http://blog.csdn.net/wolfzone025/article/details/6220442

1、概述

  安全套接层(Secure Socket Layer, SSL)协议是 Netscape 公司于 1994 年提出的一个网络安全通信协议,是一种在两台机器之间提供安全通道的协议。它具有保护传输数据以及识别通信机器的功能。SSL 最初是通过加密 HTTP 连接为

Web浏览器提供安全而引入的,现在已成为通用Internet服务的安全工具,目前己被工业界认可,成为 IETF 的 RFC 草案,在电子邮件、Netscape Navigator 和IE等网络浏览器、Oracle Application Server 等服务器上已广泛应用。

  SSL在 TCP上提供一种通用的通道安全机制,任何可以在TCP上承载的协

议都能够使用 SSL加以保护。在 TCP/IP四层协议族中,SSL协议位于传输层与应用层之间, 基于可靠传输协议 TCP, 服务于各种应用层协议, 如 HTTP、 POP、TELNET 等,它们在 SSL 协议上运行分别被称作 HTTPS、POPS、TELNETS 协

议等,分别对应的端口号为443、995、992 等。当然,SSL协议最广泛的用途是为 HTTP 提供安全保障,这也是它诞生的最初目的。

 

SSL协议实现的安全机制包括: 

   1)数据传输的机密性:利用对称密钥算法对传输的数据进行加密。

网络上传输的数据很容易被非法用户窃取,SSL采用在通信双方之间建立加密通道的方法保证数据传输的机密性。所谓加密通道,是指发送方在发送数据前,使用加密算法和加密密钥对数据进行加密,然后将数据发送给对方;接收方接收到数据后,利用解密算法和解密密钥从密文中获取明文。没有解密密钥的第三方,无法将密文恢复为明文,从而保证数据传输的机密性。

加解密算法分为两类: 

   对称密钥算法:数据加密和解密时使用相同的密钥。 

   非对称密钥算法:数据加密和解密时使用不同的密钥,一个是公开的公钥,一个是由用户秘密保存的私钥。利用公钥(或私钥)加密的数据只能用相应的私钥(或公钥)才能解密。 

与非对称密钥算法相比,对称密钥算法具有计算速度快的优点,通常用于对大量信息进行加密(如对所有报文加密);而非对称密钥算法,一般用于数字签名和对较少的信息进行加密。 SSL加密通道上的数据加解密使用对称密钥算法,目前主要支持的算法有DES、3DES、AES等,这些算法都可以有效地防止交互数据被窃听。 

对称密钥算法要求解密密钥和加密密钥完全一致。因此,利用对称密钥算法加密传输数据之前,需要在通信两端部署相同的密钥。

   2)身份验证机制:基于证书利用数字签名方法对服务器和客户端进行身份验证,其中客户端的身份验证是可选的。

电子商务和网上银行等应用中必须保证要登录的Web服务器是真实的,以免重要信息被非法窃取。SSL利用数字签名来验证通信对端的身份。 

非对称密钥算法可以用来实现数字签名。由于通过私钥加密后的数据只能利用对应的公钥进行解密,因此根据解密是否成功,就可以判断发送者的身份,如同发送者对数据进行了“签名”。例如,Alice使用自己的私钥对一段固定的信息加密后发给Bob,Bob利用Alice的公钥解密,如果解密结果与固定信息相同,那么就能够确认信息的发送者为Alice,这个过程就称为数字签名

SSL客户端必须验证SSL服务器的身份,SSL服务器是否验证SSL客户端的身份,则由SSL服务器决定。SSL客户端和SSL服务器的身份验证过程,使用数字签名验证身份时,需要确保被验证者的公钥是真实的,否则,非法用户可能会冒充被验证者与验证者通信。如错误!未找到引用源。所示,Cindy冒充Bob,将自己的公钥发给Alice,并利用自己的私钥计算出签名发送给Alice,Alice利用“Bob”的公钥(实际上为Cindy的公钥)成功验证该签名,则Alice认为Bob的身份验证成功,而实际上与Alice通信的是冒充Bob的Cindy。SSL利用PKI提供的机制保证公钥的真实性 

 

   3)消息完整性验证:消息传输过程中使用 MAC算法来检验消息的完整性。

为了避免网络中传输的数据被非法篡改,SSL利用基于MD5或SHA的MAC算法来保证消息的完整性。 MAC算法是在密钥参与下的数据摘要算法,能将密钥和任意长度的数据转换为固定长度的数据。利用MAC算法验证消息完整性的过程如图2所示。发送者在密钥的参与下,利用MAC算法计算出消息的MAC值,并将其加在消息之后发送给接收者。接收者利用同样的密钥和MAC算法计算出消息的MAC值,并与接收到的MAC值比较。如果二者相同,则报文没有改变;否则,报文在传输过程中被修改,接收者将丢弃该报文。 

 

MAC算法具有如下特征,使其能够用来验证消息的完整性: 

   消息的任何改变,都会引起输出的固定长度数据产生变化。通过比较 MAC值,可以保证接收者能够发现消息的改变。 

   MAC 算法需要密钥的参与,因此没有密钥的非法用户在改变消息的内容后,无法添加正确的 MAC值,从而保证非法用户无法随意修改消息内容。 

MAC算法要求通信双方具有相同的密钥,否则MAC值验证将会失败。因此,利用MAC算法验证消息完整性之前,需要在通信两端部署相同的密钥。

 

 利用非对称密钥算法保证密钥本身的安全

对称密钥算法和MAC算法要求通信双方具有相同的密钥,否则解密或MAC值验证将失败。因此,要建立加密通道或验证消息完整性,必须先在通信双方部署一致的密钥。 

SSL利用非对称密钥算法加密密钥的方法实现密钥交换,保证第三方无法获取该密钥。如图3所示,SSL客户端(如Web浏览器)利用SSL服务器(如Web服务器)的公钥加密密钥,将加密后的密钥发送给SSL服务器,只有拥有对应私钥的SSL服务器才能从密文中获取原始的密钥。SSL通常采用RSA算法加密传输密钥。 

    

  实际上,SSL 客户端发送给 SSL 服务器的密钥不能直接用来加密数据或计算 MAC值,该密钥是用来计算对称密钥和 MAC密钥的信息,称为 premaster secret。SSL客户端和 SSL 服务器利用 premaster secret 计算出相同的主密钥(master secret),再利用 master secret 生成用于对称密钥算法、MAC 算法等的密钥。

premaster secret是计算对称密钥、MAC算法密钥的关键。 

  用来实现密钥交换的算法称为密钥交换算法。非对称密钥算法 RSA 用于密钥交换时,也可以称之为密钥交换算法。 

 

利用非对称密钥算法加密密钥之前,发送者需要获取接收者的公钥,并保证该公钥确实属于接收者,否则,密钥可能会被非法用户窃取。如错误!未找到引用源。所示,Cindy冒充Bob,将自己的公钥发给Alice,Alice利用Cindy的公钥加密发送给Bob的数据,Bob由于没有对应的私钥无法解密该数据,而Cindy截取数据后,可以利用自己的私钥解密该数据。SSL利用PKI提供的机制保证公钥的真实性,

2、体系结构

 

  SSL协议在结构上分为两个层次:底层为记录层协议(Record Protocol) ,负责封装高层协议(包括握手协议)的数据,保证 SSL 连接的数据保密性和完整性;高层为握手层,由四个并行的协议构成:握手协议(Handshake Protocol) 、修改密码参数协议(Change Cipher Spec Protocol) 、报警协议(Alert Protocol  ) 、应用数据协议(Application data Protocol ) ,高层协议需要记录层协议支持,其中握手协议与其他的高层协议不同, 主要负责在交换应用层数据之前进行协商加密算法与密钥,其他高层协议属于应用开发的范畴,而要得到握手协议的支持,而握手协议则是 SSL 底层实现必须具有的功能,因为记录层协议的完成也由它来作保证。

----以上引用H3C<<SSL技术白皮书 >>

=================================================

一、SSL握手有三个目的:
1. 客户端与服务器需要就一组用于保护数据的算法达成一致
2. 它们需要确立一组由那些算法所使用的加密密钥
3. 握手还可以选择对客户端进行认证

二、SSL握手过程:
1. 客户端将它所支持的算法列表和一个用作产生密钥的随机数发送给服务器;
2. 服务器从算法列表中选择一种加密算法,并将它和一份包含服务器公用密钥的证书发送给客户端;该证书还包含了用于认证目的的服务器标识,服务器同时还提供了一个用作产生密钥的随机数
3. 客户端对服务器的证书进行验证(有关验证证书,可以参考数字签名),并抽取服务器的公用密钥;然后,再产生一个称作pre_master_secret的随机密码串,并使用服务器的公用密钥对其进行加密(参考非对称加/解密),并将加密后的信息发送给服务器;
4. 客户端与服务器端根据pre_master_secret以及客户端与服务器的随机数值独立计算出加密和MAC密钥(参考DH密钥交换算法)。
5. 客户端将所有握手消息的MAC值发送给服务器;
6. 服务器将所有握手消息的MAC值发送给客户端。

    第5与第6步用以防止握手本身遭受篡改。设想一个攻击者想要控制客户端与服务器所使用的算法。客户端提供多种算法的情况相当常见,某些强度弱而某些强度强,以便能够与仅支持弱强度算法的服务器进行通信。攻击者可以删除客户端在第1步所提供的所有高强度算法,于是就迫使服务器选择一种弱强度的算法。第5步与第6步的MAC交换就能阻止这种攻击,因为客户端的MAC是根据原始消息计算得出的,而服务器的MAC是根据攻击者修改过的消息计算得出的,这样经过检查就会发现不匹配。由于客户端与服务器所提供的随机数为密钥产生过程的输入,所以握手不会受到重放攻击的影响。这些消息是首个在新的加密算法与密钥下加密的消息。

    刚才所描述的每一步都需要通过一条或多条握手消息来实现。在此先简要地描述哪些消息与哪几步相对应,然后详细描述每条消息的内容。下图描述了各条消息:

    第1步对应一条单一的握手消息,ClientHello.
    第2步对应一系列SSL握手消息,服务器发送的第一条消息为ServerHello,其中包含了它所选择的算法,接着再在Certificate消息中发送其证书。最后,服务器发送ServerHelloDone消息以表示这一握手阶段的完成。需要ServerHelloDone的原因是一些更为复杂的握手变种还要在Certifacate之后发送其他一些消息。当客户端接收到ServerHelloDone消息时,它就知道不会再有其他类似的消息过来了,于是就可以继续它这一方的握手。
    第3步对应ClientKeyExchange消息。
    第5与第6步对应Finished消息。该消息是第一条使用刚刚磋商过的算法加以保护的消息。为了防止握手过程遭到篡改,该消息的内容是前一阶段所有握手消息的MAC值。然而,由于Finished消息是以磋商好的算法加以保护的,所以也要与新磋商的MAC密钥—起计算消息本身的MAc值。
    注意,上图中省略了两条ChangeCipherSpec消息。

三、SSL记录协议:
    在SSL中,实际的数据传输是使用SSL记录协议来实现的。SSL记录协议是通过将数据流分割成一系列的片段并加以传输来工作的,其中对每个片段单独进行保护和传输。在接收方,对每条记录单独进行解密和验证。这种方案使得数据一经准备好就可以从连接的一端传送到另一端,并在接收到的即刻加以处理。
    在传输片段之前,必须防止其遭到攻击。可以通过计算数据的MAC来提供完整性保护。MAC与片段一起进行传输,并由接收实现加以验证。将MAC附加到片段的尾部,并对数据与MAC整合在一起的内容进行加密,以形成经过加密的负载(Payload)。最后给负载装上头信息。头信息与经过加密的负载的连结称作记录(record),记录就是实际传输的内容。下图描述了传输过程:

3.1 记录头消息:
    记录头信息的工作就是为接收实现(receiving implementation)提供对记录进行解释所必需的信息。在实际应用中,它是指三种信息:内容类型、长度和SSL版本。长度字段可以让接收方知道他要从线路上这取多少字节才能对消息进行处理,版本号只是一项确保每一方使用所磋商的版本的冗余性检查。内容类型字段表示消息类型。

3.2 SSL记录类型
    SSL支持四种内容类型:application_data、alert、handshake和change_cipher_spec。
使用SSL的软件发送和接收的所有数据都是以application_data类型来发送的,其他三种内容类型用于对通信进行管理,如完成握手和报告错误等。
    内容类型alert主要用于报告各种类型的错误。大多数alert(警示)用于报告握手中出现的问题,但也有一些指示在对记录试图进行解密或认证时发生的错误,alert消息的其他用途是指示连接将要关闭。
    内容类型handshake用于承载握手消息。即便是最初形成连接的握手消息也是通过记录层以handshake类型的记录来承载的。由于加密密钥还未确立,这些初始的消息并未经过加密或认证,但是其他处理过程是一样的。有可能在现有的连接上初始化一次新的握手,在这种情况下,新的握手记录就像其他的数据一样,要经过加密和认证。
    change_cipher_spec消息表示记录加密及认证的改变。一旦握手商定了一组新的密钥,就发送change_cipher_spec来指示此刻将启用新的密钥。

四、各种消息协同工作:
    正如我们所看到的,SSL是一种分层协议,它以一个记录层以及记录层上承裁的个同消息类型组成。而该记录层又会由某种可靠的传输协议如TCP来承载。下图描述了该协以的结构:

五、一次SSL连接的完整过程:



摘录自《SSL与TLS》


happyhippy作者:Silent Void 
出处:http://happyhippy.cnblogs.com/
转载须保留此声明,并注明在文章起始位置给出原文链接。

 

1 SSL(Secure Socket Layer)netscape公司设计的主要用于web的安全传输协议。这种协议在WEB上获得了广泛的应用。 
  2 IETF(www.ietf.org)SSL作了标准化,即RFC2246,并将其称为TLSTransport Layer Security),从技术上讲,TLS1.0SSL3.0的差别非常微小。由于本文中没有涉及两者间的细小差别,本文中这两个名字等价。 

SSL协议分为两部分:Handshake ProtocolRecord Protocol,。其中Handshake Protocol用来协商密钥,协议的大部分内容就是通信双方如何利用它来安全的协商出一份密钥。 Record Protocol则定义了传输的格式。 

SSL 协议的握手和通讯 

  为了便于更好的认识和理解 SSL 协议,这里着重介绍 SSL 协议的握手协议。SSL 协议既用到了公钥加密技术又用到了对称加密技术,对称加密技术虽然比公钥加密技术的速度快,可是公钥加密技术提供了更好的身份认证技术。SSL 的握手协议非常有效的让客户和服务器之间完成相互之间的身份认证,其主要过程如下:
   客户端的浏览器向服务器传送客户端 SSL 协议的版本号,加密算法的种类,产生的随机数,以及其他服务器和客户端之间通讯所需要的各种信息。
   服务器向客户端传送 SSL 协议的版本号,加密算法的种类,随机数以及其他相关信息,同时服务器还将向客户端传送自己的证书。
   客户利用服务器传过来的信息验证服务器的合法性,服务器的合法性包括:证书是否过期,发行服务器证书的 CA 是否可靠,发行者证书的公钥能否正确解开服务器证书的发行者的数字签名,服务器证书上的域名是否和服务器的实际域名相匹配。如果合法性验证没有通过,通讯将断开;如果合法性验证通过,将继续进行第四步。
   用户端随机产生一个用于后面通讯的对称密码,然后用服务器的公钥(服务器的公钥从步骤中的服务器的证书中获得)对其加密,然后将加密后的预主密码传给服务器。 
   如果服务器要求客户的身份认证(在握手过程中为可选),用户可以建立一个随机数然后对其进行数据签名,将这个含有签名的随机数和客户自己的证书以及加密过的预主密码一起传给服务器。 
   如果服务器要求客户的身份认证,服务器必须检验客户证书和签名随机数的合法性,具体的合法性验证过程包括:客户的证书使用日期是否有效,为客户提供证书的 CA 是否可靠,发行 CA 的公钥能否正确解开客户证书的发行 CA 的数字签名,检查客户的证书是否在证书废止列表(CRL中。检验如果没有通过,通讯立刻中断;如果验证通过,服务器将用自己的私钥解开加密的预主密码,然后执行一系列步骤来产生主通讯密码客户端也将通过同样的方法产生相同的主通讯密码)。
   服务器和客户端用相同的主密码通话密码,一个对称密钥用于 SSL 协议的安全数据通讯的加解密通讯。同时在 SSL 通讯过程中还要完成数据通讯的完整性,防止数据通讯中的任何变化。 
   客户端向服务器端发出信息,指明后面的数据通讯将使用的步骤中的主密码为对称密钥,同时通知服务器客户端的握手过程结束。
   服务器向客户端发出信息,指明后面的数据通讯将使用的步骤中的主密码为对称密钥,同时通知客户端服务器端的握手过程结束。
   SSL 的握手部分结束,SSL 安全通道的数据通讯开始,客户和服务器开始使用相同的对称密钥进行数据通讯,同时进行通讯完整性的检验。


  双向认证 SSL 协议的具体过程
    浏览器发送一个连接请求给安全服务器。 
   服务器将自己的证书,以及同证书相关的信息发送给客户浏览器。 
   客户浏览器检查服务器送过来的证书是否是由自己信赖的 CA 中心所签发的。如果是,就继续执行协议;如果不是,客户浏览器就给客户一个警告消息:警告客户这个证书不是可以信赖的,询问客户是否需要继续。
    接着客户浏览器比较证书里的消息,例如域名和公钥,与服务器刚刚发送的相关消息是否一致,如果是一致的,客户浏览器认可这个服务器的合法身份。 
    服务器要求客户发送客户自己的证书。收到后,服务器验证客户的证书,如果没有通过验证,拒绝连接;如果通过验证,服务器获得用户的公钥。 
    客户浏览器告诉服务器自己所能够支持的通讯对称密码方案。
    服务器从客户发送过来的密码方案中,选择一种加密程度最高的密码方案,用客户的公钥加过密后通知浏览器。 
    浏览器针对这个密码方案,选择一个通话密钥,接着用服务器的公钥加过密后发送给服务器。
    服务器接收到浏览器送过来的消息,用自己的私钥解密,获得通话密钥。 
    服务器、浏览器接下来的通讯都是用对称密码方案,对称密钥是加过密的。 
   上面所述的是双向认证 SSL 协议的具体通讯过程,这种情况要求服务器和用户双方都有证书。单向认证 SSL 协议不需要客户拥有 CA 证书,具体的过程相对于上面的步骤,只需将服务器端验证客户证书的过程去掉,以及在协商对称密码方案,对称通话密钥时,服务器发送给客户的是没有加过密的(这并不影响 SSL 过程的安全性)密码方案。 这样,双方具体的通讯内容,就是加过密的数据,如果有第三方攻击,获得的只是加密的数据,第三方要获得有用的信息,就需要对加密的数据进行解密,这时候的安全就依赖于密码方案的安全。而幸运的是,目前所用的密码方案,只要通讯密钥长度足够的长,就足够的安全。这也是我们强调要求使用 128 位加密通讯的原因。