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