1. 认识HTTPS

HTTPS全称为 Hyper Text Tranfer Protocol over SecureSocket Layer。HTTPS协议也是一个应用层协议，是在HTTP协议的基础上引入了一个加密层。

在传统的HTTP协议中，数据以明文的形式在网络上传输，这意味着敏感信息（如密码、个人信息等）可能会在传输过程中被攻击者截获和窃取。为了解决这个安全问题，HTTPS通过使用安全套接字层（SSL，Secure Sockets Layer）或传输层安全（TSL，Transport Layer Security）协议对HTTP进行加密，从而在数据传输过程中提供加密和认证保护。

HTTP和HTTPS只是在技术上有交集，实际上它们是两种不同的协议。一般来说，HTTP协议使用的端口号是80，HTTPS协议使用的端口号是443。

认识相关术语

• 明文：要传输的原始的消息
• 密文：通过加密将明文变换之后的内容
• 加密：把明文进行一些列变换，生成密文
• 解密：把密文进行一系列变换，还原成明文
• 密钥：在加密和解密的过程中，需要一个或者多个中间数据，辅助进行这些过程，这样的数据称为密钥

比如在下面这样的一个过程中：

a的值就可以称之为明文， key数据就可以称之为密钥。将a与key进行异或的过程，可以称之为加密，而异或得到的b，就可以称之为密文。我们知道，如果b此时再与key进行异或，那么会得到a的值，也就是会得到明文的内容，这也就是解密的过程。

当然，实际我们使用的加密方法要比这复杂的多，但是我们可以通过这个例子来大致理解加密解密的过程是怎样的。

2. 使用HTTPS加密的必要性

就好比两个人传纸条，纸条需要经过中间人。如果不对数据进行加密，那么中间人也可以打开纸条看到数据了，甚至对数据进行篡改。我们对数据进行加密，本质上就是防止有个中间人看到或者修改我们的数据内容。

试想一下这样的场景，你给喜欢的女生写情书，中间让另一个人帮忙传递。但是他居然打开情书偷偷看里面的内容了，更损的事是他把名字给修改了！从这我相信你也知道了给数据加密的重要性了。

以臭名昭著的运营商劫持事件为例

我们知道，不管是公司、学校亦或是家庭网络，都是由运营商提供服务的，我们发送消息，或者是接收消息，中间都是要经过运营商的。

我们本来想要下载一款软件，原本在点击下载按钮之后，会弹出这款软件的下载链接，但是被数据包被劫持之后，就可能会弹出另一款软件的下载链接。

由于我们通过网站传输的任何数据报都会经过运营商的网络设备（路由器、交换机等），那么运营商的网络设备就可以解析出你传输的数据内容，并进行篡改。

点击“下载按钮”，其实就是给服务器发送了一个HTTP请求，获取到的HTTP响应其实就包含了该APP的下载链接，但是运营商劫持之后，发现这个请求是要下载一款软件，那么就自动将交给用户的响应篡改成另一款软件的下载地址了。

运营商为什么要做这样的事？

使用HTTPS不只是因为这一个事件，这里只是进行一个举例。还有更重要的原因，比如保护用户隐私，防止数据被篡改，确保网站的真实性等等。 试想一下，如果黑客在用户登录支付宝的时候获取到用户的账号密码，甚至获取到用户的支付密码，后果会有多么严重…

3. 常见的加密方式

3.1 对称加密

• 采用单钥密码系统的加密方法，同一个密钥可以同时用作信息的加密和解密，这种加密方法称为对称加密，也称为单密钥加密，特征：加密和解密所用的密钥是相同的。
• 常见对称加密算法（了解即可）：DES、3DES、AES、TDEA等
• 特定：算法公开、计算量小、加密速度快、加密效率高。

对称加密其实就是通过同一个密钥，可以把明文加密成密文，并且也能将密文加密成明文。

上面我所举的按位异或的例子用的就是简单的对称加密的方法。当前，按位异或只是最简单的对称加密，HTTPS中肯定用的不是按位异或。

单纯使用对称加密的方法可行吗？

首先，如果能做到客户端和服务端都拥有这个密钥且没有第三者做到，那理论上对称加密是可以的，但是如果才能做到这个密钥不如其他人知道呢？

无论是这个密钥是客户端生成发送给服务端，还是服务端生成发送给客户端，此时如果有中间人窃取了该密钥的信息，那往后所谓的“加密”数据，中间人都可以将其解密，获取数据后再加密，这样就拿到数据了。

因此密钥的传输也必须进行加密传输！

