HTTPS背景知识

HTTPS是什么？

加密解密

为什么要加密

常见的加密方式

对称加密

非对称加密

数据摘要&&数据指纹

数字签名

HTTPS工作过程探究

方案1：只使用对称加密

方案2：只使用非对称加密

方案3：双方都使用非对称加密

编辑

方案4：非对称加密+对称加密

中间人攻击

证书的引入

数据签名

查看CA机构

方案5：非对称加密+对称加密+证书认证

HTTPS完整流程

HTTPS背景知识

HTTPS是什么？

HTTPS也是⼀个应用层协议。是在HTTP协议的基础上引入了⼀个加密层。

HTTP协议内容都是按照文本的方式明文传输的。这就会导致在传输过程中出现一些被篡改的情况。早期很多公司刚起步的时候，使用的应用层协议都是HTTP，而HTTP无论是用GET方法还是POST方法传参，都是没有经过任何加密的，因此早期很多的信息都是可以通过抓包工具抓到的。

为了解决这个问题，于是出现了HTTPS协议，HTTPS实际就是在应用层和传输层协议之间加了一层加密层（SSL&TLS），这层加密层本身也是属于应用层的，它会对用户的个人信息进行各种程度的加密。HTTPS在交付数据时先把数据交给加密层，由加密层对数据加密后再交给传输层。

当然，通信双方使用的应用层协议必须是一样的，因此对端的应用层也必须使用HTTPS，当对端的传输层收到数据后，会先将数据交给加密层，由加密层对数据进行解密后再将数据交给应用层。

此时数据只有在用户层（应用层）是没有被加密的，而在应用层往下以及网络当中都是加密的，这就叫做HTTPS。

加密解密

什么是加密和解密？

加密就是把明文( 要传输的信息)进行一系列变换，生成密文。
解密就是把密文再进行一系列变换，还原成明文。

在这个过程中，往往需要一个或者多个中间的数据，辅助进行这个过程，这样的数据被称为密钥（正确发音是yue四声，但是大家都读作yao四声）。

例如在电影《火烧圆明园》中，有人要谋反干掉慈禧太后。恭亲王奕䜣给慈禧递的折子。折子内容只是扯⼀扯家常，但是套上⼀张挖了洞的纸就能看到真实要表达的意思。慈禧通过一张挖了洞的纸解密出了折子要传递的信息。

在这个例子中：

明⽂:"当心肃顺，端华，戴恒
密文：奏折全文
密钥：挖了洞的纸

因此在古代其实人们早已能够运用加密和解密，而加密解密到如今已经发展成为一门独立的学科：密码学。而密码学的奠基人，也正是计算机科学的祖师爷之一，艾伦·麦席森·图灵。

计算机领域中的最高荣誉就是以他名字命名的“图灵奖”。

为什么要加密

早期接触互联网的人应该都或多或少地了解臭名昭著的“运营商劫持”事件。比如当我们要想下载一个软件的时候。未被劫持的效果，点击下载按钮，就会弹出你想要下载的软件的下载链接。

但是由于你发出的HTTP请求是明文传输的，并且一定要经过运营商的路由器，那么路由器收到你的HTTP请求之后经过分析得知你想要下载某一个软件，此时它便可以响应一个其它软件的下载链接给你，如果这时候你稍微一不注意就会下载到某些流氓软件。

劫持的具体过程如下：

中间人攻击

因为http的内容是明文传输的，明⽂数据会经过路由器、wifi热点、通信服务运营商、代理服务
器等多个物理节点，如果信息在传输过程中被劫持，传输的内容就完全暴露了。劫持者还可以篡改传输的信息且不被双方察觉，这就是中间人攻击，所以我们才需要对信息进行加密。

不止运营商可以劫持，其他的黑客也可以用类似的⼿段进行劫持，来窃取用户隐私信息，或者篡改内容.试想⼀下，如果黑客在用户登陆支付宝的时候获取到用户账户余额，甚⾄获取到用户的支付密码.....在互联网上，明文传输是非常较危险的事情!!!

HTTPS就是在HTTP的基础上进⾏了加密，进⼀步的来保证用户的信息安全。

常见的加密方式

对称加密

采⽤单钥密码系统的加密⽅法，同⼀个密钥可以同时⽤作信息的加密和解密，这种加密⽅法称为对称加密，也称为单密钥加密，特征：加密和解密所用的密钥是相同的
常见的对称加密算法：DES、3DES、AES、TDEA、Blowfish、RC2等等
特点：算法公开，计算量小，加密速度快，加密效率高

