快速了解 HTTPS

1. 引入

在 HTTP 协议 章节的 reference 段，曾提到过 HTTPS。这里对HTTPS进行详细介绍。

HTTPS 是在 HTTP 的基础上，引入了一个加密层 (SSL)。HTTP 是明文传输的 (不安全)。当下所见到的大部分网站都是 HTTPS 的。

起初是拜运营商劫持所赐（篡改 reference……）。但是，即使运营商 不劫持, 如果黑客盯上了, 也是可能会对你的信息安全造成一些影响的。举个例子：黑客能否用自己的设备伪造一个 “商场 wifi” ，一旦你的数据经过了黑客的设备, 又没有加密（HTTP 是明文）, 就非常危险了，尤其是 “各种密码之类的”。

解决安全问题，最核心的要点，就是"加密"。加密的成本很低，破解的成本很高。只要破解成本，超出了要保护的数据价值本身，就是安全的。eg：造一个100元的假钞，成本花了110元

密码学中的几个重要概念：

1. 明文：要传输的真实的数据，要表达的实际的意思。

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

3. 明文 变 密文 的过程 加密。

4. 密文 变 明文 的过程 解密。

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

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

7. 非对称加密 ： 加密和解密，使用的是两个密钥。 这两个密钥，k1, k2, 是成对的。使用 k1 来加密，此时就是 k2 解密；也可以使用 k2 加密，此时就是 k1 解密（这个特性的背后有一系列的数学原理）。两个密钥，就可以一个公开出去，称为 “公钥”，另一个自己保存好，称为 “私钥”。手里只有一把的话，是无法知道另一把是什么的（也是有一定的数学原理的）

2. HTTPS 工作过程

只要针对 HTTPS 的数据进行解密了，就能够得到 HTTP 格式的数据。
上述的运营商劫持，无论是修改 referer 还是修改返回的链接(body)，本质上都是明文传输惹的祸。需要引入加密，对上述传输的数据进行保护，主要就是要针对 header 和 body 进行加密。

2.1 引入对称加密

通过对称加密的方式，针对传输的数据进行加密操作。

网络上传输的内容就是密文了

1. 对称加密的时候，客户端和服务器需要使用同一个密钥。
2. 不同的客户端，需要使用不同的密钥。（如果所有的客户端密钥都相同，加密形同虚设，黑客很容易拿到密钥）
   这就意味着，每个客户端连接到服务器的时候，都需要自己生成一个随机的密钥，并且把这个密钥告知服务器。（不一定非得是客户端生成，由服务器生成后告诉给客户端也行）。
   这就是问题的关键， 密钥需要传输给对方的。一旦黑客拿到了这个密钥，意味着加密操作就无意义了。
   
   需要考虑，针对密钥，也进行密文传输，但是假设使用对称加密，引入 key2 针对 key 进行加密，意味着，就需要把 key2 地传输给服务器，服务器才能解密拿到 key，还是可能被黑客拿到key2，然后知道 key，进而得到明文。

2.2 引入非对称加密

使用非对称加密，主要的目的是为了对对称密钥进行加密（确保对称密钥的安全性）。

不能使用非对称加密，针对后续传输的各种 header body 等进行加密，而是只能使用非对称加密去加密对称密钥。
非对称加密的加密解密成本（消耗的 CPU 资源）要远远高于对称加密。少用点，可以。如果大规模使用，就成本很大了。

可让服务器生成公钥 私钥，私钥只具备服务器自己知道、公钥可以告诉任何人。由于公钥本身就是可以公开的，不加密也无所谓，此处就让服务器持有私钥（只有服务器知道），客户端持有公钥（黑客也能知道）。

客户端使用公钥对生成的对称密钥进行加密，黑客虽然手里有公钥，但是密文需要通过私钥才能解密。黑客无法对这个数据解密，也就不能拿到 888888 对称密钥（黑客监听中间的通信数据，要比黑人服务器这边容易一些。如果能跟进服务器了，大概率就可以直接拖数据库了，用户啥信息都被拿到了）。
只要 888888 安全到达服务器，后续服务器和客户端之间就可以使用 888888 作为对称加密的密钥，此时黑客就无法破解后续的数据了。

上述操作, 其实仍然存在严重的漏洞，黑客仍然有办法破解掉其中的加密操作——中间人攻击。

服务器可以创建出一对公铀和私铀, 黑客, 也可以按照同样的方式, 创建出一对公钥和私钥
冒充自己是服务器（生成公钥和私钥的算法都是开放的，服务器能生成，黑客也能生成）。

