HTTPS加密及握手

最新推荐文章于 2022-07-03 17:34:51 发布

Yisnow.

最新推荐文章于 2022-07-03 17:34:51 发布

阅读量375

点赞数

分类专栏：计算机网络

本文链接：https://blog.csdn.net/qq_37935909/article/details/108033662

版权

计算机网络专栏收录该内容

5 篇文章 0 订阅

订阅专栏

1、HTTPS通信过程

在这里插入图片描述
先进性TCP三次握手。
步骤 1：客户端通过发送 Client Hello 报文开始 SSL 通信。报文中包
含客户端支持的 SSL 的指定版本、加密组件（Cipher Suite）列表（所
使用的加密算法及密钥长度等）。
步骤 2：服务器可进行 SSL 通信时，会以 Server Hello 报文作为应
答。和客户端一样，在报文中包含 SSL 版本以及加密组件。服务器的
加密组件内容是从接收到的客户端加密组件内筛选出来的。
步骤 3：之后服务器发送 Certificate 报文。报文中包含公开密钥证
书。
步骤 4：最后服务器发送 Server Hello Done 报文通知客户端，最初阶
段的 SSL 握手协商部分结束。
步骤 5： SSL 第一次握手结束之后，客户端以 Client Key Exchange 报
文作为回应。报文中包含通信加密中使用的一种被称为 Pre-master
secret 的随机密码串。该报文已用步骤 3 中的公开密钥进行加密。
步骤 6：接着客户端继续发送 Change Cipher Spec 报文。该报文会提
示服务器，在此报文之后的通信会采用 Pre-master secret 密钥加密。
步骤 7：客户端发送 Finished 报文。该报文包含连接至今全部报文的
整体校验值。这次握手协商是否能够成功，要以服务器是否能够正确
解密该报文作为判定标准。
步骤 8：服务器同样发送 Change Cipher Spec 报文。
步骤 9：服务器同样发送 Finished 报文。
步骤 10：服务器和客户端的 Finished 报文交换完毕之后，SSL 连接
就算建立完成。当然，通信会受到 SSL 的保护。从此处开始进行应用
层协议的通信，即发送 HTTP 请求。
步骤 11：应用层协议通信，即发送 HTTP 响应。
步骤 12：最后由客户端断开连接。断开连接时，发送 close_notify 报
文。上图做了一些省略，这步之后再发送 TCP FIN 报文来关闭与 TCP
的通信。

2 HTTPS

HTTP+ 加密 + 认证 + 完整性保护=HTTPS
通常，HTTP 直接和 TCP 通信。当使用 SSL 时，则演变成先和 SSL 通信，再由 SSL 和 TCP 通信了。简言之，所谓 HTTPS，其实就是身披SSL 协议这层外壳的 HTTP。

2.1 对称密钥加密

对称密钥加密：加密和解密同用一个密钥的方式。
以共享密钥方式加密时必须将密钥也发给对方。可究竟怎样才能安全地转交？在互联网上转发密钥时，如果通信被监听那么密钥就可会落入攻击者之手，同时也就失去了加密的意义。另外还得设法安全地保管接收到的密钥。

2.2 非对称密钥加密

    使用一对非对称的密钥。一把叫做私有密钥（private key），另一把叫做公开密钥（public key）。顾名思义，私有密钥不能让其他任何人知道，而公开密钥则可以随意发布，任何人都可以获得。使用公开密钥加密方式，发送密文的一方使用对方的公开密钥进行加密处理，对方收到被加密的信息后，再使用自己的私有密钥进行解密。利用这种方式，不需要发送用来解密的私有密钥，也不必担心密钥被攻击者窃听而盗走。
    另外，要想根据密文和公开密钥，恢复到信息原文是异常困难的，因为解密过程就是在对离散对数进行求值，这并非轻而易举就能办到。退一步讲，如果能对一个非常大的整数做到快速地因式分解，那么密码破解还是存在希望的。但就目前的技术来看是不太现实的。
    服务器先把公钥直接明文传输给浏览器，之后浏览器向服务器传数据前都先用这个公钥加密好再传，这条数据的安全似乎可以保障了！因为只有服务器有相应的私钥能解开这条数据。

然而由服务器到浏览器的这条路怎么保障安全？如果服务器用它的的私钥加密数据传给浏览器，那么浏览器用公钥可以解密它，而这个公钥是一开始通过明文传输给浏览器的，这个公钥被谁劫持到的话，他也能用该公钥解密服务器传来的信息了。所以目前似乎只能保证由浏览器向服务器传输数据时的安全性

2.3 混合加密方式

在这里插入图片描述

某网站拥有用于非对称加密的公钥A、私钥A’。
浏览器像网站服务器请求，服务器把公钥A明文给传输浏览器
浏览器随机生成一个用于对称加密的密钥X，用公钥A加密后传给服务器。
服务器拿到后用私钥A’解密得到密钥X。
这样双方就都拥有密钥X了，且别人无法知道它。之后双方所有数据都用密钥X加密解密。完美！HTTPS基本就是采用了这种方案。
完美？还是有漏洞的。

中间人攻击
中间人的确无法得到浏览器生成的密钥B，这个密钥本身被公钥A加密了，只有服务器才有私钥A’解开拿到它呀！然而中间人却完全不需要拿到密钥A’就能干坏事了。请看：

某网站拥有用于非对称加密的公钥A、私钥A’。
浏览器向网站服务器请求，服务器把公钥A明文给传输浏览器。
中间人劫持到公钥A，保存下来，把数据包中的公钥A替换成自己伪造的公钥B（它当然也拥有公钥B对应的私钥B’）。
浏览器随机生成一个用于对称加密的密钥X，用公钥B（浏览器不知道公钥被替换了）加密后传给服务器。
中间人劫持后用私钥B’解密得到密钥X，再用公钥A加密后传给服务器。
服务器拿到后用私钥A’解密得到密钥X。
这样在双方都不会发现异常的情况下，中间人得到了密钥B。根本原因是浏览器无法确认自己收到的公钥是不是网站自己的。那么下一步就是解决下面这个问题：
如何证明浏览器收到的公钥一定是该网站的公钥？
现实生活中，如果想证明某身份证号一定是小明的，怎么办？看身份证。这里政府机构起到了“公信”的作用，身份证是由它颁发的，它本身的权威可以对一个人的身份信息作出证明。互联网中能不能搞这么个公信机构呢？给网站颁发一个“身份证”？

2.4 HTTPS存在的问题

当使用 SSL 时，它的处理速度会变慢。
SSL 的慢分两种。一种是指通信慢。另一种是指由于大量消耗CPU 及内存等资源，导致处理速度变慢。
为什么不一直使用 HTTPS
其中一个原因是，因为与纯文本通信相比，加密通信会消耗更多的CPU 及内存资源。如果每次通信都加密，会消耗相当多的资源，平摊到一台计算机上时，能够处理的请求数量必定也会随之减少。
因此，如果是非敏感信息则使用 HTTP 通信，只有在包含个人信息等敏感数据时，才利用 HTTPS 加密通信。特别是每当那些访问量较多的 Web 网站在进行加密处理时，它们所承担着的负载不容小觑。在进行加密处理时，并非对所有内容都进行加密处理，而是仅在那些需要信息隐藏时才会加密，以节约资源。
参考：图解HTTP
https://zhuanlan.zhihu.com/p/43789231