对称加密的原理

如果你还想知道更多的非对称加密算法，可以了解一下RSA，这是一个基于因式分解的非对称加密算法。下面我们简单理解一下对称加密，对称加密最典型的例子就是异或运算。

我们用A异或B得到一个中间值C，此时如果我们采用C异或B就能重新得到A。在这个过程中，A就相当于通信双方想要交互的数据，B就相当于对称加密当中的密钥，C就相当于被密钥加密后的数据，异或运算实际就是一个简单的对称加密算法。当然按位异或只是一个简单的对称加密。HTTPS使用的对称加密算法要复杂许多。

非对称加密

需要两个密钥来进行加密解密，这两个密钥是公开密钥和私有密钥
常见的非对称算法：RSA、DSA、ECDSA
特点：算法强度复杂，安全性依赖于算法与密钥，但是由于算法复杂，加密解密速度极慢

非对称加密要用到两个密钥，一个公钥一个私钥，可以：

通过公钥对明文加密，通过私钥对密文解密
通过私钥对明文加密，通过公钥对密文解密

非对称原理涉及到的数学知识比较复杂，这里不作过多解释。

数据摘要&&数据指纹

数字指纹(数据摘要),其基本原理是利用单向散列函数(Hash函数)对信息进行运算，生成⼀串固定长度的数字摘要。数字指纹并不是⼀种加密机制,但可以用来判断数据有没有被窜改。
摘要常见算法：有MD5、SHA1、SHA256、SHA512等，算法把无限的映射成有限，因此可能会有碰撞（两个不同的信息，算出的摘要相同，但是概率非常低）
摘要特征：和加密算法的区别是，摘要严格意义不是加密，因为没有解密，只不过从摘要很难反推原信息，通常用来进行数据对比。

一般地，把对一个信息的摘要称为该消息的指纹或数字签名，数字签名是保证信息的完整性和不可否认性的方法。数据的完整性是指信宿接收到的消息一定是信源发送的信息，而中间绝无任何更改；信息的不可否认性是指信源不能否认曾经发送过的信息。其实，通过数字签名还能实现对信源的身份识别（认证），即确定"信源"是否是信宿意定的通信伙伴。数字签名应该具有唯一性，即不同的消息的签名是不一样的；同时还应具有不可伪造性，即不可能找到另一个消息，使其签名与已有的消息的签名一样；还应具有不可逆性，即无法根据签名还原被签名的消息的任何信息。这些特征恰恰都是消息摘要算法的特征，所以消息摘要算法适合作为数字签名算法。

应用场景

比如某一个网站支持VIP功能，那么当VIP访问该网站的时候就需要输入密码来验证身份，如果直接将密码发送到网络当中，无论使用哪种协议总会有泄漏的可能性，因此我们可以将密码利用数据摘要算法生成⼀串固定长度的数字摘要。

网站的服务器数据库里面存储的同样是数字摘要，虽然我们不知道密码的具体内容，但是可以通过比较两个摘要来确定密码的正确性从而验证登录者的身份，这样就避免了直接用网络传输密码，从根本上保证了安全。

数字签名

摘要经过加密生成数字签名（主要应用于证书，后面详细解释）

HTTPS工作过程探究

既然要保证安全，就需要对传输的数据进行加密。网络传输的过程中也就不再使用明文传输，而是加密之后的密文。刚才上面提到了两类加密方式对称加密和非对称加密，那么为什么会有两种加密方式呢？HTTPS协议实际工作的过程中又是使用的哪种加密方式呢？

方案1：只使用对称加密

如果通信双⽅都各自持有同⼀个密钥X，且没有别⼈知道，这两方的通信安全当然是可以被保证的（除非密钥被破解）。引入对称加密之后，即使数据被截获，由于黑客不知道密钥是啥，因此就⽆法进行解密，也就不知道请求的真实内容是啥了。

但事情没这么简单。服务器同⼀时刻其实是给很多客户端提供服务的。这么多客户端，每个人用的秘钥都必须是不同的(如果是相同那密钥就太容易扩散了，黑客就也能拿到了)。因此服务器就需要维护每个客户端和每个密钥之间的关联关系，这也是个很麻烦的事情。比较理想的做法是，在客户端与服务器建立连接的时候，双方就协商好这次通信要使用到的密钥。

