前文说到了6 组key material, 12个hash 值,很是迷惑, 今天才搞明白, 原来全部这些内容就是 对称密钥的内容。html
上面的图 虽然不是很清晰,可是, 其实也已经写明白了, 就是 右边的 CBC 模式的部分。对于 CBC模式的DES加密算法, 是须要这些内容的。算法
关于 身份认证, 其实不是 防止 篡改, 说的另外的一回事。 通常就是说,防止 middler man, 就是验证 服务端就是 我想要的那个。 经过 证书 验证, 能够完成 身份的认证。session
固然, 其实咱们也能够 对客户端 进行认证, 这也是 身份认证的一部分。ui
DH 算法的通讯创建过程是这样的:加密
总之,若是协商过程使用 RSA 的话, 创建tls / ssl通道(正式传输 tls 上层数据以前)有7个 交互过程:spa
1 C->S:Client Hello
2 S->C:Server Hello
3 S->C:Certificate, Server Key Exchange, Server Hello Done
4 C->S:Client Key Change
5 C->S:Change Cipher Spec
6 C->S:Encryted Handshake Messagex`
7 S->C:Change Cipher Spec, Encryted Handshake Message
8 C->S/S->C:Application Data.net
简单的SSL握手链接过程(仅Server端交换证书给client):server
1.C->S:client发送ClientHello,指定版本,随机数(RN),全部支持的密码套件(CipherSuites)xml
2.S->C:server回应ServerHello,指定版本,RN,选择CipherSuites,会话ID(Session ID)htm
3.S->C:server发送Certificate
4.S->C:Server发送ServerHelloDone
5.C->S:Client发送ClientKeyExchange,用于与server交换session key
6.C->S:Client发送ChangeCipherSpec,指示Server从如今开始发送的消息都是加密过的
7.C->S:Client发送Finishd,包含了前面全部握手消息的hash,可让server验证握手过程是否被第三方篡改
8.S->C:Server发送ChangeCipherSpec,指示Client从如今开始发送的消息都是加密过的
9.S->C:Server发送Finishd,包含了前面全部握手消息的hash,可让client验证握手过程是否被第三方篡改,而且证实本身是Certificate密钥的拥有者,即证实本身的身份
已经SSL握手完成,已经 创建tls / ssl通道了。
10 C->S/S->C:Application Data 开始正式数据交互
实际上呢, 2/3/4 几个步骤是能够合并的, 5/6/7 也是,8/9 也是。 因此抓包的时候能够看到 4次通讯。
参考:
https://blog.csdn.net/tterminator/article/details/50675540 很是很是详细
https://blog.csdn.net/phunxm/article/details/72853376 很是很是详细
https://blog.csdn.net/a_tu_/article/details/77119532
http://www.cnblogs.com/svan/p/5090201.html