HTTPS 基本流程2

Https在真正请求数据前，先会与服务有几次握手验证，以证明相互的身份，以下图为例

2.1  验证流程

注：文中所写的序号与图不对应但流程是对应的

1 客户端发起一个https的请求，把自身支持的一系列Cipher Suite（密钥算法套件，简称Cipher）发送给服务端

2  服务端，接收到客户端所有的Cipher后与自身支持的对比，如果不支持则连接断开，反之则会从中选出一种加密算法和HASH算法

以证书的形式返回给客户端 证书中还包含了 公钥 颁证机构 网址 失效日期等等。

3 客户端收到服务端响应后会做以下几件事

3.1 验证证书的合法性

　　  颁发证书的机构是否合法与是否过期，证书中包含的网站地址是否与正在访问的地址一致等

证书验证通过后，在浏览器的地址栏会加上一把小锁(每家浏览器验证通过后的提示不一样 不做讨论)

3.2 生成随机密码

如果证书验证通过，或者用户接受了不授信的证书，此时浏览器会生成一串随机数，然后用证书中的公钥加密。 　　　　　　

3.3 HASH握手信息

用最开始约定好的HASH方式，把握手消息取HASH值，  然后用 随机数加密 “握手消息+握手消息HASH值(签名)”  并一起发送给服务端

在这里之所以要取握手消息的HASH值，主要是把握手消息做一个签名，用于验证握手消息在传输过程中没有被篡改过。

4  服务端拿到客户端传来的密文，用自己的私钥来解密握手消息取出随机数密码，再用随机数密码 解密 握手消息与HASH值，并与传过来的HASH值做对比确认是否一致。

然后用随机密码加密一段握手消息(握手消息+握手消息的HASH值 )给客户端

5  客户端用随机数解密并计算握手消息的HASH，如果与服务端发来的HASH一致，此时握手过程结束，之后所有的通信数据将由之前浏览器生成的随机密码并利用对称加密算法进行加密

因为这串密钥只有客户端和服务端知道，所以即使中间请求被拦截也是没法解密数据的，以此保证了通信的安全

非对称加密算法：RSA，DSA/DSS     在客户端与服务端相互验证的过程中用的是对称加密 
对称加密算法：AES，RC4，3DES     客户端与服务端相互验证通过后，以随机数作为密钥时，就是对称加密
HASH算法：MD5，SHA1，SHA256  在确认握手消息没有被篡改时

==================================================================================

每个人都讲得不太一样，虽然基本上是相同的。

第一二步的时候，是需要随机数的，这里没有写出来。

关于  3.3 HASH握手信息 就更加迷惑了。

用最开始约定好的HASH方式，把握手消息取HASH值，  然后用 随机数加密 “握手消息+握手消息HASH值(签名)”  并一起发送给服务端

首先，握手消息是什么？看其他的文章，一般就是pre-master （又称为premaster、premaster secret ？），把premaster 按照第一次握手确定的hash算法 取hash，然后 “ 随机数加密 ”， 这里又是一个 随机数？ 搞不懂了！ 这个随机数是如何产生的？ 内容是？ 我总觉得这里可能是写错了， 这里应该是 用服务器公钥加密 " 握手消息+握手消息HASH值 "。

但是有的书上又说用 " 服务器公钥加密 premaster （也就是握手消息） "， 这里是没有用公钥加密 premaster 的hash 的 。 如果这样做，也没有什么，但这样又会衍生一点问题： 假设服务端拿到这个加密后的 “ 握手消息+握手消息HASH值 ”， 用私钥解密， 那么得到 “ premaster握手消息+premaster握手消息HASH值 ”， 那么我需要把premaster 取出来， 但是现在 premaster 和 premaster 的hash 混在了一块， 如何分离？ 除非 中间有个固定的分隔符？其实这样想是错的， premaster 并不会发送， 永远不会发送。

“ 并一起发送给服务端 ” 这里的并一起，是指哪些内容？ 想了想， 应该是这样的： 先发送 premaster  公钥加密值， 再发送premaster 的hash 的 公钥加密值。分别发送，（应该是分两次发送， 不然， 又需要一个 分隔符了， 比较麻烦， 看到其他资料的介绍也是 分多次 ）。 所以说呢，这里的 “ 并一起 ”  有相当大的 迷惑，容易产生误解。。

