HTTPS 原理

最新推荐文章于 2024-06-21 13:34:53 发布

C0oOder

最新推荐文章于 2024-06-21 13:34:53 发布

阅读量3.7k

点赞数

分类专栏：网络文章标签： https ssl tls CA 非对称加密

本文链接：https://blog.csdn.net/weixin_44244088/article/details/123436053

版权

网络专栏收录该内容

7 篇文章 0 订阅

订阅专栏

HTTPS 原理

1.简介

什么是HTTPS？ HTTP + SSL（目前是TLS,可以看做是SSL 的升级版本）,

百度百科：是以安全为目标的 HTTP 通道，在HTTP的基础上通过传输加密和身份认证保证了传输过程的安全性。HTTPS 在HTTP 的基础下加入SSL，HTTPS 的安全基础是 SSL，因此加密的详细内容就需要 SSL。 HTTPS 存在不同于 HTTP 的默认端口及一个加密/身份验证层（在 HTTP与 TCP 之间）。这个系统提供了身份验证与加密通讯方法；

说明了 HTTP 不是很安全！

2.HTTP 问题

HTTP 通信协议里面都是明文传输，如下图在数据传输的每一个节点传输的信息都有可能被泄露，数据不安全；

在这里插入图片描述

3.给HTTP加密

如果我们是这个HTTPS 协议的设计者，我们该如何设计协议，如何对HTTP 协议里面的数据加密？

3.1 方案一

对称加密算法，算法示例：des，3des ，算法效率高

秘钥+明文+ 加密 = 密文 --> 秘钥+解密 -->解密 --> 明文

内置加密算法，中间节点也可以获取到加密算法，也可以解密通信数据；但是加密算法也可以被中间节点获取到，然后就可以破解数据；

在这里插入图片描述

3.2 方案二

非对称加密，算法示例：RSA ，算法效率低

明文+公钥 +加密 = 密文 ---->>> 私钥+解密 -->明文公钥加密只有私钥才能解密，公钥不能解密

明文+ 私钥+加密 = 密文 ---->>> 公钥+解密 -->明文私钥加密公钥才能解密，(没什么意义，私钥可以生产公钥)

私钥可以生成公钥，公钥私钥特别长，是一串很长的字符串

对方案一进行升级，算法还是原来的算法，那么我们对算法添加一个随机数作为算法参数，但是这个随机数是加密的，只有服务器可以破解这个解密这个随机数就可以了，然后再使用算法(随机数) 对数据对称加密传输；

在这里插入图片描述

这样加密的通信数据是安全的；

在这里插入图片描述

1.如步骤3中公钥（拦截步骤2的公钥）无法对浏览器发送的数据解密，因为公钥发送的数据无法解密公钥加密的数据，只能发给服务器

在这里插入图片描述

2.服务器返回的数据，因为中间节点持有公钥（拦截步骤2的公钥），但是无法篡改数据，因为没有私钥；

上面两点就是非对称加密的情况下，浏览器发给服务器的数据，中间节点无法解密；服务器发给浏览器的数据，中间节点也不能篡改；

问题似乎得到了解决，但是，如果是中间节点伪造请求

在这里插入图片描述

浏览器收到的时假的公钥无法判断是否是服务器发送的公钥！！！！

当凭借浏览器和服务端是无法解决这个问题了；

4.CA 与证书

CA:证书颁发机构（CA, Certificate Authority）即颁发数字证书的机构。是负责发放和管理数字证书的权威机构，并作为电子商务交易中受信任的第三方，承担公钥体系中公钥的合法性检验的责任；

作为第三方机构CA，负责加密电子网站里面公钥的加密(CA 的私钥加密)，内外一方面把CA公钥内置在操作系统中，浏览器可以直接获取(不走网络)；用来保证服务器公钥传输的安全性；

在这里插入图片描述

5.HTTPS的实现方式

基于上一章节中，HTTPS 中引入CA机构的方式，来保证证书服务器的公钥可以安全的在证书中保存，并发送到浏览器客户端；后面的大致思想和步骤就是浏览器用证书中服务器的公钥加密一个随机数发送给服务端(非对称加密，中间人无法获取)，服务端获取到随机数后使用服务器自己私钥解密，然后再根据这个随机数采用对称加密的算法对通信内容进行对称加密传输；

在这里插入图片描述

6.求证HTTPS 通信

抓包分析：工具 Wireshark

开启请求

6.1.建立连接

TCP 三次握手之前网络二.用电信号传输 TCP/IP 数据 有介绍就不详述了

在这里插入图片描述

6.2 TLS第一次握手

(看52584 端口的通信) 第一次请求服务端，第一次客户端 Client Hello ，生成一个随机数，并告知支持的加密套件

在这里插入图片描述

加密套件

在这里插入图片描述

6.3 TLS第二次握手

服务端向客户端发起，发送服务端的随机数，协商的加密算法

在这里插入图片描述

发送CA证书

在这里插入图片描述

发送公钥，并发送Server done 第二次握手结束

在这里插入图片描述

6.4 TLS 第三次握手

浏览器发送公钥加密好的pubkey 也叫 pre-master secret 并表示可以通话客户端加密已经就绪；

在这里插入图片描述

6.5 TLS 第四次握手

服务器表示也准备就绪

在这里插入图片描述

7.整体流程分析

在这里插入图片描述

8.总结

HTTP 的SSL 和TLS 通信是为了安全的不被第三方知晓的获取会话秘钥，获取会话秘钥后使用对称加密来加密数据；

安全的不被第三方知晓的获取：数据传输安全性，使用非对称加密；

使用非对称加密：使用非对称加密对数据传输数据，但是服务器要是想和浏览器非对称传输数据，必须安全的发送公钥到浏览器；

安全的发送公钥：服务器和客户端两种是不能完成安全的发送公钥，无法判断服务器的公钥是不是伪造的，引入第三方机构CA，CA用CA的私钥加密服务器公钥，然后把公钥内置操作系统，无法篡改，第三方节点可以获取服务器证书和解开证书，但是无法伪造证书，因为没有CA私钥，(伪造一对CA公私钥也不行，因为CA公钥内置在操作系统)；

安全的发送公钥后，就可以安全的发送数据了，但是只用非对称加密通信一次就可以，就是发送对称加密的会话秘钥，非对称加密比较消耗性能；

得到会话秘钥：服务器和浏览器开始加密通话；

为什么是三个随机数？

网上搜到的：不管是客户端还是服务器，都需要随机数，这样生成的密钥才不会每次都一样。由于SSL协议中证书是静态的，因此十分有必要引入一种随机因素来保证协商出来的密钥的随机性。对于RSA密钥交换算法来说，pre-master secret本身就是一个随机数，再加上hello消息中的随机，三个随机数通过一个密钥导出器最终导出一个对称密钥。pre-master secret的存在在于SSL协议不信任每个主机都能产生完全随机的随机数，如果随机数不随机，那么pre-mastersecret就有可能被猜出来，那么仅适用pre-master secret作为密钥就不合适了，因此必须引入新的随机因素，那么客户端和服务器加上pre-master secret三个随机数一同生成的密钥就不容易被猜出了，一个伪随机可能完全不随机，可是是三个伪随机就十分接近随机了，每增加一个自由度，随机性增加的可不是一。"

仅适用pre-master secret作为密钥就不合适了，因此必须引入新的随机因素，那么客户端和服务器加上pre-master secret三个随机数一同生成的密钥就不容易被猜出了，一个伪随机可能完全不随机，可是是三个伪随机就十分接近随机了，每增加一个自由度，随机性增加的可不是一。"