应用层协议(Https)(超详解)

前言：

        https是在http基础上的进行一些"加密"操作，也可以认为是http的强化版。

        在下面展开对https的讨论中，可能不会再涉及到http的相关协议，如有对http的疑惑或是其他不一样的看法可以浏览上一篇文章：应用层协议(Http)(超详解)-CSDN博客

        欢迎留言一起交流技术！！

Https：

        Https是什么，和Http有什么关系？

        HTTPS 也是⼀个应⽤层协议. 是在 HTTP 协议的基础上引⼊了⼀个加密层.

        HTTP 协议内容都是按照⽂本的⽅式明⽂传输的. 这就导致在传输过程中出现⼀些被篡改的情况.

        例如：

        当我们需要在浏览器上面下载一个应用程序，有的时候，我们点击下载，发现下载的程序并不是我们想要的，会自定开始下载"迅雷加速，360、qq浏览器......",当有这些情况出现的时候，那么大概率你被"运营商劫持"了！！

        此时从客户端发给服务器的请求被运营商劫持，并充当服务器发送响应请求，此时响应请求里面url的路径就会被篡改！！如下图：

        那么以前只有http西医的时候，这样的情况是时常发生的。

        现如今有了https的加入，这样的情况发生的概率大幅度下降！！

加密：

        加密是什么？如何加密？

        加密就是把 明⽂ (要传输的信息)进⾏⼀系列变换, ⽣成 密⽂ .

        解密就是把 密⽂ 再进⾏⼀系列变换, 还原成 明⽂

加密方法：

        对称加密：

        加密和解密使用同一把密钥。

        因此再客户端与服务器建立链接的时候，有一个"协商密钥"的过程，但是这个过程中密钥还是会被泄露出去，如下图：

    

        此时黑客可以充当中间站获取"密钥"，还是非常不安全，所以此时引入"非对称加密"。

        非对称加密：

         有一对密钥A和B：

        如果A负责加密，B就负责解密；

        如果B负责加密，A就负责解密；

注：公开出来的密钥叫做"公钥"，私藏起来的密钥叫做"私钥"。

最⼤的缺点就是运算速度⾮常慢

有两种用法：

1.通过公钥对明⽂加密, 变成密⽂

通过私钥对密⽂解密, 变成明⽂

也可以反着⽤

2.通过私钥对明⽂加密, 变成密⽂

通过公钥对密⽂解密, 变成明⽂

        客户端时如何获取到"公钥"呢？？

中间人攻击：

        在上述过程中，非对称加密实则是对"对称加密"而加密，也就是公钥负责对对称密钥加密。私钥对公钥解密拿到对称密钥。

        针对上述的问题，我们需要清楚：客户端拿到的公钥是由"服务器"发来的，此时还是涉及到一个被劫持的情况：

        此时"黑客"可以充当中间人：

具体过程如下：

1. 服务器具有⾮对称加密算法的公钥S，私钥S'

2. 中间⼈具有⾮对称加密算法的公钥M，私钥M'

3. 客⼾端向服务器发起请求，服务器明⽂传送公钥S给客⼾端

4. 中间⼈劫持数据报⽂，提取公钥S并保存好，然后将被劫持报⽂中的公钥S替换成为⾃⼰的公钥M，并将伪造报⽂发给客⼾端

5. 客⼾端收到报⽂，提取公钥M(⾃⼰当然不知道公钥被更换过了)，⾃⼰形成对称秘钥X，⽤公钥M加密X，形成报⽂发送给服务器

6. 中间⼈劫持后，直接⽤⾃⼰的私钥M'进⾏解密，得到通信秘钥X，再⽤曾经保存的服务端公钥S加密后，将报⽂推送给服务器

7. 服务器拿到报⽂，⽤⾃⼰的私钥S'解密，得到通信秘钥X

8. 双⽅开始采⽤X进⾏对称加密，进⾏通信。但是⼀切都在中间⼈的掌握中，劫持数据，进⾏窃听甚⾄修改，都是可以的。

引入证书：

        解决上述"中间人"攻击的关键就是需要让"客户端"识别出自己拿到的"公钥"是不是是由服务器发出的真的"公钥"。

        如何证明呢？此处引入第三方"公证机构"。

        如果想搭建自己的服务器，就必须在公证机构这里申请"证书"，向公证机构提交材料，

包括：网络域名，营业执照，备案号......

需要注意的是：申请证书的时候，需要在特定平台⽣成查，会同时⽣成⼀对⼉密钥对⼉，即公钥和私钥。这对密钥对⼉就是⽤来在⽹络通信中进⾏明⽂加密以及数字签名的。

        当服务端申请CA证书的时候，CA机构会对该服务端进⾏审核，并专⻔为该⽹站形成数字签名，过程如下：

1. CA机构拥有⾮对称加密的私钥A和公钥A'

2. CA机构对服务端申请的证书明⽂数据进⾏hash，形成数据摘要

3. 然后对数据摘要⽤CA私钥A'加密，得到数字签名S

服务端申请的证书明⽂和数字签名S 共同组成了数字证书 ，这样⼀份数字证书就可以颁发给服务端了

当客⼾端获取到这个证书之后, 会对证书进⾏校验(防⽌证书是伪造的).

1.判定证书的有效期是否过期

2.判定证书的发布机构是否受信任(操作系统中已内置的受信任的证书发布机构).

3.验证证书是否被篡改: 从系统中拿到该证书发布机构的公钥, 对签名解密, 得到⼀个 hash 值(称为数据摘要), 设为 hash1. 然后计算整个证书的 hash 值, 设为 hash2. 对⽐ hash1 和 hash2 是否相等. 如果相等, 则说明证书是没有被篡改过的。

常见问题：

        1.黑客会不会篡改证书？

        答案是： 由于他没有CA机构的私钥，所以⽆法hash之后⽤私钥加密形成签名，那么也就没法办法对篡改后的证书形成匹配的签名

        如果强⾏篡改，客⼾端收到该证书后会发现明⽂和签名解密后的值不⼀致，则说明证书已被篡改，证书不可信，从⽽终⽌向服务器传输信息，防⽌信息泄露给中间⼈

     2.黑客可不可以之间掉包证书，换成自己的证书？

        这个确实能做到证书的整体掉包，但是别忘记，证书明⽂中包含了域名等服务端认证信息，如果整体掉包，客⼾端依旧能够识别出来。

永远记住：中间⼈没有CA私钥，所以对任何证书都⽆法进⾏合法修改，包括⾃⼰的

       3.客户端最后如何解析服务器传过来的密文的？

        由于摘要内容在网络传输过程中都是以hash值的方式加密传输，该加密是由签证机构自己的私钥进行一系列的加密的，最后只能由该公证机构的公钥进行hash值解密，最后拿到密文。

        客⼾端通过操作系统⾥已经存的了的证书发布机构的公钥进⾏解密, 还原出原始的哈希值, 再进⾏校验。