参考文章

HTTPS 是什么

HTTPS , Hyper Text Transfer Protocol over Secure Socket Layer 。从英文释义可以看出，HTTPS 就是 HTTP + SSL 或者 HTTP + TLS 。

上面的英文缩写不是 HTTP over SSL 吗？
TTPS 最初使用的加密协议的确是 SSL，SSL 最近的三个版本是：SSL 1.0 、SSL 2.0 、SSL 3.0 ，不过随着加密算法的发展和人们对传输安全性要求的提高，截止目前已经长江后浪推前浪依次推出了 TLS 的四个版本，分别是：TLS 1.0 、TLS 1.1 、TLS 1.2 以及前不久刚推出的 TLS 1.3 。

与 HTTP 的差异

image.png

中间人攻击

http 在传输时信息是明文，这个信息有可能被某个中间人恶意截获甚至篡改。这种行为叫做中间人攻击。
image.png

如何避免中间人攻击?

先定义中间人攻击这个问题

我们讨论的这个中间人攻击, 是针对客户端和服务端间通信时有第三方截获信息进行恶意篡改利用.

在实际生产中, 可以使用 “QQ/微信/邮件/邮寄” 等方式, 只要确信传递的密钥没有问题, 那么对称加密/非对称加密都是安全的.

下面的讨论, 都是建立在 “第一次传递密钥时是否可信的基础上”.

对称加密泄露密钥后信息被解密

第一次约定加密方式和密钥的通信仍然是明文，如果第一次通信就已经被拦截了，那么密钥就会泄露给中间人，中间人仍然可以解密后续所有的通信内容。
image.png

非对称加密-中间人可能替换密钥对

中间人虽然不知道小红的私钥是什么，但是在截获了小红的公钥Key1之后，却可以偷天换日，自己另外生成一对公钥私钥，把自己的公钥Key3发送给小灰。
image.png

小灰不知道公钥被偷偷换过，以为Key3就是小红的公钥。于是按照先前的流程，用Key3加密了自己生成的对称加密密钥Key2，发送给小红。

这一次通信再次被中间人截获，中间人先用自己的私钥解开了Key3的加密，获得Key2，然后再用当初小红发来的Key1重新加密，再发给小红。

image.png

HTTP 基本思路

1. 服务端向 CA 厂商申请数字证书

作为服务端的小红，首先把自己的公钥发给证书颁发机构，向证书颁发机构申请证书。

申请证书时, 服务端需要提供自己的公钥.

image.png

2. CA 厂商签发数字证书

证书颁发机构自己也有一对公钥私钥。

  • 机构利用自己的私钥来加密Key1(服务端小红的公钥)，并且通过服务端网址等信息生成一个证书签名.
  • 证书签名同样经过机构的私钥加密。
  • 证书制作完成后，机构把证书发送给了服务端小红。

image.png

3. 客户与服务端通信时返回公钥

当小灰向小红请求通信的时候，小红不再直接返回自己的公钥，而是把自己申请的证书返回给小灰。

注意: **第一次通信时**, 服务端都需要返回数字证书给客户端. 客户端验证证书后, 会生成一个对称加密的密钥, 之后通信都是用这个对称加密的密钥.—— 这叫做密钥协商.
image.png

4. 客户端验证数字证书

CA 厂商的公钥已经内置到客户端系统中

各大浏览器和操作系统已经维护了所有权威证书机构的名称和公钥。(这点在数字证书中有进一步阐述)
那客户端只需要知道是哪个机构颁布的证书，就可以从本地找到对应的机构公钥.

客户端根据 CA 公钥验证 “证书签名”

如果证书签名验证通过, 说明证书提供的内容是可信的. 即证书内提供的服务器信息和服务器公钥是可信的.
image.png

image.png

5. 客户端生成对称密钥并通知服务端

像之前一样，小灰生成自己的对称加密密钥Key2，并且用服务端公钥Key1加密Key2，发送给小红。

费这么大劲, 只是想解决第一次通信传递密钥时是可信的, 没有遭受中间人攻击.

image.png

6. 后续通信进行对称加密

最后，小红用自己的私钥解开加密，得到对称加密密钥Key2。于是两人开始用Key2进行对称加密的通信。
image.png