但是如果直接把密钥明文传输，那么黑客就也能获得密钥了，此后的加密解密操作就形同虚设，白白浪费资源了。因此密钥的传输必须加密传输。但是要想对密钥进行对称加密，就仍然需要先协商确定⼀个"密钥的密钥"。这就成了"先有鸡还是先有蛋"的问题了。此时密钥的传输再用对称加密就行不通了，我们要考虑其他方法来保证密钥的安全性。

方案2：只使用非对称加密

鉴于非对称加密的机制，如果服务器先把公钥以明文方式传输给浏览器，之后浏览器向服务器传数据前都先用这个公钥加密好再传，从客户端到服务器信道似乎是安全的(有安全问题)，因为只有服务器有相应的私钥能解开公钥加密的数据。但是服务器到浏览器的这条路怎么保障安全？

如果服务器用它的私钥加密数据传给浏览器，那么浏览器⽤公钥可以解密它，而这个公钥是⼀开始通过明⽂传输给浏览器的，若这个公钥被中间⼈劫持到了，那他也能⽤该公钥解密服务器传来的信息了。

并且前文提到了非对称加密的速度极慢，网络通信过程除了安全问题最重要的就是效率问题，只使用对称加密既不安全速度又慢，因此不采用这种方法。

方案3：双方都使用非对称加密

服务端拥有公钥S与对应的私钥S'，客户端拥有公钥C与对应的私钥C'
客户端和服务端交换公钥
客户端给服务端发信息：先⽤S对数据加密，再发送，只能由服务器解密，因为只有服务器有私钥S'
服务端给客户端发信息：先⽤C对数据加密，在发送，只能由客户端解密，因为只有客户端有私钥C'

这样貌似可以，但是首先效率低下，其次也有安全问题，能够遭到中间人攻击（后面会讲）

方案4：非对称加密+对称加密

首先解决效率问题

服务端具有非对称公钥S和私钥S'
客户端发起https请求，获取服务端公钥S
客户端在本地⽣成对称密钥C，通过公钥S加密，发送给服务器。
由于中间的网络设备没有私钥，即使截获了数据，也⽆法还原出内部的原⽂，也就⽆法获取到对称密钥（实际上可以通过中间人攻击破解）
服务器通过私钥S'解密，还原出客户端发送的对称密钥C。并且使⽤这个对称密钥加密给客户端返回的响应数据。
后续客户端和服务器的通信都只⽤对称加密即可。由于该密钥只有客户端和服务器两个主机知道，其他主机/设备不知道密钥即使截获数据也没有意义。

由于对称加密的效率比非对称加密高很多，因此可以这样提高效率：只是在开始阶段协商密钥的时候使用非对称加密，后续的传输仍然使用对称加密。这样的做法已经很接近HTTPS采用的方法了，但是会遭到中间人攻击。

中间人攻击

MAN-in-the-MiddleAttack，简称“MITM攻击”

确实，在⽅案2/3/4中，客户端获取到公钥S之后，对客⼾端形成的对称秘钥X⽤服务端给客户端的公钥S进⾏加密，中间⼈即使窃取到了数据，此时中间⼈确实无法解出客⼾端形成的密钥X，因为只有服务器有私钥S'。HTTPS通信安全的关键在于对称加密的密钥是否加密传输，中间人攻击窃取的也正是对称加密的密钥。

上面非对称加密+对称加密的方式想法很正确，先采用非对称加密保证密钥的安全传输，保证以后通信的安全性，之后采用对称加密保证通信的效率。但是中间人攻击可以伪装成为服务器，在第一步非对称加密的途中就窃取到密钥。

首先中间人有自己的对称加密密钥C，中间人有非对称加密公钥M，私钥M'，server有S，S'。

client向server请求非对称加密公钥S，但是被中间人截获，中间人发送给client自己的私钥M'，并且向server请求公钥S
client申请到中间人的公钥M，误以为中间人是server，用中间人的公钥M加密自己的密钥C。server误以为中间人是client，将自己的公钥S发给中间人。
client将用M加密的密钥发给中间人，中间人可以用M'解密，密钥C泄漏。中间人收到server的公钥S。此时中间人就可以同时伪装成client和server，后续对称加密的密钥泄漏，安全性荡然无存！