客户端拿到pub2 之后，无法区分 pub2 是否是服务器的，于是客户端拿着pub2 就对 key 加密了。黑客就使用 pri2 对上述数据进行解密，因此黑客就拿到了 key。黑客继续使用从服务器拿到的 pub1 重新对 key 进行加密，并且传输给服务器。服务器拿到数据之后, 使用 pri1 来解密，当然可以解密成功，于是服务器就知道了对称密钥是 key 了。
后续的通信, 服务器和客户端之间仍然会继续使用 key 作为加密的密钥，此时后续传输的各种数据就都可以被黑客解密了。

2.3 证书

针对上述中间人攻击问题，如何解决？
最关键的一点，客户端拿到公钥的时候，要能有办法验证，这个公钥是否是真的，而不是黑客伪造的。
这要求服务器要提供一个"证书"，证书是一个结构化的数据(里面包含很多属性，最终以字符串的形式提供)。证书中会包含一系列的信息，比如：服务器的主域名、公钥、证书有效期……

证书是搭建服务器的人，要从第三方的公正机构进行申请的（申请的时候当然要提交材料，人家要审核）

一个关键问题: 返回证书的时候证书数据也是经过了黑客的设备，此时黑客是否能够改正书中的公钥？ 将公钥替换成自己的公钥呢？
答：不行，客户端拿到证书之后，会先针对证书验证真伪。

证书验证的过程
假设这是一个证书，
证书:
服务器的域名: …
证书的有效时间: …
服务器的公钥: …
公证机构信息: …
证书的签名: …

颁布证书的公证机构会在发布证书的时候，给这个证书计算出一个校验和。然后公证机构使用自己的私钥(如服务器的私钥无关)，针对校验和进行加密，此时就得到了证书的签名。

市面上的公证机构一共也没多少，这些公证机构持有自己的私钥，对应的公钥都包含在常见的系统中。windows 里面就内置了大量的公钥，(如果没有，也可以额外安装)。前面安装的 fiddler，有一步操作，就是安装证书(主要就是安装 fiddler 这边提供的公钥)。

此处所谓的"签名"本质上是一个经过加密的校验和，把证书中其他的字段通过一系列的算法（CRC, MD5 等），得到一个较短的字符串。=> 校验和
如果两份证书内容一样，此时校验和，就是相同的，如果校验和不同，两份数据的内容则一定不同。(逆否命题)

客户端拿到证书之后，主要做两件事：

1. 按照同样的校验和算法，把证书的其他字段重新算一遍，得到校验和1
2. 使用系统中内容的公证机构公钥，对证书中的签名进行解密，得到校验和2

此时，就可以对比，看这俩校验和是否一致。如果一致，说明证书是没有被修改过的，就是原版证书；如果不一致，说明证书被别人篡改过了。(比如黑客如果替换了自己的公钥，此时算出来的校验和一定发生改变)，此时客户端就能识别出来了。

证书主要是防止黑客篡改，而不是防止黑客知道，黑客的系统也内置了公证机构的公钥
黑客也能解密，但是黑客无法修改证书的内容。

1. 如果黑客直接修改 公钥，不修改签名。
   此时，客户端验证的校验和是一定不一样的。就识别出来了。

2. 如果黑客修改公钥，也尝试重新生成签名，由于黑客不知道公证机构的私钥，所以黑客无法重新生成加密的签名；
   如果黑客拿自己的私钥加密，客户端这边拿着公证机构的公钥也会解密失败。
   上述操作，就把黑客篡改证书的行为给堵死了。

3. 黑客能不能自己去公证机构申请个证书？然后把自己的证书替换掉服务器的证书呢？
   不行，域名是唯一的，黑客申请的证书的域名，和服务器的域名肯定不相同。客户端拿到证书之后，一看域名都不一样，直接就知道证书是假冒的了，都不用验证校验和了。

有时浏览器告诉用户访问的网站有风险，请谨慎访问，可能是黑客进行了中间人攻击，也可能是证书过期了。

当然，上述讨论的过程，所谓的安全，也不是绝对的安全。上述的安全本质上都是基于非对称加密体系。非对称加密体系，也不是无懈可击的。只不过破解这样的加密体系，需要的计算量非常大，随着算力的提升，尤其是量子计算机崛起，算力又会大幅度提升，对于现有的密码学体系就会造成重大冲击。