为什么需要加密，因为HTTP是明文传输，不安全。
对称加密
浏览器和服务器使用同一个密钥进行加密和解密。没有该密钥不能获取到传输的内容。看似是正确的没有错误。但是怎么保证该密钥能安全的让双方知道呢，服务器生成密钥发送给浏览器的过程中是有可能被截获该密钥的。有的人可能会想，如果浏览器一开始就有该密码就可以了，但是你想想让浏览器去保存所有HTTPS网站的密钥?这不现实吧。
非对称加密
浏览器和服务器同时拥有公钥和私钥，公钥用来加密，私钥用来解密。公钥是可以在网络中传输的。
过程是这样的：
浏览器拥有公钥A和私钥A',服务器拥有公钥B和私钥B'
浏览器向服务器发送请求时，服务器明文传输公钥B给浏览器。
浏览器用公钥B进行加密发送给服务器，服务器收到后用私钥B'进行解密，因为只有服务器有该密钥B',所以是安全的。
同理，服务器向浏览器传输的道路上用浏览器的公钥加密，浏览器收到后用浏览器的私钥进行解密。
这样两条路的安全都可以保证是安全的了(其实是不安全的)
先抛开非对称加密的不安全性不说来谈谈为什么HTTPS不是用的这种加密？
很简单，这种方式太过于繁琐和耗时，效率不高。而对称加密算法则比这快的多，那么我们可不可以使用两者的结合呢？
非对称加密+对称加密
HTTPS真正采用的是这种加密方式。
大致的过程就是使用非对称加密的方式传送密钥，那么该密钥就是双方就安全的得到了，也就是说使用非对称加密来使得双方安全拿到密钥。这个过程可以自己想象一下。
这样是不是很完美的解决了安全问题和效率问题？答案是否，因为这样同样存在安全问题，也就是上面提到的非对称加密通用存在安全问题
中间人攻击
在非对称加密的过程中，服务器向浏览器发送公钥的过程是明文的，这个通道上的公钥是可以被中间人获取到的，假设这个公钥被获取到了，然后中间人自己伪造一个公钥和私钥。将自己伪造的公钥传给浏览器，而浏览器用伪造的公钥加密后传回服务器的途中被中间人获取，然后用伪造的私钥解密，这样数据就被获取到了，而中间人同样有服务器的公钥，同时也可以和服务器进行交互。
上面暴露的问题是浏览器根本不知道公钥是不是服务器的，那么有没有什么办法来证明公钥是不是服务器的呢？答案是有
数字证书
使用HTTPS的网站需要向CA机构申请一份数字证书来证明来保证该公钥是归谁所持有的。所以服务器和浏览器通信时可以下发给浏览器数字证书。浏览器可以从证书中获取到公钥。
但是同样存在问题，因为证书同样会被中间人获取到，同样可以伪造。真令人头大，怎么样都不行了？那是不是有可以防止伪造数字证书的方法呢？答案是有的。
数字签名
把证书内容生成一份签名，对比内容和签名是否一致来判断是否被篡改了消息。大概步骤：
CA机构拥有公钥和私钥
CA机构对证书明文哈希
对哈希后的值用私钥哈希得到数字签名。
这样将明文+数字签名组成一份数字证书颁发给网站。
那么怎么验证信息有没有被篡改呢
验证
浏览器拿到证书后，得到了明文信息和数字签名信息。
浏览器使用CA的公钥匙解密拿到哈希的信息。
使用哈希算法对明文进行加密与解密得到的哈希信息进行比对，如果不等则说明被篡改了。
那么中间人是否能够篡改签名呢？答案是想屁吃。他不是CA机构信任的，所以没有服务器的私钥)
来源：https://www.cnblogs.com/lgxblog/p/11692932.html
