基础名词
先说一下基础名词，对称加密、非对称加密
对称加密：加密、解密使用同一副秘钥的加密算法，比如DES
非对称加密：加密、解密使用不同秘钥，加密使用公钥，则解密须使用私钥；反之亦然。比如RSA
https 对称加密
https使用对称加密，流程
- 浏览器请求服务器，服务器返回秘钥key
- 浏览器得到秘钥key
- 浏览器使用秘钥key加密html，传输给服务器
- 服务器使用秘钥key解密
存在的问题
会出现秘钥泄露问题：如果有不怀好意的人，在步骤1和步骤2之间，拦截了秘钥key，那整个会话的内容对他来说都是明文了
https非对称加密
https使用非对称加密，流程
- 浏览器请求服务器，服务器返回公钥k1（服务器公钥k1，私钥k2）
- 浏览器得到秘钥k1
- 浏览器使用秘钥k1加密html，传输给服务器
- 服务器使用秘钥k2解密
没有直接解决秘钥泄露问题，但是解决了秘钥泄露所引发的问题。即使在步骤1和步骤2之间被人拦截了，他只有公钥k1，对于加密后的html密文，无法进行解密，保证了数据传输的安全性。
存在的问题
非对称加密的方式，又引出了新的问题–非对称加密效率比较低，特别是在对大文本的加密上，非对称加密的效率更低。 显然我们是不能忍受浏览器发请求出去了，很久才响应的
https对称+非对称加密
https使用对称加密+非对称加密，流程
-
浏览器请求服务器，服务器返回公钥k1（服务器公钥k1，私钥k2）
-
浏览器得到秘钥k1
-
浏览器生成对称加密的秘钥k3
-
浏览器用k1加密k3，得到密文x，把x传输给服务器
-
服务器用k2解析x，得到对称加密的秘钥k3
- 浏览器使用秘钥k3加密html，传输给服务器
- 服务器使用秘钥k3解密
https对称+非对称 解决了秘钥泄露问题、非对称加密效率低下问题，实际上现在很多网站的https就是使用的这一版本。
存在的问题
看似是无懈可击，然而，还是不完美的–会出现公钥被篡改的问题
假如，在步骤1和步骤2之间，被不怀好意的人拦截了，他获取到秘钥k1，保存下来，并生成一对新的秘钥(公钥k11，私钥k22)，把k11返回给浏览器 浏览器收到秘钥k11，使用k11加密html，得到密文x，把x传输给服务器， 在传输的过程中，不怀好意的人再次拦截请求，得到x，因为x是使用k11加密的，他有对应的私钥k22，所以，他是能解析得到明文的 再得到明文后，他把明文用秘钥k1加密，传输给服务器 服务器是正常解析的，浏览器和服务器是无法感知密文已经被泄露
这就是中间人攻击，根本原因是浏览器无法确定接收到的公钥，是否是被篡改的。
https数字证书，闪亮登场
数字证书原理
证书是如何防止被篡改的？证书如何证明本身的真实性呢？ 先说下数字证书的构成：CA机构用私钥加密 消息摘要 ，其中消息摘要=hash(公钥k1+网站信息) 数字证书的验证：
在https3.0步骤2的基础上，额外返回证书信息和CA的公钥 使用CA公钥解密，得到一串hash值，它是 hash(公钥k1+网站信息)得来的 再使用https3.0步骤2返回的秘钥k1和自己的网站信息，进行hash 比较hash得到的内容与使用CA公钥解密后的内容，是否一致，若不一样，则被篡改。
相关疑问
中间人能篡改证书吗？
无法做到，因为CA私钥只有CA机构拥有，中间人无CA私钥，所以无法对篡改内容进行签名
中间人能掉包证书吗？
无法做到，假如有网站B，想搞垮网站A，拦截了网站A的证书，把B自己的证书返回给A，只有网站A使用的就是B的公钥了。这样是行不通的，因为证书里，包含了网站信息，域名等，一对比就知道是否是掉包的了
如何保证CA公钥可信性？
同理，CA机构的公钥，也是可以使用数字证书的套路来证明的。
那么最终，最底层是如何保证可信任性的呢？
操作系统、浏览器会预装它们信任的根证书。从根证书开始，经过层层信任，形成信任链，CA证书获得信任链的信任，那就能证明身份。