【网络】HTTPS协议原理
目录
“加密”相关概念
为什么要加密
常见加密方式
对称加密
非对称加密
HTTPS工作过程探究
方案1-只使用对称加密
方案2-只使用非对称加密
方案3-客户端和服务端双方都使用非对称加密
方案4-非对称加密 + 对称加密
上述方案问题分析
方案5-证书认证 + 非对称加密+对称加密
什么是证书
什么是数据摘要
什么是数字签名
证书认证 + 非对称加密+对称加密
常见问题
中间人修改证书怎么办。
中间人将证书整个换掉。
摘要内容在网络传输时为什么要加密形成签名
数字签名为什么不直接加密，而是要先hash形成摘要呢。
总结
http协议内容是按照文本的方式明文传输的，传输的过程中存在被恶意分子获取，修改的风险。这种传输方式，称为明文传输。
https也是用用层的协议，在http协议的基础上引入了加密层，这种传输方式称为密文传输。
“加密”相关概念
加密的本质就是把 要传输的信息 进行一系列的变换，生成密文。解密的过程就是将密文再次经过变换，恢复成 真正要传输的信息。在加密解密的过程中，需要一个或者多个中间数据，辅助加密解密，这样的中间数据叫做 密钥。
例：如下图所示，张三想要向如花表白，但是在信息传输的过程中，害怕被别人看到或者恶意修改，就用key对要传输的数据进行了加密，并且在消息发送前把key也告诉了如花。信息发送后，即便数据在传输的过程中被别人看见，看到了并不是信息的原貌。只有拥有key的如花通过key对数据进行解密，才能等看到张三传输的原始信息。
为什么要加密
在互联网上，明文传输是比较危险的事情。不法分子可以通过一些技术手段来窃取你的隐私信息，甚至篡改内容。如果你在登录支付软件的过程中被“坏人”获取到了账户余额，甚至获取到用户的支付密码，后果不堪设想。下面举个例子：
案例场景：小明 想要下载一个 A 软件，点击下载按钮后，本质上是在给服务器发送一个http请求，服务器发送响应给客户端后，http响应中就包含了 A软件 的下载链接， 因为 在网络传输的任何数据包都要通过运营商的网络设备，这个时候运营商可以劫持这个响应，对数据内容进行篡改，如将A软件的下载链接 修改成 “B软件的下载链接” 。
http的内容是明文传输的，被中间人劫持后，传输的内容完全暴露。中间人可以修改传输的信息，并且不被客户端和服务端察觉。因此我们需要对信息进行加密。
常见加密方式
对称加密
对称加密采用的是单个密钥的加密方法，使用这一个密钥完成对信息进行加密和解密。
特点：算法公开、计算量小、加密速度快、加密效率高。
非对称加密
非对称加密，需要两个密钥进行加密和解密，公钥（对明文加密），私钥（对明文解密），两个密钥反过来使用也是可以的。
特点：算法强度复杂、加密解密速度慢。
HTTPS工作过程探究
方案1-只使用对称加密
问题：服务器需要维护每个客户端和每个密钥之间的关联关系，比较理想的做法就是在客户端和服务器建立连接的时候，双方协商确定好这次密钥是什么。但是在协商密钥的过程中，如果将密钥明文传输，那么中间人（黑客等）也可以获得密钥，这样一来后序的加密传输就形同虚设，毫无意义！
方案2-只使用非对称加密
分析：服务器端有私钥和公钥，服务器先将公钥以明文的方式传递给客户端（中间人也可以拿），此后客户端向服务器传输数据前都用公钥加密，从客户端到服务器的信道好像是安全的（实际上仍不安全，后面讨论），因为只有服务端有解密的私钥。 但是，从服务端到客户端这条路无法保证安全，如果服务器用私钥加密，中间人手中也有公钥，也可以对信息进行解密。
问题总结：公钥传输后，从客户端到服务端的通信信道似乎保证了安全（实际不安全）。但是，从服务端到客户端仍然是不安全的。
方案3-客户端和服务端双方都使用非对称加密
如下图所示：服务端和客户端各有一对密钥。
以上图为例进行描述，服务端的密钥为公钥S和私钥S',客户端的密钥为公钥C和私钥C'。
1.客户端和服务端交换公钥。（明文传输）
2.客户端向服务端发送信息时用公钥S对数据加密，由于只有服务端有解密的私钥S'，所以只能由服务器进行解密（貌似安全，实际不安全）。
3.同理，服务端向客户端发送信息时用公钥C对数据加密，只有服务端可以用私钥C'进行解密，这个过程似乎也是安全的（实际不安全）。
4.综上所述，通过双方都使用非对称加密的方式，似乎保证了信息传输的安全（依旧有安全问题）。
问题：双方使用非对称加密，效率太低。虽然表面上看保障了信息传输的安全，但是实际上依旧有安全问题！
方案4-非对称加密 + 对称加密
1.服务端有一对密钥，公钥S和私钥S' ，客户端有只有一个公钥C.
2.首先客户端发起https请求，获取到服务端的公钥S。
3.客户端将公钥C通过服务端公钥S'加密后，发送给服务端。
4.由于解密S的私钥只有服务端有S',公钥C传输的过程似乎是安全的（实际上仍然不安全）。
5.服务器通过私钥S'解密，等到客户端的公钥C。并通过C加密向客户端返回响应数据。
6.从整体流程上看，解决了方案3效率低的问题，并且似乎也是安全的（实际上不安全）。
上述方案问题分析
在方案2/3/4中都存在同一问题，假设中间人在最开始的握手协商阶段，就进行攻击，依旧会存在安全问题。
如上图所示：以方案4为例进行演示
1.服务端有公钥S和私钥S',客户端有公钥C,中间人有公钥M和私钥M'。
2.客户端向服务器发送请求，服务器明文传送公钥S给客户端。
3.中间人可以劫持报文，并获取公钥S。与此同时，如果中间人把劫持报文中的公钥S换成自己的公钥M,并伪造报文发送给客户端。
4.客户端并不知道自己收到的公钥已经被掉包，按照流程解密获取到公钥M。将客户端公钥C通过M加密发送给服务端。
5.中间人劫持报文后，通过M'进行解密，获取到公钥C。接着再用开头截取到的公钥S加密后，将报文推送给服务器。
6.服务器收到报文后，通过密钥S'解密获取到客户端公钥C。此后服务端和客户端通过公钥C进行对称加密。
7.当CS双方都用公钥C对称加密的时候，中间人也有密钥C,也就说中间人对数据可以随时截取、窃听甚至修改。
8.综上所述,2/3/4方案也都存在安全问题。
方案5-证书认证 + 非对称加密+对称加密
什么是证书
服务端在使用HTTPS前，需要向CA机构申领一份数字证书，数字证书中包含证书申请者信息，公钥信息等。服务器把证书传输给浏览器，浏览器从证书里获取公钥。证书可以证明服务端公钥的权威性，并且私钥只有服务端有。
什么是数据摘要
数据摘要的基本原理就是利用单向散列函数（Hash函数）对信息进行运算，生成一串固定长度的数字摘要。数字摘要并不是一种加密机制，它主要用来判断数据有没有被篡改过。
什么是数字签名
数字签名是基于非对称加密算法的。简单的理解，数据摘要用CA的私钥加密后，就是数字签名。
如上图所示是有效证书的生成过程：
1.CA机构有非对称加密的公钥A和A'。
2.CA机构对服务器申请的证书明文数据进行hash，形成数据摘要。
3.然后对数据摘要用CA私钥A'机密，就得到了数字签名S。
4.服务端申请的证书明文+数字签名共同组成了数字证书。
证书认证 + 非对称加密+对称加密
1.客户端和服务器刚刚建立连接的时候，服务器给客户端返回一个证书，证书中包含了之前服务端的公钥。
2.客户端收到证书后，对证书的合法性进行校验。如果不合法进行提示，合法随机生成一个密钥R。
3.使用证书种包含的公钥X对R进行加密，发送给服务端。
4.服务端用私钥X'加密获取到公钥R,此后服务端和客户端就使用对称加密的方案进行通信。
常见问题
中间人修改证书怎么办。
中间⼈篡改了证书的明⽂也没关系，由于中间人没有CA机构的私钥，所以⽆法hash之后⽤私钥加密形成签名，那么也就没法办法对篡改后的证书形成匹配的签名。 如果强⾏篡改，客⼾端收到该证书后会发现明⽂和签名解密后的值不⼀致，则说明证书已被篡改，证书不可信，从⽽终⽌向服务器传输信息，防⽌信息泄露给中间⼈。
中间人将证书整个换掉。
因为中间⼈没有CA私钥，所以⽆法制作假的证书。所以中间⼈想掉包只能向CA申请真证书，然后⽤⾃⼰申请的证书进⾏掉包。这个确实能做到证书的整体掉包，但是，证书明⽂中包含了域名等服务端认证信息，如果整体掉包，客⼾端依旧能够识别出来。
中间⼈没有CA私钥，所以对任何证书都⽆法进⾏合法修改。
摘要内容在网络传输时为什么要加密形成签名
对证书明⽂hash形成散列摘要，然后CA使⽤⾃⼰的私钥加密形成签名，将数据和加密的签名合起来形成CA证书，颁发给服务端，当客⼾端请求的时候，就发送给客⼾端，中间⼈截获了，因为没有CA私钥，就⽆法更改或者整体掉包，就能安全的证明，证书的合法性。最后，客⼾端通过操作系统⾥已经存的了的证书发布机构的公钥进⾏解密,还原出原始的哈希值,再进⾏校验。
数字签名为什么不直接加密，而是要先hash形成摘要呢。
缩小签名的密文长度，加快数字签名验证签名的运算速度。
总结
证书+非对称加密+对称加密，一切的关键都是围绕着对称加密的密钥，其他的机制都是辅助这个密钥工作的。