一、预备知识
1.HTTPS定义
也是一个应用层协议，相当于在HTTP协议的基础上引入了一个加密层 。HTTP协议内容都是按照文本的方式明文传输 的，这就导致在传输过程中出现一些被篡改的情况。
其实相当于HTTP再做一次封装，数据要先经过诸如SSL这样权威的加密软件加密。
2.加密
加密就是把明文 （要传输的信息）进行一系列变换，生成密文 。解密就是把密文再进行一系列变换，还原成明文。在这个加密和解密的过程中，往往需要一个或者多个中间的数据，辅助进行这个过程，这样的数据称为密钥。比如7作为明文异或5，5就是密钥，得到的结果就是密文。
3.明文的危险性
热点、WiFi、运营商路由器本质就是中间人 ，发送的请求如果是明文 的，就会被这些中间人获取到信息，是不安全的。
4.常见加密方式
(1)对称加密
加密解密用同一个密钥 ，加密速度快。
(2)非对称加密
两把秘钥分别负责加密和解密，其中一把秘钥公开（即公钥） 一把不公开（即私钥）就叫非对称加密。可分为两种情况:用公钥加密，只有拥有私钥的人才能解密;用私钥加密，任何拥有公钥的人都可以解密。该方法加密速度慢。
(5)指纹
用hash算法把数据变成固定长度的冲突概率低的字符串，这个字符串叫做数据指纹，只要数据被篡改了，hash算法得出来的指纹就会对不上原来的指纹。
HTTPS工作过程
为了保障数据安全和加密效率，下面给出几种方案做对比，从而理解潜在的威胁。
方案一
双方遵守对称加密
客户端和服务器一开始就约好秘钥，使用对称加密。
问题
但是秘钥要通过网络传输，对秘钥再加密是不可能的（因为二次加密必须知道初始秘钥，可此时初始密钥还没定下来），仍可能被抓到。
方案二
服务器采用非对称加密
服务器把公钥发给客户端，私钥自己留着，客户端发给服务器的时候用公钥加密，然后让服务器来解密，这时候即便黑客拿到了公钥，也无法解密
问题
服务器用私钥加密，意味着可以被公钥解密，而公钥定义就是任何人都可拿到手，黑客也不例外。
方案三
客户端和服务器都使用非对称加密
- 服务端拥有公钥S与对应的私钥S'，客⼾端拥有公钥C与对应的私钥C'
- 客⼾和服务端交换公钥
- 客⼾端给服务端发信息：先⽤S对数据加密，再发送，只能由服务器解密，因为只有服务器有私钥 S'
- 服务端给客⼾端发信息：先⽤C对数据加密，在发送，只能由客⼾端解密，因为只有客⼾端有私钥 C
问题
1.效率低 ：非对称加解密比对称加解密慢上千倍，双方都做非对称加密会导致两边都很慢。
2.新的安全问题 ：虽规避前两种方案秘钥被截取的可能，但双方都用非对称，服务器怎么知道客户端公钥真的是客户端的呢？中间人完全可以分别伪造一套自己的公私钥，同时让两端认为自己是沟通的那一端，这就是中间人攻击（MITM）。
方案四
服务器使用非对称加密，客户端使用对称加密
- 服务端具有非对称公钥S和私钥S'
- 客户端发起https请求，获取服务端公钥S
- 客户端在本地生成对称密钥C，通过公钥S加密，发送给服务器。
- 由于中间的网络设备没有私钥，即使截获了数据，也无法还原出内部的原文，也就无法获取到对称密钥。
- 服务器通过私钥S'解密，还原出客户端发送的对称密钥C。并且使用这个对称密钥加密给客户端返回的响应数据。
- 后续客户端和服务器的通信都只用对称加密即可。由于该密钥只有客户端和服务器两个主机知道，其他主机/设备不知道密钥即使截获数据也没有意义。
问题
- 服务器具有非对称加密算法的公钥S，私钥S'
- 中间人具有非对称加密算法的公钥M，私钥M'
- 客户端向服务器发起请求，服务器明文传送公钥S给客户端
- 中间人劫持数据报文，提取公钥S并保存好，然后将被劫持报文中的公钥S替换成为自己的公钥M，并将伪造报文发给客户端
- 客户端收到报文，提取公钥M(自己当然不知道公钥被更换过了)，自己形成对称秘钥X，用公钥M加密X，形成报文发送给服务器
- 中间人劫持后，直接用自己的私钥M'进行解密，得到通信秘钥X，再用曾经保存的服务端公钥S加密后，将报文推送给服务器
- 服务器拿到报文，用自己的私钥S'解密，得到通信秘钥X
- 双方开始采用X进行对称加密，进行通信。但是一切都在中间人的掌握中，劫持数据，进行窃听甚至修改，都是可以的
问题总结
上述方案遇到的问题主要是下面两点。
- 双方传输的秘钥可能被截获。
- 攻击者可以充当中间人同时骗过双方。
证书与安全可行的方案
平时点开的一些网站会显示"该网站的安全证书已经过期"从而提示我们该网站是不安全的，而这个证书指的正是由CA机构颁发的CA认证。下面先介绍CA证书的申请流程、证书的产生过程，然后再提出一套方案可解决上述的安全问题的方案。
申请证书
申请者（也就是服务端）要提前准备好基本信息以及一对公钥和私钥，公钥将提交给CA认证机构，私钥自己保留。
证书的形成
证书包括签名和明文信息，明文信息包含了用户上传的资料，其中公钥就是用户上传的公钥。
CA机构有自己的公钥和私钥，其中公钥是浏览器内置好的，而私钥只有CA机构知道。
对用户数据运算得出数据指纹（也就是数据摘要），CA机构再用自己的私钥加密，就是签名。
签名和原始数据打包得到证书，发放的证书会被安装在服务器里面。
客户端与服务器的安全传输
当客户端发起请求时，服务端先把证书发给客户端。
客户端对证书中的明文信息做哈希运算得到数据指纹A，用浏览器内置的公钥解密签名得到数据指纹B，若A=B则证书合法，同时说明证书明文信息的公钥合法，随后客户端生成一把对称秘钥，用证书里面的公钥（也就是服务器一开始给的公钥）加密，发送给服务器，只有服务器拥有私钥，保障了这个秘钥仅双方知晓。
上述过程中，证书如何解决中间人问题？
用户只要得到证书**，就会用浏览器内置的公钥去解密** ，如果能公钥解密，证书必然是CA机构颁发的，因为匹配的私钥仅CA机构持有。正因如此，只有CA机构才有证书颁发的权利，中间人不具有生成新的证书的资格，这也是CA机构采用非对称加密的原因。
如果黑客伪造一份证书，因为没有私钥，用户用唯一公钥解密必然失败。
如果黑客修改了服务端的明文数据，因无法修改签名，客户端对明文数据运算得到的指纹和签名解密得到的指纹必然不同，说明数据是不安全的。
这样一来，用户拿到的公钥一定是没被篡改过的，从而保障安全性。
如果黑客也申请一份证书，将双方证书替换掉呢？
证书里有域名，客户端即将访问的域名肯定是申请过安全证书的服务器域名，黑客再次申请必然得到不同的域名，当浏览器发现客户一开始登上去的域名和验证证书时域名不同，说明不安全。
数据摘要比数据本身短很多，对摘要做加密运算肯定更快，而且摘要是定长的，加密速度稳定。