目录
1、概念准备
1.1、HTTPS是什么
HTTPS也是一个应用层协议，是在HTTP协议的基础上引入了一个加密层。
HTTP协议内容都是按照文本的方式明文传输的，这就导致在传输过程中出现一些被篡改的情况。
1.2、什么是加密
加密就是把明文（要传输的信息）进行一系列变换，生成密文。
解密就是把密文再进行一系列变换，还原成明文。
在这个加密和解密的过程中，往往需要一个或者多个中间的数据，辅助进行这个过程，这样的数据称为秘钥。
1.3、为什么要进行加密
相信我们在下载软件时都遇到过的一个事情，就是我明明点击的是网易云音乐的下载，怎么变成了qq浏览器？这就是臭名昭著的运营商劫持。
由于我们通过网络传输的任何的数据包都会经过运营商的网络设备（路由器，交换机等），那么运营的网络设备就可以解析出你传输的数据内容，并进行篡改。
点击“下载按钮”，其实就是在给服务器发送了一个HTTP请求，获取到的HTTP响应其实就包含了该APP的下载链接。运营商劫持之后，就发现这个请求是要下载网易云音乐，那么就自动的把用户的响应给篡改成了“qq浏览器”的下载地址了。
所以：因为http的内容是明文传输的，明文数据会经过路由器、wifi热点、通信服务运营商、代理服务器等多个物理节点，如果信息在传输过程中被劫持，传输的内容就完全暴露了。劫持者还可以篡改传输的信息且不被双方察觉，这就是中间人攻击，所以我们才需要对信息进行加密。
1.4、常见的加密方式
对称加密
使用一个秘钥，加密和解密所用的秘钥是相同的。
特点：算法公开、计算量小、加密速度快、加密效率高。
非对称加密
需要两个秘钥来进行加密和解密，一个公钥，另一个是私钥，用公钥加密，只有拥有私钥的人才能解密。
特点：算法强度复杂、安全性依赖于算法与秘钥但是由于其算法复杂，而使得加密解密速度没有对称加密解密的速度快。
1.5、数据摘要&&数据指纹
数字指纹（数字摘要），其基本原理是利用单向散列函数（Hash函数）对信息进行运算，生成一串固定长度的数字摘要。数字指纹并不是一种加密机制，但可以用来判断数据有没有被篡改。
摘要常见算法：有MD5、SHA1、SHA256、SHA512等，算法把无限的映射成有限，因此可能会有碰撞（两个不同的信息，算出的摘要相同，但是概率非常低）。
摘要特征：和加密算法的区别是，摘要严格意义不是加密，因为没有解密，只不过从摘要很难反推原信息，通常用来进行数据对比。
1.6、数字签名
摘要经过加密，就得到数字签名（具体是什么，后面会细讲）。
2、HTTPS的工作过程探究
既然要保证数据安全，就需要进行加密。
网络传输中不再直接传输明文了，而是加密之后的密文。
加密的方式有很多，但是整体可以分为两大类：对称加密和非对称加密。
2.1、方案1 - 只使用对称加密
如果通信双方都各自持有同一个秘钥X，且没有别人知道，这两方的通信安全当然是可以保证的（除非秘钥被破解）。
引入对称加密后，即使数据被截获，由于黑客不知道秘钥是啥，因此就无法进行解密，也就不知道请求的真实内容是啥了。
但事情没有这么简单，服务器同一时刻其实是给很多客户端提供服务的，这么多客户端，每个人用的秘钥都必须是不同的。因此服务器就需要维护每个客户端和每个秘钥之间的关联关系，这是个很麻烦的事情。
比较理想的做法是，客户端和服务器建立连接的时候，双方协商确定这次的密钥是什么，但如果直接传输密钥，黑客就能直接获得，那么就必须对密钥进行加密，这就又回到了之前的问题，所以此时密钥的传输再用对称加密就行不通了。
2.2、方案2 - 只使用非对称加密
鉴于非对称加密的机制，如果服务器先把公钥以明文方式传输给浏览器，之后浏览器向服务器传数据前，先用公钥加密再传，这样看起来似乎是没问题的，因为只有服务器有私钥，那么这里就有两个问题，第一是服务器用私钥加密数据传输给浏览器时，因为公钥是明文传输的，黑客也持有公钥，那么服务器的数据黑客也能进行解密。第二是浏览器向服务器发送的数据，黑客也可能进行掉包，理由同上。
2.3、方案三 - 双方都使用非对称加密
1、服务端拥有公钥S与对应的私钥S’，客户端拥有公钥C与对应的私钥C’；
2、客户和服务端交换公钥；
3、客户端给服务端发消息：先用S对数据加密，再发送，只能由服务器解密，因为只有服务器有私钥S’；
4、服务端给客户端发消息：先用C对数据加密，再发送，只能由客户端解密，因为只有客户端有私钥C’；
这样可以吗？
答案当然也是不行，首先效率太低，然后也会有安全问题，如果这时黑客用自己的公钥和私钥替代了服务器，那客户端的数据还是会被盗取。
2.4、方案四 - 非对称加密 + 对称加密
1、服务端具有⾮对称公钥S和私钥S'；
2、客⼾端发起https请求，获取服务端公钥S；
3、客⼾端在本地⽣成对称密钥C,通过公钥S加密,发送给服务器；
4、由于中间的⽹络设备没有私钥,即使截获了数据,也⽆法还原出内部的原⽂,也就⽆法获取到对称密钥(真的吗？)；
5、服务器通过私钥S'解密,还原出客⼾端发送的对称密钥C，并且使⽤这个对称密钥加密给客⼾端返回的响应数据；
6、后续客⼾端和服务器的通信都只⽤对称加密即可，由于该密钥只有客⼾端和服务器两个主机知道,其他主机/设备不知道密钥即使截获数据也没有意义。
其实这个已经很接近答案，但是依然有一个最大的问题，这也是上面的方案使用非对称加密所共有的问题，那就是客户端如何确保发来的公钥的合法性呢？换句话说就是如果黑客从一开始就把公钥替换了，那客户端又怎么会知道呢？
2.5、引入证书
CA认证
服务端在使用HTTPS前，需要向CA机构申领一份数字证书，数字证书里含有证书申请者信息、公钥信息等。服务器把证书传输给浏览器，浏览器从证书里获取公钥就行了，证书就如身份证，证明服务端公钥的权威性。
那么同时，这里也有一个问题，我们该如何确保证书的合法性？即没有被修改过并且要是这个权威机构发放的。这就要用到证书上的数据签名了。
理解数据签名
签名的形成是基于非对称加密算法的，注意，目前暂时和https没有关系，不要和https中的公钥私钥搞混了。
2.6、方案5 - 非对称加密 + 对称加密 + 证书认证
在客户端和服务器刚一建立连接的时候，服务器给客户端返回一个证书，证书包含了之前服务端的公钥，也包含了网站的身份信息。
客户端进行认证
当客户端获取到这个证书后，会对证书进行校验（防止证书是伪造的）
1、判定证书的有效期是否过期；
2、判定证书的发布机构是否受信任（操作系统中已内置的受信任的证书发布机构）；
3、验证证书是否被篡改：从系统中拿到该证书发布机构的公钥，对签名解密，得到一个hash值（称为数据摘要），设为hash1，然后计算整个证书的hash值，设为hash2，对比hash1和hash2是否相等，如果相等，则说明证书是没有被篡改过的。
中间人有没有可能篡改该证书？
中间人篡改了证书的明文，由于他没有CA机构的密钥，所以无法hash之后用私钥加密形成签名，那么也就没有办法对篡改后的证书形成匹配的签名。如果强行篡改，客户端收到该证书后发现明文和签名解密后的值不一致，则说明证书被篡改，证书不可信，从而终止向服务器传输信息，防止信息泄露给中间人。
中间人整个掉包证书？
因为中间人没有CA秘钥，所以无法制作假的证书吗，那么中间人只能向CA申请真证书，然后进行掉包，这个确实能做到证书的整体掉包，但是别忘了，证书明文中包含了域名等服务端认证信息，如果整体掉包，客户端依旧能够识别出来。
2.7、完整流程
872
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
