HTTPS加密及工作过程

一，HTTP为什么要加密

HTTPS是在HTTP的基础上，引入了一个加密层（SSL）

HTTP是明文传输的（不安全）

因为HTTP是明文传输的，于是在以前出现了一种现象：运营商劫持

比如你在网上下载一款软件，明明要下载的是一个音乐播放器，结果下载下来的是一个QQ，如图：

出现这种原因的过程：

对此，即使运营商不劫持，如果黑客盯上了，也是可能对你的信息安全造成一些影响

为了解决安全问题，最核心的要点，就是"加密"了。

以此，我们就引入了密码学，密码学中有几个重要概念：

明文：要传输的真实的数据，就是要表达是实际意思

密文：针对明文加密之后，得到的结果，往往是不直观的，不易理解的

加密和解密的过程中，涉及到一个关键的道具，称为密钥

根据密钥，有两种加密方式。分为对称加密和非对称加密：

对称加密：加密和解密，使用的是同一个密钥

非对称加密：加密和解密，使用的是两个密钥。这两个密钥，k1，k2，是成对的，可以使用k1来加密，此时就是k2解密，也可以使用k2加密，k1解密

两个密钥，就可以一个公开出去，称为"公钥"，另一个自己保存好，称为"私钥"

二，HTTPS工作过程

只要针对HTTPS的数据进行解密了，就能够得到HTTP格式的数据

对于上述的运营商劫持，无论是修改referer还是修改返回的链接，其实本质上都是明文传输惹的祸

于是需要引入加密，对上述传输的数据进行保护，主要就是要针对header和body进行加密

1）引入对称加密：

引⼊对称加密之后,即使数据被截获,由于⿊客不知道密钥是啥,因此就⽆法进⾏解密,也就不知道请求的真实内容是啥了.但事情没这么简单.服务器同⼀时刻其实是给很多客⼾端提供服务的.这么多客⼾端,每个⼈⽤的秘钥都必须是不同的(如果是相同那密钥就太容易扩散了,⿊客就也能拿到了).因此服务器就需要维护每个客⼾端和每个密钥之间的关联关系,这也是个很⿇烦的事情~

⽐较理想的做法,就是能在客⼾端和服务器建⽴连接的时候,双⽅协商确定这次的密钥是啥~

但是如果直接把密钥明⽂传输,那么⿊客也就能获得密钥了~~此时后续的加密操作就形同虚设了.

**因此密钥的传输也必须加密传输!**

但是要想对密钥进⾏对称加密,就仍然需要先协商确定⼀个"密钥的密钥".这就成了"先有鸡还是先有蛋"的问题了.此时密钥的传输再⽤对称加密就⾏不通了. 就需要引⼊⾮对称加密.

2)引入非对称加密

⾮对称加密要⽤到两个密钥,⼀个叫做"公钥",⼀个叫做"私钥". 公钥和私钥是配对的.最⼤的缺点就是运算速度⾮常慢，⽐对称加密要慢很多.

客⼾端在本地⽣成对称密钥,通过公钥加密,发送给服务器.

由于中间的⽹络设备没有私钥,即使截获了数据,也⽆法还原出内部的原⽂,也就⽆法获取到对称密钥

服务器通过私钥解密,还原出客⼾端发送的对称密钥.并且使⽤这个对称密钥加密给客⼾端返回的响应数据.

后续客⼾端和服务器的通信都只⽤对称加密即可.由于该密钥只有客⼾端和服务器两个主机知道,其他主机/设备不知道密钥即使截获数据也没有意义.

上述操作下，仍然存在重大的安全漏洞，黑客仍然有办法获取到对称密钥key的

3）中间人攻击