SSL/TLS协议的基本思路是采用公钥加密法，也就是说，客户端先向服务器端索要公钥，然后用公钥加密信息，服务器收到密文后，用自己的私钥解密。
但是，这里有两个问题。
（1）如何保证公钥不被篡改？
解决方法：将公钥放在数字证书中。只要证书是可信的，公钥就是可信的。
（2）公钥加密计算量太大，如何减少耗用的时间？
解决方法：每一次对话（session），客户端和服务器端都生成一个”对话密钥”（session key），用它来加密信息。由于”对话密钥”是对称加密，所以运算速度非常快，而服务器公钥只用于加密”对话密钥”本身，这样就减少了加密运算的消耗时间。
因此，SSL/TLS协议的基本过程是这样的：
（1） 客户端向服务器端索要并验证公钥。
（2） 双方协商生成”对话密钥”。
（3） 双方采用”对话密钥”进行加密通信。

相关概念

CA 厂商

CA, Certificate Authority. CA 厂商.
传输之前首先通过数字证书来确认身份，各大 CA 厂商干的就是这个事情。

数字证书

数字证书分为公钥和私钥，CA 厂商会用自己的私钥来给证书申请者签发一套包含私钥和公钥的客户证书，客户的公钥证书谁都可以获取，里面包含了客户站点和证书的基本信息，用来确保访问者访问的就是他想要访问的站点。

这段的精髓就是, CA 厂商使用非对称加密技术的生成签名的方法, 用厂商自己的私钥来给申请者签发一套证书. 这个证书的特点:

  • 证书也使用了非对称加密技术, 包含公钥和私钥两个部分;
  • 这个证书的真实性由 “证书的签名” 来保证.

CA 厂商的客户是谁? 想给网站增加 HTTPS 的那些公司.

访问者是谁? 访问者就是指浏览网站的这些人. 我们的浏览器在访问网站时, 发现该网站是 https 开头的, 就会把这个网站的公钥证书拿来校验, 看看是真的还是钓鱼网站.

数字证书包含什么?

image.png

数字证书不可以伪装也不可破解

原因一：系统早已内置了各大 CA 厂商的公钥来校验证书是否是对应的站点的证书，如果不是，就会给出证书不匹配的提示，除非你给别人的设备强行植入假的 CA 公钥。

系统指的是我们的操作系统, 安卓手机打开 “设置->安全->加密与凭据->信任的凭据” 就可以看到上百个 CA 厂商的公钥.

原因二：这个证书是 CA 厂商通过哈希并加密得到的，基本无法逆向破解并伪造一个新的，除非是你黑进 CA 获取了 CA 的私钥，那这家 CA 也基本可以倒闭了。

即也不可逆向.

HTTPS 为什么安全?

confidentiality-加密技术

把传输内容加密处理, 即使传输过程中被截获, 也不会泄露内容.
数据保密包括对话秘钥传输时候的保密和数据的加密传送:

对话秘钥-非对称

对话秘钥：以 TLS 1.2 使用的套件之一 DHE-RSA-AES256-SHA256 为例：该套件是以 DHE 、RSA 作为秘钥交换算法，这两种秘钥交换算法都是使用的非对称加密，数学原理分别依赖于计算离散对数的难度和大数分解的难度。也就是在建立 HTTPS 链接的过程中，刚开始是有一些明文出现的，不过想要根据这些已知的明文推算出“对话秘钥”却非常困难。

对称加密

对话加密：客户端和和服务端协商并成功获取到对话秘钥后就开始用对话秘钥进行对称加密会话，上面的套件我们可以看到使用的是 AES256 加密算法。

Intergrity-数据一致性-哈希算法

传输的内容不会被替换掉.
身份认证成功后，到了数据加密传输的阶段，所有数据都以明文（HTTP）收发，只不过收发的是加密后的明文。这时候也遇到了一个问题，虽然中间人很难破解加密后的数据，但是如果他对数据进行了篡改，那该怎么办？

此时加密套件验证数据一致性的哈希算法就派上用场了，哈希算法有多种，比如 MD5 ，SHA1 或者 SHA2 等，上面举例的加密套件使用的是 SHA2 中的 SHA256 来对数据进行哈希计算。这样就使得任何的数据更改都会导致通信双方在校验时发现问题，进而发出警报并采取相应的措施。

Authentication-认证

从连接到这个网站开始，到你关闭这个页面为止，你和这个网站之间收发的所有信息，就连url的一部分都被保护了. 免受中间人攻击.

为什么后续会话使用对称加密?

那么为什么“对话秘钥”的交换使用非对称加密，正式对话数据的传输使用对称加密？
对称加密效率高.
因为非对称加密虽然安全性比较高，但是它的效率比较低，速度比较慢，所以我们一般只使用它们来交换一下对话秘钥，后面的对话加密则使用速度更快，效率更高的对称加密。