但是呢，  premaster 的hash 的 公钥加密值， 有必要发送吗？ 发送是保险起见， 为了验证premaster  是否已经被更改， 因为服务器的公钥是 任何人都可见的，如果流量被middleman 劫持，随便加密了一个 随机数，然后 用公钥加密，然后发送过来， 服务器端没法确定它是否已经发生 改变，然后把middleman 当做最开始通信的客户端，然后和middleman 通信，这样就出问题了。 因为http是无状态的， 客户端-服务端 建立通信过程有很多步骤，每一个步骤都可能 被劫持，因此， 在没有完全建立通信、信道 之前，每一个步骤都要验证。所以后面这一句是 非常正确的：

在这里之所以要取握手消息的HASH值，主要是把握手消息做一个签名，用于验证握手消息在传输过程中没有被篡改过。

握手消息的HASH值 是必不可少需要发送给服务端的。但是我又看到有资料这样描述：

encrypted_handshake_message，结合之前所有通信参数的 hash 值与其它相关信息生成一段数据，采用协商密钥 session secret 与算法进行加密，然后发送给服务器用于数据与握手验证

这样的描述，也十分的不清晰， " 结合之前所有通信参数的 hash 值 " 到底是什么？ 莫非就是前面说的 premaster 的hash ？ “ 与其它相关信息生成一段数据 ” 具体什么数据不要紧，因为 我们仅仅是用它做比较， 以验证 协商密钥 session secret （我觉得就是 master secret） 的正确。 问题是 这里的 “ 与 ”， 怎么理解， 是直接拼在一起吗？ 这样的话，premaster 的hash 和 “ 一段数据 ” 中间是不是又需要一个分隔符？

random client 和 random server, Pre-master, 容易理解， Master secret 还好理解, key material, 又是什么？

Key 经过12轮迭代计算会获取到12个 hash 值，分组成为6个元素，列表如下：

竟然出现了 12个 hash 值 ，我看一般资料根本没有题这么详细。 是真的有吗？

(2).密钥使用

Key 经过12轮迭代计算会获取到12个 hash 值，分组成为6个元素，列表如下：

(a) mac key、encryption key 和 IV 是一组加密元素，分别被客户端和服务器使用，但是这两组元素都被两边同时获取;

    (b) 客户端使用 client 组元素加密数据，服务器使用 client 元素解密;服务器使用 server 元素加密，client 使用 server 元素解密;
    (c) 双向通信的不同方向使用的密钥不同，破解通信至少需要破解两次;
    (d) encryption key 用于对称加密数据;
    (e) IV 作为很多加密算法的初始化向量使用，具体可以研究对称加密算法;
    (f) Mac key 用于数据的完整性校验;

（3）.数据加密通信过程
    (a) 对应用层数据进行分片成合适的 block;
    (b) 为分片数据编号，防止重放攻击;
    (c) 使用协商的压缩算法压缩数据;
    (d) 计算 MAC 值和压缩数据组成传输数据;
    (e) 使用 client encryption key 加密数据，发送给服务器 server;
    (f) server 收到数据之后使用 client encrytion key 解密，校验数据，解压缩数据，重新组装。
注：MAC值的计算包括两个 Hash 值：client Mac key 和 Hash (编号、包类型、长度、压缩数据)。
--------------------- 
作者：hherima 
来源：CSDN 
原文：https://blog.csdn.net/hherima/article/details/52469674 
版权声明：本文为博主原创文章，转载请附上博文链接！

这里的“ 数据加密通信过程 ” 不好理解，分片，压缩，计算MAC，可以理解。client encryption key 是什么？  是不是就是  cipher suite 中 确认过的  对称加密算法 的密钥吗 ?  不应该就是 协商密钥吗？  不应该就是 master secret 吗？  server encryption key 就更加不好理解了， 通信建立ok了后，就进入了 对称加密的 通道了吧！