第二章对SSL握手协议的研究.docVIP

第一章.对SSL的基木概念和框架的介绍 第二章?对SSL握手|办议的研究（part-l ） 第三章?对SSL握手协议的研究（part-2） 第四章.对SSL握手协议细节和实现的介绍 第五章?对SSL记录协议细节和实现的介绍 第六章?对SSL的安全性分析 第七章.举例一种将usbkey融入java JSSE框架的解决方案 ? Client处理和回应Server Hello阶段 客户端收到服务器发过来的那些消息，耍做的是验证服务器证书，发送自 己的证书（如果双向认证），发送计算出的预主密码，发送证书验证消息。 Client Cert if i cate * Client Key Exchange Certificate Verify * [Change Cipher Spec] Client Finished Message * Optional or situationnt messages [Change Cipher Spec] is not a TLS handshake message but is an independent」TLS Protocol content type that helps the parties avoid a pipeline stall. 收到 Server Hello 在server hello阶段连续的发了多个消息，最先发出的是server hello , client收到后将SSL会话ID，服务器端的一个随机数，协 商岀的SSL协议版本号以及密钥套件放到会话缓存中。 收到 Server Certificates 接下来收到的应该是server端的证书消息了，取出所冇的消息，最头上 的是server证书，最末端的CA根证书。在SUN JDK JSSE中实现的SSL 是这样处理的： 从SSLContex屮取出trust manager ,如果用过java SSL编程的同学 应该知道，可以口己实现X509TrustManager和X509KeyManager两个接 口来定制对证书的验证，sun jdk屮就是调用这个trust manager的验 证方法来验证证书（在解决浏览器检测到证书是口签名的时候跳出警告框 的问题就是可以自己实现这个trust manager來让浏览器不跳出警告 框）。 JDK当然也冇默认的证书验证实现，就是验证签名冇效性，验证证书是否 过期等。证书签名的有效性验证是在取证书链中某证书中的公钥验证前一 个证书的签名，这样第一个证书就是用第二个证书的公钥來验证，那冇人 可能会问最后的根CA的证书谁来验证？根CA的证书是自签名的，就是 自己给自己签名，没人管的了，JDK中某个文件中有存储一堆可信任的 证书发行机构的证书列表，如果你的根CA在那个列表屮并对比后确实是 那个根CA的证书那就0K ,验证通过，这个可信任的机构也可以门己实 现那个trust manager來添加设置。 收到 Server Key Exchange 消息 RSA方式密钥交换消息则把消息中的加密用公钥放入会话缓存中，作为客 户端这边握手阶段的写密钥而不是用服务器证书中的公钥。 DH方式的消息就把消息中的p,g,Ys三个参数记录下来，有这些client 端就可以计算岀pre-master 了，只要冋头再把自己这边的Yc参数发过 去，server端就也能计算出相同的pre-maseter 了。 将消息中的证书类型列表和可信任证书发行机构列表保存下來，可在后面 发送客户端证巧时候拿来筛选证巧用。 收到 Server Hello Done 消息 收到这个消息后client端开始向server发消息了 发送 Client Certificates 消息 如果是server端要求客户端认证就会发这个消息，否则不发。客户端可 能会有多个证书，在JSSE里头多个客户端证书存储在keystore里头, 选哪个发过去呢？这吋候要用到server端之前发的cert request消 息中的支持的证书类型列表和信任的根CA列表，满足这个两个条件的第 一个证书链就会被选屮作为客户端证卩。 发送 Client Key Exchange 消息 若是RSA方式密钥交换，则产生一个48位随机数作为pre-master并 用服务器公钥加密后发出去 若是DH方式的密钥交换，则根据sever的g, p, Ys ,产生Xa和Yc , Xa和Ys能计算出pre-master ,把产生的Yc放入消息中发给 server ,这样server用它的Xb和Yc也能计算出pre-master 了。 计算出预主密码后就顺便把主密码（master secret）给算岀来了。算出 主密码就把对称密钥产生出來了。 发送 Certificate verify 消息