完整word证书的应用之一TCPSSL通信实例及协议分析中.docx
《完整word证书的应用之一TCPSSL通信实例及协议分析中.docx》由会员分享，可在线阅读，更多相关《完整word证书的应用之一TCPSSL通信实例及协议分析中.docx（10页珍藏版）》请在冰豆网上搜索。
完整word证书的应用之一TCPSSL通信实例及协议分析中
证书的应用之一——TCP&SSL通信实例及协议分析（中）
SSL建立握手连接目的：
1.身份的验证，client与server确认对方是它相连接的，而不是第三方冒充的，通过证书实现
2.client与server交换sessionkey，用于连接后数据的传输加密和hash校验
简单的SSL握手连接过程（仅Server端交换证书给client）：
1.client发送ClientHello，指定版本，随机数（RN），所有支持的密码套件（CipherSuites）
2.server回应ServerHello，指定版本，RN，选择CipherSuites，会话ID（SessionID）
3.server发送Certificate
4.Server发送ServerHelloDone
5.Client发送ClientKeyExchange，用于与server交换sessionkey
6.Client发送ChangeCipherSpec，指示Server从现在开始发送的消息都是加密过的
7.Client发送Finishd，包含了前面所有握手消息的hash，可以让server验证握手过程是否被第三方篡改
8.Server发送ChangeCipherSpec，指示Client从现在开始发送的消息都是加密过的
9.Server发送Finishd，包含了前面所有握手消息的hash，可以让client验证握手过程是否被第三方篡改，并且证明自己是Certificate密钥的拥有者，即证明自己的身份
下面从抓包数据来具体分析这一过程并说明各部分数据的作用以及如实现前面列出的握手的目标，当然了，最重要的还是说明为何这一过程是安全可靠的，第三方无法截获，篡改或者假冒
1.client发送ClientHello
每一条消息都会包含有ContentType,Version,HandshakeType等信息。
ContentType指示SSL通信处于哪个阶段，是握手（Handshake），开始加密传输（ChangeCipherSpec）还是正常通信（Application）等，见下表
Hex
Dec
Type
0x14
20
ChangeCipherSpec
0x15
21
Alert
0x16
22
Handshake
0x17
23
Application
Version是TLS的版本，见下表
MajorVersion
MinorVersion
VersionType
3
0
SSLv3
3
1
TLS1.0
3
2
TLS1.1
3
3
TLS1.2
HandshakeType是在handshanke阶段中的具体哪一步，见下表
Code
Description
0
HelloRequest
1
ClientHello
2
ServerHello
11
Certificate
12
ServerKeyExchange
13
CertificateRequest
14
ServerHelloDone
15
CertificateVerify
16
ClientKeyExchange
20
Finished
ClientHello附带的数据随机数据RN，会在生成sessionkey时使用，Ciphersuite列出了client支持的所有加密算法组合，可以看出每一组包含3种算法，一个是非对称算法，如RSA，一个是对称算法如DES，3DES，RC4等，一个是Hash算法，如MD5，SHA等，server会从这些算法组合中选取一组，作为本次SSL连接中使用。
2.server回应ServerHello
这里多了个sessionid,如果SSL连接断开，再次连接时，可以使用该属性重新建立连接，在双方都有缓存的情况下可以省略握手的步骤。
server端也会生成随机的RN，用于生成sessionkey使用
server会从client发送的Ciphersuite列表中跳出一个，这里挑选的是RSA+RC4+MD5
这次server共发送的3个handshake消息:
Serverhello，Certificate和ServerHelloDone，共用一个ContentType:
Handshake
3.server发送Certificate
server的证书信息，只包含publickey，server将该publickey对应的privatekey保存好，用于证明server是该证书的实际拥有者，那么如何验证呢？
原理很简单：
client随机生成一串数，用server这里的publickey加密（显然是RSA算法），发给server，server用privatekey解密后返回给client，client与原文比较，如果一致，则说明server拥有privatekey，也就说明与client通信的正是证书的拥有者，因为publickey加密的数据，只有privatekey才能解密，目前的技术还没发破解。
利用这个原理，也能实现sessionkey的交换，加密前的那串随机数就可用作sessionkey，因为除了client和server，没有第三方能获得该数据了。
原理很简单，实际使用时会复杂很多，数据经过多次hash，伪随机等的运算，前面提到的client和server端得RN都会参与计算。
4.Server发送ServerHelloDone
5.Client发送ClientKeyExchange
client拿到server的certificate后，就可以开始利用certificate里的publickey进行sessionkey的交换了。
从图中可以看出，client发送的是130字节的字节流，显然是加过密的。
client随机生成48字节的Pre-mastersecret，padding后用publickey加密就得到这130字节的数据发送给server，server解密也能得到Pre-mastersecret。
双方使用pre-mastersecret,"mastersecret"常量字节流，前期交换的server端RN和client的RN作为参数，使用一个伪随机函数PRF，其实就是hash之后再hash，最后得到48字节的mastersecret。
mastersecret再与"keyexpansion"常量，双方RN经过伪随机函数运算得到key_block，PRF伪随机函数可以可以仿佛循环输出数据，因此我们想得到多少字节都可以，就如Random伪随机函数，给它一个种子，后续用hash计算能得到无数个随机数，如果每次种子相同，得到的序列是一样的，但是这里的输入时48字节的mastersecret，2个28字节的RN和一个字符串常量，碰撞的可能性是很小的。
得到keyblock后，算法，就从中取出sessionkey，IV（对称算法中使用的初始化向量）等。
client和server使用的sessionkey是不一样的，但只要双方都知道对方使用的是什么就行了。
这里会取出4个：
client/server加密正文的key，client/server计算handshake数据hash的key。
6.Client发送ChangeCipherSpec
client指示Server从现在开始发送的消息都是加密过的
7.Client发送Finished
client发送的加密数据，这个消息非常关键，一是能证明握手数据没有被篡改过，二也能证明自己确实是密钥的拥有者（这里是单边验证，只有server有certificate，server发送的Finished能证明自己含有privatekey，原理是一样的）。
client将之前发送的所有握手消息存入handshakemessages缓存，进行MD5和SHA-1两种hash运算，再与前面的mastersecret和一串常量"clientfinished"进行PRF伪随机运算得到12字节的verifydata，还要经过改进的MD5计算得到加密信息。
为什么能证明上述两点呢，前面说了只有密钥的拥有者才能解密得到pre-masterkey，masterkey，最后得到keyblock后，进行hash运算得到的结果才与发送方的一致。
8.Server发送ChangeCipherSpec
Server指示client从现在开始发送的消息都是加密过的
9.Server发送Finishd
与client发送Finished计算方法一致。
server发送的Finished里包含hash给client，client会进行校验，如果通过，说明握手过程中的数据没有被第三方篡改过，也说明server是之前交换证书的拥有者。
现在双方就可以开始后续通信，进入Applicationcontext了。
升级会员 