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了后，就进入了 对称加密的 通道了吧！