在HTTP 协议中有可能存在信息窃听或身份伪装等安全问题。使用 HTTPS 通信机制可以有效地防止这些问题。
HTTPS 是建立在 SSL/TLS 协议之上的 HTTP。HTTPS 的本质就是在 HTTP 连接发起之前，先使用 SSL/TLS 协议，协调客户端和服务端，在两端各自生产一个对称加密算法的秘钥，然后使用普通的 HTTP 协议传输经过对称加密算法加密的网页内容。因为对称加密算法的秘钥是安全的，所以对称加密算法加密的网页内容也是安全的。
SSL/TLS用于在两个通信应用程序之间提供保密性和数据完整性。在采用SSL/TLS后，HTTP 就拥有了 HTTPS 的加密、证书和完整性保护这些功能。
HTTPS 四大金刚
HTTP + 加密 + 认证 + 完整性保护 = HTTPS
非对称加密算法(生成对称加密算法的秘钥) + 对称加密算法(生成加密内容) + 数字证书(防止篡改非对称加密算法的公钥) + HASH算法(防止篡改消息)== HTTPS
HTTPS 基本原理
HTTPS的整体过程分为证书验证和数据传输阶段，HTTPS 在内容传输的加密上使用的是对称加密，非对称加密只作用在证书验证阶段。具体的交互过程如下：
- 使用非对称加密算法来获得对称加密算法的秘钥，从而保证了对称加密算法的秘钥的安全，也就保证了对称加密算法的安全。
- 利用对称加密算法来加密网页内容；每一次对话（session），客户端和服务器端都生成一个”对话密钥”（session key），用它来加密信息。由于”对话密钥”是对称加密算法，所以运算速度非常快，而服务器公钥只用于加密”对话密钥”本身，这样就减少了加密运算的消耗时间。（也就是网页内容的加密使用的是对称加密算法）；
利用了对称加密算法速度快，而非对称加密算法安全的优点；同时巧妙的避免了对称加密算法的不安全性，以及需要同步密钥的缺点，也避免了非对称加密算法的速度慢的缺点。
为什么数据传输是用对称加密？
- 首先，非对称加密的加解密效率是非常低的，而 HTTP 的应用场景中通常端与端之间存在大量的交互，非对称加密的效率是无法接受的
- 另外，在 HTTPS 的场景中只有服务端保存了私钥，一对公私钥只能实现单向的加解密，所以 HTTPS 中内容传输加密采取的是对称加密，而不是非对称加密
如何保证非对称加密算法公钥不被篡改？
将公钥放在数字证书中。只要证书是可信的，公钥就是可信的。
SSL/TLS 协议的基本过程
- 客户端向服务器发出加密通信的请求。在这一步，客户端主要向服务器提供以下信息：
- 浏览器支持的
SSL/TLS协议版本，比如TLS 1.0版。 - 客户端生成的一个随机数，稍后用于生成对称加密算法的 「对话密钥」。
- 客户端支持的加密方法，对称的，非对称的，
HASH算法。比如RSA非对称加密算法，DES对称加密算法，SHA-1 hash算法。 - 客户端支持的压缩算法。
- 浏览器支持的
- 服务器响应包含的内容：
- 确认加密通信协议版本，比如
TLS 1.0版本。如果客户端与服务器支持的版本不一致，服务器关闭加密通信。 - 服务器生成的随机数，稍后用于生成对称加密算法的 「对话密钥」。
- 确认加密方法，比如：RSA 非对称加密算法，DES 对称加密算法，
SHA-1 hash算法； - 服务器证书
- 确认加密通信协议版本，比如
- 客户端验证非对称加密算法的公钥（证书）。 如果证书不是可信机构颁布、或者证书中的域名与实际域名不一致、或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。如果证书没有问题，客户端就会从证书中取出服务器的非对称加密算法的公钥。然后，向服务器发送下面三项信息：
- 一个随机数。该随机数用服务器发来的公钥使用非对称加密算法加密，防止被窃听。
- 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送(比如确认使用：RSA 非对称，DES 对称，SHA-1 hash算法)。
- 客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的
hash值，用来供服务器校验
- 双方协商生成对称加密算法的「对话密钥」。服务器收到第三个随机数
pre-master key之后，计算生成本次会话所用的对称加密算法的”会话密钥”。然后向客户端最后发送下面信息：- 编码改变通知，表示随后的信息都将用双方商定的对称加密算法和密钥进行加密。
- 服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时也是前面发送的所有内容的
hash值，用来供客户端校验。
- 整个握手阶段全部结束。
- 双方采用对称加密算法和它的 「对话密钥」 进行加密通信。就完全是使用普通的 HTTP 协议，只不过用 “会话密钥” 加密内容
注：
- 如果服务器需要确认客户端的身份，就会再包含一项请求，要求客户端提供 「客户端证书」。比如，金融机构往往只允许认证客户连入自己的网络，就会向正式客户提供 USB 密钥，里面就包含了一张客户端证书。
- 整个握手阶段出现的第三个随机数，又称
pre-master key。有了它以后，客户端和服务器就同时有了三个随机数，接着双方就用事先商定的对称加密算法，各自生成本次会话所用的同一把 “会话密钥”。也就是说浏览器和服务器各自使用同一个对称加密算法，对三个相同的随机数进行加密，获得了用来加密网页内容的 对称加密算法的秘钥。 - 客户端获得的三个随机数都是明文的，但是服务端获得的
pre-master key是密文的，所以服务器需要使用非对称加密算法的私钥，来先解密获得pre-master key的明文，在来生成对称加密算法的秘钥。这样的目的是为了防止：pre-master key被窃听，因为发送明文会被窃听，但是发生的是非对称加密算法的加密过后的密文，因为窃听者不知道私钥，所以即使窃听了，也无法解密出其对应的明文。从而保证了最后生成的：用于加密网页内容的对称加密算法的秘钥的安全性！
双向认证
SSL 双向认证相比于单向认证，多了一步服务端发送认证请求消息给客户端，客户端发送自签名的证书给服务端进行安全认证的过程。
自签名证书和第三方 CA 认证证书：
自签名证书：只能保证证书本身是完成且没有经过非法修改，但是没有办法保证这个证书的所有者。为了对自签名证书进行认证，需要每个客户端和服务端都交换自签名证书，对于一个大型网站或应用服务来说，工作量是巨大的。Jdk keytool 生成的数字证书是自签名的；
第三方 CA 证书：第三方 CA 证书颁发机构进行签名和验证的证书。浏览器中就保存了几个常用的 CA_ROOT ,每次连接到网站时，只要这个网站的证书是经过这些 CA_ROOT 签名过的，就可以验证通过了。
问：为什么一定要用三个随机数，来生成”会话密钥”？
不管是客户端还是服务器，都需要随机数，这样生成的密钥才不会每次都一样。由于 SSL 协议中证书是静态的，因此十分有必要引入一种随机因素来保证协商出来的密钥的随机性。
对于 RSA 密钥交换算法来说，pre-master-key 本身就是一个随机数，再加上 hello 消息中的随机，三个随机数通过一个密钥导出器最终导出一个对称密钥。
pre master 的存在在于 SSL 协议不信任每个主机都能产生完全随机的随机数，如果随机数不随机，那么 pre master-key 就有可能被猜出来，那么仅适用 pre master-key 作为密钥就不合适了，因此必须引入新的随机因素，那么客户端和服务器加上 pre master-key 三个随机数一同生成的密钥就不容易被猜出了，一个伪随机可能完全不随机，可是是三个伪随机就十分接近随机了，每增加一个自由度，随机性增加的 可不是一。”
