部分内容来源：小林coding
详细解析
Http的风险
HTTP 由于是明文传输，所以安全上存在以下三个风险：
1.窃听风险
比如通信链路上可以获取通信内容，用户号容易没。
2.篡改风险
比如强制植入垃圾广告，视觉污染，用户眼容易瞎。
3.冒充风险
比如冒充淘宝网站，用户钱容易没
HTTPS如何解决风险
HTTPS 在 HTTP 与 TCP 层之间加入了 SSL/TLS 协议，可以很好的解决了上述的风险：
1.信息加密
交互信息无法被窃取，但你的号会因为「自身忘记」账号而没。
2.校验机制
无法篡改通信内容，篡改了就不能正常显示，但百度「竞价排名」依然可以搜到垃圾广告。
3.身份证书
证明淘宝是真的淘宝网，但你的钱还是会因为「剁手」而没。
HTTP是如何解决上面三个风险的
1.混合加密（消息保密）
HTTPS 采用的是对称加密+非对称加密 结合的**「混合加密**」方式：
- 会话开始时使用 非对称加密（公钥算法）：
- 发送方使用接收方的公钥 加密一个对称密钥（私钥）（称为会话密钥）。
- 由于非对称加密解决了密钥交换的安全问题，这个过程确保了会话密钥的安全传输。
- 会话过程中使用 对称加密（私钥算法）：
- 一旦会话密钥安全地传输到接收方，后续的通信就使用这个对称密钥（私钥）进行加密明文数据 和解密。
- 由于对称加密速度快，适合大量数据的加密，这提高了通信的效率
你妈个比，说这么多sb专业名词能不能说点人话
人话：我们发送方和接收方都用私钥加密数据（因为快），然后我们要用接收方的公钥加密发送方的私钥，然后把发送方机密后的私钥发送到接收方用让他的公钥解开，从而用发送方的私钥解开加密数据
一句话：我们都用私钥加密，只是私钥传输给对方使用的时候为了防止泄漏所以我们加密
采用「混合加密」的方式的原因
1.对称加密（私钥）只使用一个密钥，运算速度快，密钥必须保密，无法做到安全的密钥交换。
2.非对称加密（公钥）使用两个密钥：公钥和私钥，公钥可以任意分发而私钥保密，解决了密钥交换问题但速度慢
2.摘要算法（签名算法）+数字签名（防止签名伪造）
我们要判断内容是否被篡改
为了保证传输的内容不被篡改，我们需要对内容计算出一个**「指纹」**，然后同内容一起传输给对方。
对方收到后，先是对内容也计算出一个「指纹」，然后跟发送方发送的「指纹」做一个比较，如果「指纹」相同，说明内容没有被篡改，否则就可以判断出内容被篡改了。
那么，在计算机里会用摘要算法（哈希函数）来计算出内容的哈希值，也就是内容的「指纹」
这个 哈希值是唯一的 ，且无法通过哈希值推导出内容
私钥是由服务器端保管，然后服务器端会向客户端颁发对应的公钥。如果客户端收到的信息，能被公钥解密，就说明该消息是由服务器发送的。
例子：
引入了数字签名算法后，你就无法模仿你爸爸的字迹来请假了，你爸爸手上持有着私钥，你老师持有着公钥。这样只有用你爸爸手上的私钥对请假条进行「签名」，老师通过公钥看能不能解出这个「签名」，如果能解出并且确认内容的完整性，就能证明是由你爸爸发起的请假条，这样老师才允许你请假，否则老师就不认
如何避免【伪造签名】
使用非对称算法（公钥加密）
那为了避免这种情况，计算机里会用非对称加密算法来解决，共有两个密钥：
- 一个是公钥，这个可以公开给所有人的；
- 一个是私钥，这个必须由本人管理，不可泄露。
这两个密钥可以双向加解密的，比如可以用公钥加密内容，然后用私钥解密，也可以用私钥加密内容，公钥解密内容。
流程的不同，意味着目的也不相同
一般私钥和公钥都是一对多的关系
公钥加密，私钥解密（保证安全）
这个目的是为了保证内容传输的安全，因为被公钥加密的内容，其他人是无法解密的，只有持有私钥的人，才能解密出实际的内容。
私钥加密，公钥解密（防止伪造，确认身份）
这个目的是为了保证消息不会被冒充，因为私钥是不泄露的，如果公钥能正常解密出私钥加密的内容，就能证明消息是来源于持有私钥身份的人发送的。
一般我们不会用私钥加密和公钥解密实际传输的内容，因为非对称加密的计算比较耗费性能的，所以非对称加密算法的重点主要在于通过**「私钥加密，公钥解密」** 的方式，来确认消息的身份 ，我们常说的数字签名算法 ，就是用的这种方式，不过对内容的签名本身，而是对内容的哈希值加密
3.数字证书（防止公钥伪造）
前面我们知道：
- 可以通过哈希算法 来保证消息的完整性；
- 可以通过数字签名 来保证消息的来源可靠性（能确认消息是由持有私钥的一方发送的）；
但是这还远远不够，还缺少身份验证的环节，万一公钥是被伪造的呢？
还是请假的例子，虽然你爸爸持有私钥，老师通过是否能用公钥解密来确认这个请假条是不是来源你父亲的。
但是我们还可以自己伪造出一对公私钥啊！
例子：
你找了个铁匠，偷偷把老师桌上和你爸爸管家的公钥，换成了你的公钥，那么下次你在请假的时候，你继续模仿你爸爸的字迹写了个请假条，然后用你的私钥做了【数字签名】。
但是老师并不知道自己的公钥已经被掉包了，所以他还是按照往常一样用公钥解密，由于这个公钥和你的私钥是配对的，老师当然能通过这个被掉包的公钥解密出来，并且确认了内容的完整性，于是老师就会以为是你父亲写的请假条，又允许你请假了。
好家伙，为了一个请假，真的是上智斗勇。
后面的老师和父亲发现了你伪造公私钥的事情后，决定重新商量一对策略来应对你这个臭家伙。
正所谓魔高一尺，道高一尺
既然伪造公私钥那么随意，所以你爸爸把他的公钥注册到警察局，警察局用他们自己的私钥对你父亲的公钥做了个数字签名
然后把你爸爸的**「个人信息 + 公钥 + 数字签名」打包成一个数字证书** ，也就是说这个数字证书包含你爸爸的公钥。
这样，你爸爸如果因为家里确实有事要向老师帮你请假的时候，不仅会用自己的私钥对内容进行签名，还会把数字证书给到老师。
老师拿到了数字证书后，首先会去警察局验证这个数字证书是否合法，因为数字证书里面有警察局的数字签名，警察局的公钥是全世界公认合法的，用自己的公钥解密，如果解密成功，就说明这个数字证书是警察局签发的，老师就会信任数字证书里的公钥是你爸爸的公钥，然后用这个公钥解密你爸爸的签名。
由于通过警察局验证了数字证书是合法的，那么就能证明这个公钥就是你父亲的，于是老师就可以安心的用这个公钥解密签名，如果能解密出来，就证明是你爸爸写的请假条。
正是通过了一个权威机构来证明你爸爸的身份，所以你的伪造公私钥这个小伎俩就没用了。
在计算机里，这个权威的机构就叫做CA（数字证书认证机构） ，将服务器的公钥放到数字证书中（由数字证书认证机构颁发的），中，只要证书是可信的，公钥就是可信的
总结：我们要去权威机构去注册
简短总结
Http存在安全问题
例如
1.明文传输存在的窃听风险
2.传输数据的篡改风险
3.公钥修改的冒充风险
我们用混合加密（公私钥混合使用）来解决明文传输的数据窃听风险
发送方的私钥加密数据，然后发送给接收方
发送方的私钥通过接收方的公钥加密数据，然后把自己的加密的私钥传过去
接收方用自己的私钥解开发送方加密传过来的私钥，用这个发送方私钥来解开加密的数据
通过摘要算法+数字签名解决数据篡改的风险
加密内容唯一Hash值【指纹】发送过去，发送方对内容做运算算出【指纹】，判断指纹是否相同
我们会把我们的数据通过摘要算法做一个运算，得到一个【Hash运算值】，这个值就是一个【指纹】
然后我们会通过【数字签名】，什么是【数字签名】？
就是我们在通过**密钥加密（我们还是用混合加密）**我们的唯一的【Hash运算值】，得到的就是我们的数字签名。
这样子就可以得到我们当前内容的唯一Hash值+加密Hash值防止我们的唯一Hash值被篡改
同时接收方通过同样的哈希算法对内容进行计算，再跟我加密传过来的Hash值进行对比
我们可以知道：
- 可以通过哈希算法 来保证消息的完整性；
- 可以通过数字签名 来保证消息的来源可靠性（能确认消息是由持有私钥的一方发送的）；
通过数字证书防止公钥被篡改和冒充的风险
我们刚刚都是公钥合法的情况，但是公钥被伪造了呢？
例如我们伪造一个和官方网站一模一样的网站？
所以说我们会有个**【合法注册中心】，也就是** CA（数字证书认证机构）
我们一般「个人信息 + 公钥 + 数字签名」打包成一个数字证书，然后去CA验证，只要证书是可信的那么我们的公钥就是可信的
总结： 我们要去权威机构去注册我们的合法公钥信息