HTTPS实现原理

HTTPS（Hypertext Transfer Protocol Secure）是一种通过计算机网络进行安全通信的传输协议。**HTTPS经由HTTP进行通信，但利用TLS来加密数据包。**HTTPS开发的主要目的，是提供对网站服务器的身份认证，保护交换数据的隐私与完整性。

HTTPS: 在HTTP之下增加一个安全层TLS，来保证HTTP的加密传输

TLS是传输层加密协议，前身是SSL协议。由网景公司于1995年发布。后改名为TLS。常用的 TLS 协议版本有：TLS1.2, TLS1.1, TLS1.0 和 SSL3.0。其中 SSL3.0 由于 POODLE 攻击已经被证明不安全。TLS1.0 也存在部分安全漏洞，比如 RC4 和 BEAST 攻击。

由于HTTP协议采用明文传输，我们可以通过抓包很轻松的获取到HTTP所传输的数据。因此，采用HTTP协议是不安全的。这才催生了HTTPS的诞生。

HTTPS相对HTTP提供了更安全的数据传输保障。主要体现在三个方面：

• 1， 内容加密。客户端到服务器的内容都是以加密形式传输，中间者无法直接查看明文内容。
• 2， 身份认证。通过校验保证客户端访问的是自己的服务器。
• 3， 数据完整性。防止内容被第三方冒充或者篡改。

其实为了提高安全性和效率HTTPS结合了对称和非对称两种加密方式。即客户端使用对称加密生成密钥（key）对传输数据进行加密，然后使用非对称加密的公钥再对key进行加密。因此网络上传输的数据是被key加密的密文和用公钥加密后的密文key，因此即使被黑客截取，由于没有私钥，无法获取到明文key，便无法获取到明文数据。所以HTTPS的加密方式是安全的。

对称加密

对称加密，顾名思义就是加密和解密都是使用同一个密钥，常见的对称加密算法有 DES、3DES 和 AES 等，其优缺点如下：

优点：算法公开、计算量小、加密速度快、加密效率高，适合加密比较大的数据。

缺点：交易双方需要使用相同的密钥，也就无法避免密钥的传输，而密钥在传输过程中无法保证不被截获，因此对称加密的安全性得不到保证。

每对用户每次使用对称加密算法时，都需要使用其他人不知道的惟一密钥，这会使得发收信双方所拥有的钥匙数量急剧增长，密钥管理成为双方的负担。对称加密算法在分布式网络系统上使用较为困难，主要是因为密钥管理困难，使用成本较高

非对称加密

非对称加密，顾名思义，就是加密和解密需要使用两个不同的密钥：公钥（public key）和私钥（private key）。公钥与私钥是一对，如果用公钥对数据进行加密，只有用对应的私钥才能解密；如果用私钥对数据进行加密，那么只有用对应的公钥才能解密。非对称加密算法实现机密信息交换的基本过程是：甲方生成一对密钥并将其中的一把作为公钥对外公开；得到该公钥的乙方使用公钥对机密信息进行加密后再发送给甲方；甲方再用自己保存的私钥对加密后的信息进行解密。如果对公钥和私钥不太理解，可以想象成一把钥匙和一个锁头，只是全世界只有你一个人有这把钥匙，你可以把锁头给别人，别人可以用这个锁把重要的东西锁起来，然后发给你，因为只有你一个人有这把钥匙，所以只有你才能看到被这把锁锁起来的东西。常用的非对称加密算法是 RSA 算法，想详细了解的同学点这里：RSA 算法详解一、RSA 算法详解二，其优缺点如下：

优点：算法公开，加密和解密使用不同的钥匙，私钥不需要通过网络进行传输，安全性很高。

缺点：计算量比较大，加密和解密速度相比对称加密慢很多。

由于非对称加密的强安全性，可以用它完美解决对称加密的密钥泄露问题，效果图如下：

在上述过程中，客户端在拿到服务器的公钥后，会生成一个随机码 (用 KEY 表示，这个 KEY 就是后续双方用于对称加密的密钥)，然后客户端使用公钥把 KEY 加密后再发送给服务器，服务器使用私钥将其解密，这样双方就有了同一个密钥 KEY，然后双方再使用 KEY 进行对称加密交互数据。在非对称加密传输 KEY 的过程中，即便第三方获取了公钥和加密后的 KEY，在没有私钥的情况下也无法破解 KEY (私钥存在服务器，泄露风险极小)，也就保证了接下来对称加密的数据安全。而上面这个流程图正是 HTTPS 的雏形，HTTPS 正好综合了这两种加密算法的优点，不仅保证了通信安全，还保证了数据传输效率。

HTTPS的连接实现

HTTPS的连接过程可以简单分为五步：

1. 客户端请求建立TLS连接
2. 服务端发回证书
3. 客户端验证服务器证书
4. 客户端信任服务器证书后和服务器协商对称秘钥
5. 使用对称秘钥开始通信

详细的流程如下：

1. 客户端发送一个字节的“Client Hello”请求连接服务器，另外还会附加客户端支持的TLS可选的版本集合、可选的加密套件（英文Cipher Suites 包括可选的对称加密算法、可选的非对称加密算法及可选的 Hash 算法）以及一个客户端随机数。
2. 服务端根据客户端发送的信息选取TLS版本、加密算法，然后向客户端发送一个字节的Server Hello，并附加选中的TLS版本、加密算法及一个服务端随机数。服务端和客户端协商成功后各自保都存了使用的TLS版本、加密套件，以及客户端随机数和服务端随机数。
3. 服务器将证书发送到客户端，证书中包含了
   • 服务器的公钥
   • 服务器公钥的签名，签名是用私钥对数据的Hash值进行非对称加密的计算得到的结果。这里加密的私钥是另选的一对，与服务器公钥没有关系。这个签名可以被加密时的私钥对应的公钥解开，这个公钥也是由证书签发机构提供的。但是，现在并不能确定这个证书签发机构提供的公钥是否可信，所以又对这个[公钥签名]的公钥用另一个公钥再次进行签名，最终可以追溯到系统内置的根证书中的公钥。系统中根证书是无条件被信任的。
   • 证书所属的主机名，客户端需要验证主机名是否是自己要访问的，防止中间人使用CA证书进行攻击。
4. 客户端收到后需要验证公钥的合法性后，会发送一个Pre-Master secret，这是一个使用服务器公钥加密后的随机数。
5. 服务端收到Pre-Master secret后用其私钥进行解密，并且客户端与服务端都会根据客户端随机数、服务端随机数以及这个Pre-Master secret来算出一个Master secret。这里的客户端随机数、服务端随机数每次都会重新生成，这样可以防止 replay attack。
6. 接着，客户端与服务端还会通过 Master secret生成客户端加密秘钥、服务端加密秘钥、客户端Mac Secret、服务端Mac Secret。
7. 客户端与服务端通过对称加密进行通信。客户端使用客户端秘钥加密数据发送到服务端，服务端接收到数据后使用客户端秘钥进行解密。接着服务端使用服务端秘钥对返回数据进行加密并返回到客户端，客户端使用服务端秘钥进行解密得到返回数据。

为什么要把服务端秘钥和客户端秘钥分开？

也是为了防止中间人攻击。如果客户端与服务端使用相同的秘钥，虽然中间人截取数据后无法解码数据，但可以原封不动的返回，而由于客户端与服务端秘钥相同，客户端并不能确定是自己法的数据还是服务端返回的数据。