服务器具有⾮对称加密算法的公钥S，私钥S'
中间⼈具有⾮对称加密算法的公钥M，私钥M'
客⼾端向服务器发起请求，服务器明⽂传送公钥S给客⼾端
中间⼈劫持数据报⽂，提取公钥S并保存好，然后将被劫持报⽂中的公钥S替换成为⾃⼰的公钥M，并将伪造报⽂发给客⼾端
客⼾端收到报⽂，提取公钥M(⾃⼰当然不知道公钥被更换过了)，⾃⼰形成对称秘钥X，⽤公钥M加密X，形成报⽂发送给服务器
中间⼈劫持后，直接⽤⾃⼰的私钥M'进⾏解密，得到通信秘钥X，再⽤曾经保存的服务端公钥S加密后，将报⽂推送给服务器
服务器拿到报⽂，⽤⾃⼰的私钥S'解密，得到通信秘钥X
双⽅开始采⽤X进⾏对称加密，进⾏通信。但是⼀切都在中间⼈的掌握中，劫持数据，进⾏窃听甚⾄修改，都是可以的

针对上述问题，如何解决？

最关键的一点，客户端拿到公钥的时候，要能有办法验证，这个公钥是否是真的，而不是黑客伪造的。

4）引入证书

服务端在使⽤HTTPS前，需要向CA机构申领⼀份数字证书，数字证书⾥含有证书申请者信息、公钥信息等。服务器把证书传输给浏览器，浏览器从证书⾥获取公钥就⾏了，证书就如⾝份证，证明服务端公钥的权威性

证书中会包含一系列信息：服务器的主域名，公钥，证书有效期，签名等

需要注意的是：申请证书的时候，需要在特定平台⽣成查，会同时⽣成⼀对⼉密钥对⼉，即公钥和私钥。这对密钥对⼉就是⽤来在⽹络通信中进⾏明⽂加密以及数字签名的。

数据签名：

签名的形成是基于⾮对称加密算法的，注意，⽬前暂时和https没有关系，不要和https中的公钥私钥搞混了

当服务端申请CA证书的时候，CA机构会对该服务端进⾏审核，并专⻔为该⽹站形成数字签名，过程如下：

CA机构拥有⾮对称加密的私钥A和公钥A'
CA机构对服务端申请的证书明⽂数据进⾏hash，形成数据摘要
然后对数据摘要⽤CA私钥A'加密，得到数字签名S 服务端申请的证书明⽂和数字签名S共同组成了数字证书，这样⼀份数字证书就可以颁发给服务端了

5）通过证书解决中间人问题

在客⼾端和服务器刚⼀建⽴连接的时候,服务器给客⼾端返回⼀个证书. 这个证书包含了刚才的公钥,也包含了⽹站的⾝份信息.

当客⼾端获取到这个证书之后,会对证书进⾏校验(防⽌证书是伪造的)

. • 判定证书的有效期是否过期

• 判定证书的发布机构是否受信任(操作系统中已内置的受信任的证书发布机构)

. • 验证证书是否被篡改:从系统中拿到该证书发布机构的公钥,对签名解密,得到⼀个hash值(称为数据摘要),设为hash1.然后计算整个证书的hash值,设为hash2.对⽐hash1和hash2是否相等.如果相等,则说明证书是没有被篡改过的.

中间⼈有没有可能篡改该证书？

• 中间⼈篡改了证书的明⽂

• 由于他没有CA机构的私钥，所以⽆法hash之后⽤私钥加密形成签名，那么也就没法办法对篡改后的证书形成匹配的签名

• 如果强⾏篡改，客⼾端收到该证书后会发现明⽂和签名解密后的值不⼀致，则说明证书已被篡改，证书不可信，从⽽终⽌向服务器传输信息，防⽌信息泄露给中间⼈

中间⼈整个掉包证书？

• 因为中间⼈没有CA私钥，所以⽆法制作假的证书

• 所以中间⼈只能向CA申请真证书，然后⽤⾃⼰申请的证书进⾏掉包

• 这个确实能做到证书的整体掉包，但是别忘记，证书明⽂中包含了域名等服务端认证信息，如果整体掉包，客⼾端依旧能够识别出来。

• 永远记住：中间⼈没有CA私钥，所以对任何证书都⽆法进⾏合法修改，包括⾃⼰的