这里的“PRF”就是伪随机数函数 ， 它基于密码套件里的最后一个参数 ， 比如这次的 SHA384 ， 通过摘要算法来再一次强化“Master Secret”的随机性 。 复制代码
主密钥有 48 字节 ， 但它也不是最终用于通信的会话密钥 ， 还会再用 PRF 扩展出更多的密钥 ， 比如客户端发送用的会话密钥（client_write_key）、服务器发送用的会话密钥（server_write_key）等等 ， 避免只用一个密钥带来的安全隐患 。
有了主密钥和派生的会话密钥 ， 握手就快结束了 。 客户端发一个“Change Cipher Spec” ， 然后再发一个“Finished”消息 ， 把之前所有发送的数据做个摘要 ， 再加密一下 ， 让服务器做个验证 。
意思就是告诉服务器：“后面都改用对称算法加密通信了啊 ， 用的就是打招呼时说的 AES ， 加密对不对还得你测一下 。 ”
服务器也是同样的操作 ， 发“Change Cipher Spec”和“Finished”消息 ， 双方都验证加密解密 OK ， 握手正式结束 ， 后面就收发被加密的 HTTP 请求和响应了 。
RSA 握手过程整个握手过程可真是够复杂的 ， 但你可能会问了 ， 好像这个过程和其他地方看到的不一样呢？
刚才说的其实是如今主流的 TLS 握手过程 ， 这与传统的握手有两点不同 。
第一个 ， 使用 ECDHE 实现密钥交换 ， 而不是 RSA ， 所以会在服务器端发出“Server Key Exchange”消息 。
第二个 ， 因为使用了 ECDHE ， 客户端可以不用等到服务器发回“Finished”确认握手完毕 ， 立即就发出 HTTP 报文 ， 省去了一个消息往返的时间浪费 。 这个叫“TLS False Start” ， 意思就是“抢跑” ， 和“TCP Fast Open”有点像 ， 都是不等连接完全建立就提前发应用数据 ， 提高传输的效率 。
这里我也画了个图 。
文章插图
大体的流程没有变 ， 只是“Pre-Master”不再需要用算法生成 ， 而是客户端直接生成随机数 ， 然后用服务器的公钥加密 ， 通过“Client Key Exchange”消息发给服务器 。 服务器再用私钥解密 ， 这样双方也实现了共享三个随机数 ， 就可以生成主密钥 。
双向认证到这里 TLS 握手就基本讲完了 。
不过上面说的是“单向认证”握手过程 ， 只认证了服务器的身份 ， 而没有认证客户端的身份 。 这是因为通常单向认证通过后已经建立了安全通信 ， 用账号、密码等简单的手段就能够确认用户的真实身份 。
但为了防止账号、密码被盗 ， 有的时候（比如网上银行）还会使用 U 盾给用户颁发客户端证书 ， 实现“双向认证” ， 这样会更加安全 。
双向认证的流程也没有太多变化 ， 只是在“Server Hello Done”之后 ， “Client Key Exchange”之前 ， 客户端要发送“Client Certificate”消息 ， 服务器收到后也把证书链走一遍 ， 验证客户端的身份 。
作者：huansky
来源：

稿源：(未知)

【傻大方】网址：http://www.shadafang.com/c/111J2Hc2020.html

标题：深入浅出 HTTPS (详解版)( 六 )