但是如果想对密钥进行对称加密，就仍然需要先协商确定一个“密钥的密钥”，这就形成了“先有鸡还是先有蛋”的问题了，此时密钥的传输再用对称加密就行不通了。

所以单纯地使用对称加密是行不通的，我们还需要引非对称加密。

3.2 非对称加密

• 需要两个密钥来进行加密和解密，这两个密钥是公钥和私钥。
• 常见非对称加密算法（了解）：RSA，DSA，ECDSA
• 特点：算法强度复杂、安全性异彩与算法与密钥但是由于其算法复杂，而是的加密解密速度密钥对称加密解密的速度快。

非对称加密要用到两个密钥，一个叫做公钥，一个叫做私钥。公钥和私钥是配对的，最大的缺点就是运算速度非常慢，比对称加密要慢很多。

过程如下：

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

也可以反着用

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

非对称加密的数学原理比较复杂，涉及到一些数论相关的知识。这里举一个生活上的例子：
比如A给一个文件上锁，只有B有解锁的钥匙。这个场景中，锁就相当于公钥，钥匙就是私钥，私钥只有B才拥有，也就是说，只有B才能进行解密。

那么非对称加密可以防范中间人攻击吗？

鉴于非对称加密的机制，我们可能会有这种思路：服务器先把公钥以明文方式传输给浏览器，之后浏览器向服务传数据前都先用这个公钥加密好再传，这样数据的安全似乎就可以保障了，因为只有服务器有相应的私钥能解开公钥加密的数据。

然而反过来由服务器到浏览器的这条路怎么保障安全？如果服务器用它的私钥加密数据传给浏览器，那么浏览器用公钥可以解密它，而这个公钥是一开始通过明文传输给浏览器的，若这个公钥中间被人劫持到了，那它也能用该公钥解密服务器传来的信息了。所以目前只能保证由浏览器向服务器传输数据的安全性。

所以，一组公钥私钥，至少可以确保单向的数据安全，那么我们可不可以合理推断如果我有两组公钥私有，那我就可以保证双向数据传输的安全了呢？

• 某网站服务器拥有公钥A与对应的私钥A’，浏览器拥有公钥B与对应的私钥B’
• 服务器把公钥A传给浏览器
• 浏览器把公钥B传给服务器
• 之后浏览器向服务器传输的内容都用公钥A加密，服务器收到后用私钥A’加密。由于只有服务拥有私钥A’，所以能保证数据的安全。
• 同理，服务器向浏览器传输的内容都用公钥B加密，浏览器收到后用私钥B’加密，也能保证数据的安全。

这样似乎就成功了，但是非对称加密方法非常耗时，这样的方法在实际中其实我们并没有去用。

有没有一种方法，可以让客户端和服务端都使用私密的密钥进程对称加密呢？

3.3 非对称加密+对称加密

• 服务端具有非对称公钥S和私钥S’
• 客户端发起HTTPS请求，获取服务端公钥S
• 客户端在本地生成对称密钥C，通过公钥S加密，发送给服务器。
• 由于中间的网络设备密钥私钥，即使截获了数据，也无法还原出内部的原文，也就无法获取到对称密钥了。
• 服务器通过私钥S’解密，还原出客户端发送的对称密钥C，并且使用这个对称密钥加密给客户端返回的响应数据。
• 后续客户端和服务器的通信都只用对称加密即可，由于该密钥只有客户端和服务器两个主机知道，其他主机/设备不知道密钥即使截获数据也没有意义。

由于对称加密的效率比非对称加密高很多，因此只是在开始阶段协商密钥的时候使用非对称加密，后续的传输仍然使用对称加密。

这样就解决了通信时数据的安全问题了吗？进度条告诉你，事情没这么简单！

如果从一开始，服务端在传输公钥S的时候，中间人将该公钥S换成了其他的公钥呢？

• 服务器具有非对称加密算法的公钥S，私钥S’
• 中间人具有非对称加密算法的公钥M，私钥M’
• 客户端向服务器发起请求，服务器明文传送公钥S给客户端
• 中间人劫持数据报文，提取公钥S并保存好，然后将劫持报文中的公钥S换成自己的公钥M，并将伪造报文发给客户端
• 客户端收到报文，提取公钥M（它不知道公钥被更换过了），自己形成对称密钥X，用公钥M加密X，形成报文发送给服务器
• 中间人劫持后，直接用自己的私钥M’进行解密，得到通信私钥X，再用曾经保存的服务端公钥S加密后，将报文推送给服务器
• 服务器拿到报文，用自己的私钥S’解密，得到通信密钥X
• 双方开始采用X进行对称加密，进行通信。但是一切都在中间人的掌握之中，劫持数据，进行窃听甚至修改，都是可以的

