HTTP的缺点

HTTP协议通信使用明文（未加密的报文），不对传输内容进行加密。如果使用fiddler等抓包工具可以很轻松地截取到HTTP的请求与响应报文（事实上我在做网站的时候经常用fiddler抓包来查看报文内容）
HTTP不会验证通信双方的身份。因此有可能出现别的人伪装成对方来和你通信，即通信双方很可能是伪装的，比如我访问百度首页，我并不知道这个响应就是百度返回给我的，也可能是别的人伪装成百度来和我通信
HTTP无法证明报文的完整性。有可能报文被截取以后被篡改了再发给我，这样我得到的就是被篡改了的报文。

以上三个缺点，可以简要地归结为如下三点：易被窃听，无身份验证，易被篡改。

事实上，不仅仅是HTTP协议，几乎所有的不加密的协议都会出现此类问题。

在日常互联网浏览网页时，我们接触到的大多都是 HTTP 协议，这种协议是未加密，即明文的,这使得 HTTP 协议在传输隐私数据时非常不安全。因此，浏览器鼻祖 Netscape 公司设计了 SSL（Secure Sockets Layer）协议，用于对 HTTP 协议传输进行数据加密，即 HTTPS 。
SSL 目前版本是 3.0，之后升级为了 TLS（Transport Layer Security）协议，TLS 目前为 1.2 版本。如未特别说明，SSL 与 TLS 均指同一协议。

HTTP和HTTPS协议的区别

HTTPS协议需要到证书颁发机构（Certificate Authority，简称CA）申请证书，一般免费证书很少，需要交费。
HTTP是超文本传输协议，信息是明文传输，HTTPS则是具有安全性的SSL加密传输协议。
HTTP和HTTPS使用的是完全不同的连接方式，使用的端口也不一样,前者是80,后者是443。
HTTP的连接很简单,是无状态的。
HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比HTTP协议安全。
HTTPS 和HTTP 协议相比提供了：

数据完整性：内容传输经过完整性校验
数据隐私性：内容经过对称加密，每个连接生成一个唯一的加密密钥
身份认证：第三方无法伪造服务端（客户端）身份
数据完整性和隐私性由TLS Record Protocol保证，身份认证由TLS Handshaking Protocols实现。

HTTPS 下的加密

加密算法

加密算法一般分为两种:对称加密和非对称加密。
对称加密(密钥加密):就是指加密和解密使用的是相同的密钥。
非对称加密(公钥加密):就是指加密和解密使用的是不同的密钥。

在这里插入图片描述

HTTPS一般使用的加密与HASH算法

非对称加密算法：RSA，DSA/DSS
对称加密算法：AES，RC4，3DES
HASH算法：MD5，SHA1，SHA256

RSA 算法的安全性是建立在乘法不可逆或者大数因子很难分解的基础上。
RSA 的推导和实现涉及到了欧拉函数和费马定理及模反元素的概念。
RSA 算法是’统治世界’的最重要算法之一，而且从目前来看，RSA 也是 ‘HTTPS 体系中最重要的算法’，没有之一。
非对称加密算法用于在握手过程中加密生成的密码。
对称加密算法用于对真正传输的数据进行加密。
HASH算法用于验证数据的完整性。

由于浏览器生成的密码是整个数据加密的关键因此在传输的时候使用了非对称加密算法对其加密。
非对称加密算法会生成公钥和私钥，公钥只能用于加密数据，因此可以随意传输，网站的私钥用于对数据进行解密，所以网站都会非常小心的保管自己的私钥，防止泄漏。

HTTPS的加密通信过程

客户端发起HTTPS 请求

SSL 连接总是由客户端启动，在 SSL 会话开始时，执行 SSL 握手。
用户在浏览器里输入一个https 网址，然后连接到server 的443 端口。
客户端发送以下：

列出客户端密支持的加密方式列表（以客户端首选项顺序排序），如 SSL 的版本、客户端支持的加密算法和客户端支持的数据压缩方法(Hash 算法)。
包含 28 字节的随机数，client_random

