SSL原理
一 前言
首先要澄清一下名字的混淆：
1 SSL(Secure Socket Layer)是netscape公司设计的主要用于web的安全传输协议。这种协议在WEB上获得了广泛的应用。
2 IETF(www.ietf.org)将SSL作了标准化，即RFC2246,并将其称为TLS（Transport Layer Security），从技术上讲，TLS1.0与SSL3.0的差别非常微小。由于本文中没有涉及两者间的细小差别，本文中这两个名字等价。
3 在WAP的环境下，由于手机及手持设备的处理和存储能力有限，wap论坛（www.wapforum.org）在TLS的基础上做了...S协议（Wireless Transport Layer Security），以适应无线的特殊环境。
我们从各式各样的文章中得知，SSL可以用于保密的传输，这样我们与web server之间传输的消息便是“安全的”。
而这种“安全”究竟是怎么实现的，最终有能实现多大程度的保密？本文希望能用通俗的语言阐明其实现原理。
二 整体结构概览
SSL是一个介于HTTP协议与TCP之间的一个可选层，其位置大致如下：
－－－－－－－－－
| HTTP |
－－－－－－－－－
| SSL |
－－－－－－－－－
| TCP |
－－－－－－－－－
| IP |
－－－－－－－－－
如果利用SSL协议来访问网页，其步骤如下：
用户：在浏览器的地址栏里输入https://www.sslserver.com
HTTP层：将用户需求翻译成HTTP请求，如
GET /index.htm HTTP/1.1
Host http://www.sslserver.com
SSL层: 借助下层协议的的信道安全的协商出一份加密密钥，并用此密钥来加密HTTP请求。
TCP层：与web server的443端口建立连接，传递SSL处理后的数据。
接收端与此过程相反。
SSL在TCP之上建立了一个加密通道，通过这一层的数据经过了加密，因此达到保密的效果。
SSL协议分为两部分：Handshake Protocol和Record Protocol,。其中Handshake Protocol用来协商密钥，协议的大部分内容就是通信双方如何利用它来安全的协商出一份密钥。 Record Protocol则定义了传输的格式。
三 需要的加密方面的基础知识
了解SSL原理需要一点点加密的概念，这里把需要的概念做一下简单阐述：
加密一般分为三类，对称加密，非对称加密及单向散列函数。
对称加密：又分分组密码和序列密码。
分组密码是将明文按一定的位长分组，明文组经过加密运算得到密文组，密文组经过解密运算
（加密运算的逆运算），还原成明文组。
序列密码是指利用少量的密钥（制乱元素）通过某种复杂的运算（密码算法）产生大量的伪随机位流，用于对明文位流的加密。
解密是指用同样的密钥和密码算法及与加密相同的伪随机位流，用以还原明文位流。
CBC(Cipher Block Chaining)模式这个词在分组密码中经常会用到，它是指一个明文分组在被加密之前要与前一个的密文分组进行异或运算。当加密算法用于此模式的时候除密钥外，还需协商一个初始化向量（IV），这个IV没有实际意义，只是在第一次计算的时候需要用到而已。采用这种模式的话安全性会有所提高。
分组密码的典型例子为DES,RC5,IDEA。
序列密码的典型例子为RC4。
公钥加密：
简单的说就是加密密钥与解密密钥不同，分私钥和公钥。这种方法大多用于密钥交换，RSA便是一个我们熟知的例子。
还有一个常用的称作DH，它只能用于密钥交换，不能用来加密。
单向散列函数：
由于信道本身的干扰和人为的破坏，接受到的信息可能与原来发出的信息不同，一个通用的办法就是加入校验码。
单向散列函数便可用于此用途，一个典型的例子是我们熟知的MD5,它产生128位的摘要，在现实中用的更多的是安全散列算法（SHA），SHA的早期版本存在问题，目前用的实际是SHA－1，它可以产生160位的摘要，因此比128位散列更能有效抵抗穷举攻击。
由于单向散列的算法都是公开的，所以其它人可以先改动原文，再生成另外一份摘要。解决这个问题的办法可以通过HMAC（RFC 2104）,它包含了一个密钥，只有拥有相同密钥的人才能鉴别这个散列。
四 密钥协商过程
由于对称加密的速度比较慢，所以它一般用于密钥交换，双方通过公钥算法协商出一份密钥，然后通过对称加密来通信，当然，为了保证数据的完整性，在加密前要先经过HMAC的处理。
SSL缺省只进行server端的认证，客户端的认证是可选的。以下是其流程图（摘自TLS协议）。
Client Server
Clienth*llo -------->
Serverh*llo
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- Serverh*lloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
简单的说便是：SSL客户端（也是TCP的客户端）在TCP链接建立之后，发出一个Clienth*llo来发起握手，这个消息里面包含了自己可实现的算法列表和其它一些需要的消息，SSL的服务器端会回应一个Serverh*llo，这里面确定了这次通信所需要的算法，然后发过去自己的证书（里面包含了身份和自己的公钥）。Client在收到这个消息后会生成一个秘密消息，用SSL服务器的公钥加密后传过去，SSL服务器端用自己的私钥解密后，会话密钥协商成功，双方可以用同一份会话密钥来通信了。
五 密钥协商的形象化比喻
如果上面的说明不够清晰，这里我们用个形象的比喻，我们假设A与B通信，A是SSL客户端，B是SSL服务器端，加密后的消息放在方括号[]里，以突出明文消息的区别。双方的处理动作的说明用圆括号（）括起。
A：我想和你安全的通话，我这里的对称加密算法有DES,RC5,密钥交换算法有RSA和DH，摘要算法有MD5和SHA。
B：我们用DES－RSA－SHA这对组合好了。
这是我的证书，里面有我的名字和公钥，你拿去验证一下我的身份（把证书发给A）。
目前没有别的可说的了。
A：（查看证书上B的名字是否无误，并通过手头早已有的CA的证书验证了B的证书的真实性，如果其中一项有误，发出警告并断开连接，这一步保证了B的公钥的真实性）
（产生一份秘密消息，这份秘密消息处理后将用作加密密钥，加密初始化向量和hmac的密钥。将这份秘密消息-协议中称为per_master_secret-用B的公钥加密，封装成称作ClientKeyExchange的消息。由于用了B的公钥，保证了第三方无法窃听）
我生成了一份秘密消息，并用你的公钥加密了，给你（把ClientKeyExchange发给B）
注意，下面我就要用加密的办法给你发消息了！
（将秘密消息进行处理，生成加密密钥，加密初始化向量和hmac的密钥）
[我说完了]
B：（用自己的私钥将ClientKeyExchange中的秘密消息解密出来，然后将秘密消息进行处理，生成加密密钥，加密初始化向量和hmac的密钥，这时双方已经安全的协商出一套加密办法了）
注意，我也要开始用加密的办法给你发消息了！
[我说完了]
A: [我的秘密是...]
B: [其它人不会听到的...]
六 加密的计算
上一步讲了密钥的协商，但是还没有阐明是如何利用加密密钥，加密初始化向量和hmac的密钥来加密消息的。
其实其过程不过如此：
1 借助hmac的密钥，对明文的消息做安全的摘要处理，然后和明文放到一起。
2 借助加密密钥，加密初始化向量加密上面的消息。
七 安全性
SecurityPortal在2000年底有一份文章《The End of SSL and SSH?》激起了很多的讨论，
目前也有一些成熟的工具如dsniff（http://www.monkey.org/~dugsong/dsniff/）可以
通过man in the middle攻击来截获https的消息。
从上面的原理可知，SSL的结构是严谨的，问题一般出现在实际不严谨的应用中。常见的攻击就是
middle in the middle攻击，它是指在A和B通信的同时，有第三方C处于信道的中间，可以完全
听到A与B通信的消息，并可拦截，替换和添加这些消息。
1 SSL可以允许多种密钥交换算法，而有些算法，如DH，没有证书的概念，这样A便无法验证B的公钥
和身份的真实性，从而C可以轻易的冒充，用自己的密钥与双方通信，从而窃听到别人谈话的内容。
而为了防止middle in the middle攻击，应该采用有证书的密钥交换算法。
2 有了证书以后，如果C用自己的证书替换掉原有的证书之后，A的浏览器会弹出一个警告框进行警告，但又有多少人会注意这个警告呢？
3 由于美国密码出口的限制，IE，netscape等浏览器所支持的加密强度是很弱的，如果只采用浏览器自带的加密功能的话，理论上存在被破解可能。
八 代理
下面探讨一下SSL的代理是怎样工作的(可参见[6])。这可能与你开始想的不太一样：）
当在浏览器里设置了https的代理，而且在浏览器里输入了https://www.example.com之后，
浏览器会与proxy建立tcp链接，然后向其发出这么一段消息：
CONNECT server.example.com:443 HTTP/1.1
Host: server.example.com:443
然后proxy会向webserver端建立tcp连接,之后，这个代理便完全成了个内容转发装置。浏览器
与web server会建立一个安全通道，因此这个安全通道是端到端的，尽管所有的信息流过了proxy,
但其内容proxy是无法解密和改动的（当然要由证书的支持，否则这个地方便是个man in the middle攻击的好场所，见上面的讨论）。
九 关于证书
注意，如果对于一般的应用，管理员只需生成“证书请求”（后缀大多为.csr），它包含你的名字和公钥，然后把这份请求交给诸如verisign等有CA服务公司（当然，连同几百美金），
你的证书请求经验证后，CA用它的私钥签名，形成正式的证书发还给你。管理员再在web server上导入这个证书就行了。如果你不想花那笔钱，或者想了解一下原理，可以自己做CA。
从ca的角度讲，你需要CA的私钥和公钥。从想要证书的服务器角度将，需要把服务器的证书请求交给CA.
如果你要自己做CA，别忘了客户端需要导入CA的证书（CA的证书是自签名的，导入它意味着你“信任”这个CA签署的证书）。
而商业CA的一般不用，因为它们已经内置在你的浏览器中了。
首先要澄清一下名字的混淆：
1 SSL(Secure Socket Layer)是netscape公司设计的主要用于web的安全传输协议。这种协议在WEB上获得了广泛的应用。
2 IETF(www.ietf.org)将SSL作了标准化，即RFC2246,并将其称为TLS（Transport Layer Security），从技术上讲，TLS1.0与SSL3.0的差别非常微小。由于本文中没有涉及两者间的细小差别，本文中这两个名字等价。
3 在WAP的环境下，由于手机及手持设备的处理和存储能力有限，wap论坛（www.wapforum.org）在TLS的基础上做了...S协议（Wireless Transport Layer Security），以适应无线的特殊环境。
我们从各式各样的文章中得知，SSL可以用于保密的传输，这样我们与web server之间传输的消息便是“安全的”。
而这种“安全”究竟是怎么实现的，最终有能实现多大程度的保密？本文希望能用通俗的语言阐明其实现原理。
二 整体结构概览
SSL是一个介于HTTP协议与TCP之间的一个可选层，其位置大致如下：
－－－－－－－－－
| HTTP |
－－－－－－－－－
| SSL |
－－－－－－－－－
| TCP |
－－－－－－－－－
| IP |
－－－－－－－－－
如果利用SSL协议来访问网页，其步骤如下：
用户：在浏览器的地址栏里输入https://www.sslserver.com
HTTP层：将用户需求翻译成HTTP请求，如
GET /index.htm HTTP/1.1
Host http://www.sslserver.com
SSL层: 借助下层协议的的信道安全的协商出一份加密密钥，并用此密钥来加密HTTP请求。
TCP层：与web server的443端口建立连接，传递SSL处理后的数据。
接收端与此过程相反。
SSL在TCP之上建立了一个加密通道，通过这一层的数据经过了加密，因此达到保密的效果。
SSL协议分为两部分：Handshake Protocol和Record Protocol,。其中Handshake Protocol用来协商密钥，协议的大部分内容就是通信双方如何利用它来安全的协商出一份密钥。 Record Protocol则定义了传输的格式。
三 需要的加密方面的基础知识
了解SSL原理需要一点点加密的概念，这里把需要的概念做一下简单阐述：
加密一般分为三类，对称加密，非对称加密及单向散列函数。
对称加密：又分分组密码和序列密码。
分组密码是将明文按一定的位长分组，明文组经过加密运算得到密文组，密文组经过解密运算
（加密运算的逆运算），还原成明文组。
序列密码是指利用少量的密钥（制乱元素）通过某种复杂的运算（密码算法）产生大量的伪随机位流，用于对明文位流的加密。
解密是指用同样的密钥和密码算法及与加密相同的伪随机位流，用以还原明文位流。
CBC(Cipher Block Chaining)模式这个词在分组密码中经常会用到，它是指一个明文分组在被加密之前要与前一个的密文分组进行异或运算。当加密算法用于此模式的时候除密钥外，还需协商一个初始化向量（IV），这个IV没有实际意义，只是在第一次计算的时候需要用到而已。采用这种模式的话安全性会有所提高。
分组密码的典型例子为DES,RC5,IDEA。
序列密码的典型例子为RC4。
公钥加密：
简单的说就是加密密钥与解密密钥不同，分私钥和公钥。这种方法大多用于密钥交换，RSA便是一个我们熟知的例子。
还有一个常用的称作DH，它只能用于密钥交换，不能用来加密。
单向散列函数：
由于信道本身的干扰和人为的破坏，接受到的信息可能与原来发出的信息不同，一个通用的办法就是加入校验码。
单向散列函数便可用于此用途，一个典型的例子是我们熟知的MD5,它产生128位的摘要，在现实中用的更多的是安全散列算法（SHA），SHA的早期版本存在问题，目前用的实际是SHA－1，它可以产生160位的摘要，因此比128位散列更能有效抵抗穷举攻击。
由于单向散列的算法都是公开的，所以其它人可以先改动原文，再生成另外一份摘要。解决这个问题的办法可以通过HMAC（RFC 2104）,它包含了一个密钥，只有拥有相同密钥的人才能鉴别这个散列。
四 密钥协商过程
由于对称加密的速度比较慢，所以它一般用于密钥交换，双方通过公钥算法协商出一份密钥，然后通过对称加密来通信，当然，为了保证数据的完整性，在加密前要先经过HMAC的处理。
SSL缺省只进行server端的认证，客户端的认证是可选的。以下是其流程图（摘自TLS协议）。
Client Server
Clienth*llo -------->
Serverh*llo
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- Serverh*lloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
简单的说便是：SSL客户端（也是TCP的客户端）在TCP链接建立之后，发出一个Clienth*llo来发起握手，这个消息里面包含了自己可实现的算法列表和其它一些需要的消息，SSL的服务器端会回应一个Serverh*llo，这里面确定了这次通信所需要的算法，然后发过去自己的证书（里面包含了身份和自己的公钥）。Client在收到这个消息后会生成一个秘密消息，用SSL服务器的公钥加密后传过去，SSL服务器端用自己的私钥解密后，会话密钥协商成功，双方可以用同一份会话密钥来通信了。
五 密钥协商的形象化比喻
如果上面的说明不够清晰，这里我们用个形象的比喻，我们假设A与B通信，A是SSL客户端，B是SSL服务器端，加密后的消息放在方括号[]里，以突出明文消息的区别。双方的处理动作的说明用圆括号（）括起。
A：我想和你安全的通话，我这里的对称加密算法有DES,RC5,密钥交换算法有RSA和DH，摘要算法有MD5和SHA。
B：我们用DES－RSA－SHA这对组合好了。
这是我的证书，里面有我的名字和公钥，你拿去验证一下我的身份（把证书发给A）。
目前没有别的可说的了。
A：（查看证书上B的名字是否无误，并通过手头早已有的CA的证书验证了B的证书的真实性，如果其中一项有误，发出警告并断开连接，这一步保证了B的公钥的真实性）
（产生一份秘密消息，这份秘密消息处理后将用作加密密钥，加密初始化向量和hmac的密钥。将这份秘密消息-协议中称为per_master_secret-用B的公钥加密，封装成称作ClientKeyExchange的消息。由于用了B的公钥，保证了第三方无法窃听）
我生成了一份秘密消息，并用你的公钥加密了，给你（把ClientKeyExchange发给B）
注意，下面我就要用加密的办法给你发消息了！
（将秘密消息进行处理，生成加密密钥，加密初始化向量和hmac的密钥）
[我说完了]
B：（用自己的私钥将ClientKeyExchange中的秘密消息解密出来，然后将秘密消息进行处理，生成加密密钥，加密初始化向量和hmac的密钥，这时双方已经安全的协商出一套加密办法了）
注意，我也要开始用加密的办法给你发消息了！
[我说完了]
A: [我的秘密是...]
B: [其它人不会听到的...]
六 加密的计算
上一步讲了密钥的协商，但是还没有阐明是如何利用加密密钥，加密初始化向量和hmac的密钥来加密消息的。
其实其过程不过如此：
1 借助hmac的密钥，对明文的消息做安全的摘要处理，然后和明文放到一起。
2 借助加密密钥，加密初始化向量加密上面的消息。
七 安全性
SecurityPortal在2000年底有一份文章《The End of SSL and SSH?》激起了很多的讨论，
目前也有一些成熟的工具如dsniff（http://www.monkey.org/~dugsong/dsniff/）可以
通过man in the middle攻击来截获https的消息。
从上面的原理可知，SSL的结构是严谨的，问题一般出现在实际不严谨的应用中。常见的攻击就是
middle in the middle攻击，它是指在A和B通信的同时，有第三方C处于信道的中间，可以完全
听到A与B通信的消息，并可拦截，替换和添加这些消息。
1 SSL可以允许多种密钥交换算法，而有些算法，如DH，没有证书的概念，这样A便无法验证B的公钥
和身份的真实性，从而C可以轻易的冒充，用自己的密钥与双方通信，从而窃听到别人谈话的内容。
而为了防止middle in the middle攻击，应该采用有证书的密钥交换算法。
2 有了证书以后，如果C用自己的证书替换掉原有的证书之后，A的浏览器会弹出一个警告框进行警告，但又有多少人会注意这个警告呢？
3 由于美国密码出口的限制，IE，netscape等浏览器所支持的加密强度是很弱的，如果只采用浏览器自带的加密功能的话，理论上存在被破解可能。
八 代理
下面探讨一下SSL的代理是怎样工作的(可参见[6])。这可能与你开始想的不太一样：）
当在浏览器里设置了https的代理，而且在浏览器里输入了https://www.example.com之后，
浏览器会与proxy建立tcp链接，然后向其发出这么一段消息：
CONNECT server.example.com:443 HTTP/1.1
Host: server.example.com:443
然后proxy会向webserver端建立tcp连接,之后，这个代理便完全成了个内容转发装置。浏览器
与web server会建立一个安全通道，因此这个安全通道是端到端的，尽管所有的信息流过了proxy,
但其内容proxy是无法解密和改动的（当然要由证书的支持，否则这个地方便是个man in the middle攻击的好场所，见上面的讨论）。
九 关于证书
注意，如果对于一般的应用，管理员只需生成“证书请求”（后缀大多为.csr），它包含你的名字和公钥，然后把这份请求交给诸如verisign等有CA服务公司（当然，连同几百美金），
你的证书请求经验证后，CA用它的私钥签名，形成正式的证书发还给你。管理员再在web server上导入这个证书就行了。如果你不想花那笔钱，或者想了解一下原理，可以自己做CA。
从ca的角度讲，你需要CA的私钥和公钥。从想要证书的服务器角度将，需要把服务器的证书请求交给CA.
如果你要自己做CA，别忘了客户端需要导入CA的证书（CA的证书是自签名的，导入它意味着你“信任”这个CA签署的证书）。
而商业CA的一般不用，因为它们已经内置在你的浏览器中了。
=======
|
||||||||
一．协议的起源 随着计算机网络技术向整个经济社会各层次延伸，整个社会表现对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消息。因为只有拥有合适的公钥的服务器才能解开密钥。下图为第一阶段的流程： 需要注意的一点是每一通信方向上都需要一对密钥，所以一个连接需要四个密钥，分别为客户方的读密钥、客户方的写密钥、服务器方的读密钥、服务器方的写密钥。 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 Eclient_write_key[connection-id] SERVER-VERIFY S－>;C Eserver_write_key[challenge] SERVER－FINISH S－>;C Eserver_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 Eserver_public_key[master_key] CLIENT－FINISH C－>;S Eclient_write_key[connection-id] SERVER－VERIFY S－>;C Eserver_write_key[challenge] SERVER－FINISH S－>;C Eserver_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 Eclient_write_key[connection-id] SERVER-VERIFY S－>;C Eserver_write_key[challenge] REQUEST－CERTIFICATE S－>;C Eserver_write_key[auth_type,challenge'] CLIENT－CERTIFICATE C－>;S Eclient_write_key[cert_type,client_cert,response_data] SERVER－FINISH S－>;C Eserver_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 |
QQ：273352165
evlon#126.com
转载请注明出处。