为了解决问题，下面引入CA证书。

4. 引入CA证书

4.1 CA认证

HTTPS协议不是想用就能用的，服务端在使用HTTPS之前，需要向CA机构申领一份数字证书，数字证书里包含了证书的申请者信息，公钥信息等。服务器把证书传输给浏览器，浏览器从证书里获取公钥就可以了。

证书就好比身份证，证明服务端公钥的权威性。

当客户端第一次向服务端发起请求的时候，其实服务端返回的不仅仅是公钥，而是CA证书，证书内包含了公钥和其他信息。

CA认证是什么？

CA认证，即电子认证服务 ，是指为电子签名相关各方提供真实性、可靠性验证的活动。
证书颁发机构（CA, Certificate Authority）即颁发数字证书的机构。是负责发放和管理数字证书的权威机构，并作为电子商务交易中受信任的第三方，承担公钥体系中公钥的合法性检验的责任。

证书含有的重要信息有：

• 证书办法机构
• 证书有效期
• 公钥
• 证书所有者
• 签名

4.2 数据签名

服务器发来的公钥的合法性，是要通过证书来进行甄别的。问题是，证书怎么做到的呢？或者说，我们如何保证证书的合法性？

引入数字签名

数据签名和形成是基于非对称加密算法的。

我们申请证书的时候，只是将图中的明文信息给了CA机构。

CA机构会将这些数据进行哈希散列，得到一个哈希值。然后，CA机构会用它自己的私钥对这个哈希值进行加密，形成一个数据签名。将数据和数据签名合在一起，就变成了带有数据签名的数据了。

那么这个签名该怎么使用呢？客户端拿到服务端的CA整数之后，会将数据和数据签名分开。将数据进行哈希散列形成一个哈希值。再将数据签名使用CA机构的公钥进行解密，也得到一个哈希值。将这两个哈希值进行比较，如果相同，则说明证书是正确的。

两个概念的解释：

1. 数据摘要：数据在经过哈希散列之后形成的哈希值
2. 数据签名：CA机构使用自己的私钥对数据摘要进行加密得到数据签名

4.3 非对称机密+对称加密+证书认证

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

服务器申请CA证书

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

1. CA机构拥有非对称加密的私钥A和公钥A’
2. CA机构对服务端申请的整数明文数据进行hash，形成数据摘要
3. 然后对数据摘要用CA私钥A’加密，得到数据签名S

服务端申请的证书明文和数字签名S共同组成了数字证书，这样一份数字证书就可以颁发给服务器了。

客户端进行认证

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

• 判定证书的有效期是否过期
• 判定证书的发布机构是否受信任（操作系统中已内置受信任的证书发布机构）
• 验证证书是否被篡改：从系统中拿到该证书发布机构的公钥，对签名解密，得到一个hash值（称为数据摘要），然后计算整个整数的hash值，对比它们看是否相等，如果相等，则说明整数是没有被篡改的。

4.4 常见问题

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

如果中间人篡改了证书的明文，那他没有CA机构的私钥，也就没法生成对应的数据签名，那么他的篡改结果就不符合CA证书的规定了。如果强行篡改，也就是说用自己的私钥去加密数据摘要得到数据签名，那么这样客户端收到证书之后会发现明文和前面解密后的值不一致，则说明证书已被篡改，证书不可信，从而终止向服务器传输信息，防止信息泄漏给中间人。

那中间人要是整个掉包证书呢？

• 由于中间人没有CA私钥，所以他不能制作假的证书
• 所以中间人只能向CA机构申请真证书，然后用自己申请的证书进行掉包
• 这个确实能做到证书的整体掉包，但是别忘记，证书明文中包含了域名等服务端认证信息，如果整体掉包，客户端依旧能识别出来。
• 并且，有没有这么傻的黑客，为了窃取你的数据，把自己的信息也给泄漏了。

5. 总结

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

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

第二组（非对称加密）：用于协商生成对称加密的密钥，客户端收到CA证书中的公钥给随机生成的对称加密的密钥进行加密，服务器通过私钥解密获取到对称加密的密钥。

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

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

• 第一组非对称加密的密钥是为了让客户端拿到第二组非对称加密的公钥
• 第二组非对称加密的密钥是为了让客户端把对称密钥传给服务器