服务端的配置

采用HTTPS 协议的服务器必须要有一套数字证书，可以自己制作，也可以向组织申请。
区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面。这套证书其实就是一对公钥和私钥。
对于公钥和私钥可以想象成一把钥匙和一个锁头，只是全世界只有你一个人有这把钥匙，你可以把锁头给别人，别人可以用这个锁把重要的东西锁起来，然后发给你，因为只有你一个人有这把钥匙，所以只有你才能看到被这把锁锁起来的东西。
客户端和服务器至少必须支持一个公共密码对，否则握手失败。
服务器一般选择最大的公共密码对

传送证书

服务器端返回以下：

服务器端选出的一套加密算法和 Hash 算法
服务器生成的随机数 server_random
SSL 数字证书（服务器使用带有 SSL 的 X.509 V3 数字证书），这个证书包含网站地址，公钥 public_key ，证书的颁发机构，过期时间等等。

客户端解析证书

这部分工作是由客户端的TLS来完成的

首先会验证公钥是否有效，比如颁发机构，过期时间等等。
如果发现异常，则会弹出一个警告框，提示证书存在问题。
如果证书没有问题，那么就生成一个随机值。
然后用证书对该随机值进行加密。就好像上面说的，把随机值用锁头锁起来，这样除非有钥匙，不然看不到被锁住的内容。

传送加密信息

客户端发送以下：

这部分传送的是用证书加密后的随机值
目的就是让服务端得到这个随机值，以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。

服务端解密信息

服务端用私钥解密后，得到了客户端传过来的随机值(私钥)
然后把内容通过该值进行对称加密。
所谓对称加密就是，将信息和私钥（随机值）通过某种算法混合在一起，这样除非知道私钥（随机值），不然无法获取内容，而正好客户端和服务端都知道这个私钥（随机值），所以只要加密算法够彪悍，私钥（随机值）够复杂，数据就够安全。

传输加密后的信息

服务器端返回以下：服务端返回用私钥（随机值）加密后的信息，可以在客户端被还原

客户端解密信息

客户端用之前生成的私钥解密服务段传过来的信息，于是获取了解密后的内容。整个过程第三方即使监听到了数据，也束手无策。

HTTPS的加密通信过程总结

客户端信任了服务端的证书，并和服务端确认了双方的加密算法【握手中需要的非对称算法、握手信息验证的hash算法、正文传输的对称加密】；
客户端生成随机数，通过证书中的公钥按照约定的非对称加密算法进行加密，得到加密的随机数秘钥，同时将之前所有的通信信息【秘钥算法套件、证书等所有的通信内容】按照约定的hash/摘要算法获取hash值，并使用随机数和协商好的对称加密算法进行签名加密，将随机数秘钥和加密签名发送到服务端。
服务端收到随机数秘钥和加密签名，先使用私钥将随机数按照约定的非对称解密算法进行解密，获取随机数，同时使用随机数按照约定的对称解密算法进行解密，获取待验证的hash值，将之前的通信消息体【秘钥算法套件、证书等所有的通信内容】按照约定的hash/摘要算法获取hash值，与刚才解密获取的待验证的hash值对比，验证加密成功与否。
成功以后，服务器再次将之前所有的通信信息【秘钥算法套件、证书等所有的通信内容】按照约定的hash/摘要算法获取hash值，并使用随机数和协商好的对称加密算法进行签名加密，将随机数秘钥发送到客户端，
客户端使用随机数按照约定的对称解密算法进行解密，获取待验证的hash值，将之前的通信消息体【秘钥算法套件、证书等所有的通信内容】按照约定的hash/摘要算法获取hash值，与刚才解密获取的待验证的hash值对比，验证加密成功与否，
成功的话整个链接过程完成，之后将使用随机数和约定的对称加密算法进行密文通信，【如果上面的任何步骤出现问题，都将会结束整个握手过程，导致建立安全连接失败】。

在这里插入图片描述

原文链接：https://blog.csdn.net/qq_43313035/article/details/100081982