了解完中间人攻击的具体过程，我们仔细分析一下可以发现，安全性出现危机的关键在于，客户端无法确定收到包含公钥的数据报文是由谁发送的，即client无法验证公钥的权威性。

证书的引入

为了解决上面的中间人攻击，HTTPS引入了证书来保证信息的安全传输。

对于中间人来说，证书可以说是一个很聪明的阳谋

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

CA认证

CA认证，即电子认证服务，是指为电子签名相关各方提供真实性、可靠性验证的活动。

证书颁发机构（CA, Certificate Authority）即颁发数字证书的机构。是负责发放和管理数字证书的权威机构，并作为电子商务交易中受信任的第三方，承担公钥体系中公钥的合法性检验的责任。

这个证书可以理解成一个结构化的字符串，里面包含了以下信息：

证书发布机构
证书有效期
公钥
证书所有者
签名

需要注意的是：申请证书的时候，需要在特定平台生成，会同时生成⼀对密钥对，即公钥和私钥。这对密钥对就是用来在网络通信中进行明文加密以及数字签名的。

其中公钥会随着CSR⽂件，⼀起发给CA进行权威认证，私钥服务端自己保留，用来后续进行通信（其实主要就是用来交换对称秘钥）

可以使用在线生成CSR和私钥：https://myssl.com/csr_create.html
形成CSR之后，后续就是向CA进行申请认证，不过⼀般认证过程很繁琐，网络各种提供证书申请的服务商，⼀般真的需要，直接找平台解决就行。

数据签名

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

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

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

查看CA机构

在浏览器中点击右上角的

选择"设置"，搜索"证书管理"，即可看到以下界面(如果没有，在隐私设置和安全性->安全⾥⾯找找)

方案5：非对称加密+对称加密+证书认证

上面我们已经分析完毕中间人攻击的过程，得出了公钥的权威性无法保证的结论。那么证书认证的出现就能够保证server公钥的权威性，具体实现过程如下：

在客户端和服务器刚⼀建立连接的时候，服务器给客户端返回⼀个证书，证书包含了之前服务端的公钥，也包含了网站的身份信息。

客户端进行认证，当客户端获取到这个证书之后，会对证书进行校验(防止证书是伪造的)。

判定证书的有效期是否过期
判定证书的发布机构是否受信任(操作系统中已内置的受信任的证书发布机构)
验证证书是否被篡改

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

中间人有没有可能篡改证书

中间⼈篡改了证书的明⽂
由于他没有CA机构的私钥，所以⽆法hash之后⽤私钥加密形成签名，那么也就没法办法对篡改后的证书形成匹配的签名
如果强行篡改，客户端收到该证书后会发现明⽂和签名解密后的值不⼀致，则说明证书已被篡改，证书不可信，从而终止向服务器传输信息，防⽌信息泄露给中间⼈

中间人掉包整个证书？

因为中间⼈没有CA私钥，所以无法制作假的证书
所以中间⼈只能向CA申请真证书，然后用自己申请的证书进行掉包
这个确实能做到证书的整体掉包，但是别忘记，证书明⽂中包含了域名等服务端认证信息，如果整体掉包，客户端依旧能够识别出来。
并且如果中间人向CA申请了真的证书，自已一定要填真实的信息，此时中间人的身份会暴露给CA机构，如果这样中间人还敢非法操作一定会受到法律制裁
永远记住：中间⼈没有CA私钥，所以对任何证书都⽆法进⾏合法修改，包括自己的

HTTPS完整流程

总结：

HTTPS⼯作过程中涉及到的密钥有三组

第一组(非对称加密):用于校验证书是否被篡改。服务器持有私钥(私钥在形成CSR⽂件与申请证书时获得)，客户端持有公钥(操作系统包含了可信任的CA认证机构有哪些，同时持有对应的公钥)。服务器在客户端请求是，返回携带签名的证书。客户端通过这个公钥进行证书验证，保证证书的合法性，进⼀步保证证书中携带的服务端公钥权威性。

第二组(非对称加密):用于协商⽣成对称加密的密钥。客户端用收到的CA证书中的公钥(是可被信任的)给随机⽣成的对称加密的密钥加密，传输给服务器，服务器通过私钥解密获取到对称加密密钥。

第三组(对称加密):客户端和服务器后续传输的数据都通过这个对称密钥加密解密。

其实⼀切的关键都是围绕这个对称加密的密钥。其他的机制都是辅助这个密钥工作的