一、混合加密
通过混合加密的方式可以保证信息的机密性，解决了窃听的风险。
HTTPS采用的是对称加密和非对称加密结合的混合加密方式：
（1） 在通信建立前采用非对称加密的方式交换会话密钥，后续就不再使用非对称加密。
（2）在通信过程中全部使用对称加密的会话密钥的方式加密明文数据。
采用混合加密方式的原因：
对称加密只使用一个密钥，运算速度快，密钥必须保密，无法做到安全的密钥交换。
非对称加密使用两个密钥：公钥和私钥，公钥可以任意分发而私钥保密，解决了密钥交换问题但速度慢。
二、摘要算法+数字签名
为了保证传输的内容不被篡改，我们需要对内容计算出一个指纹，然后同内容一起传输给对方。对方收到后，先是对内容也计算出一个指纹，然后跟发送方发送的指纹做一个比较，如果指纹相同，说明内容没有被篡改，否则就可以判断出内容被篡改了。
那么，在计算机里会用摘要算法（哈希函数）来计算出内容的哈希值，也就是内容的指纹，这个哈希值是唯一的，且无法通过哈希值推导出内容。
通过哈希算法可以确保内容不会被篡改，但是并不能保证内容+哈希值不会被中间人替换，因为这里缺少对客户端收到的消息是否来源于服务端的证明。
那么为了避免这种情况，计算机里会用非对称加密算法来解决，共有两个密钥：
（1）一个是公钥，这个是可以公开给所有人的；
（2）一个是私钥，这个必须由本人管理，不可泄露。
这两个密钥可以双向加解密的，比如可以用公钥加密内容，然后用私钥解密，也可以用私钥加密内容，公钥解密内容。
流程的不同，意味着目的也不同：
（1）公钥加密，私钥解密。这个目的是为了保证内容传输的安全，因为被公钥加密的内容，其他人是无法解密的，只有持有私钥的人，才能解密出实际的内容；
（2）私钥加密，公钥解密。这个目的是为了保证消息不会被冒充，因为私钥是不可泄露的，如果公钥能正常解密出私钥加密的内容就能证明这个消息是来源于持有私钥身份的人发送的。
一般我们不会用非对称加密来加密实际的传输内容，因为非对称加密的计算比较耗费性能。
所以非对称加密的用途主要在于通过私钥加密，公钥解密的方式，来确认消息的身份，我们常说的数字签名算法，就是用的这种方式。
三、数字证书
通过数字证书的方式保证服务器公钥的身份，解决冒充的风险。
四、HTTPS是如何建立连接的？期间交互了什么？
1、SSL/TLS协议基本流程：
（1）客户端向服务器索要并验证服务器的公钥。
（2）双方协商生产会话密钥。
（3）双方采用会话密钥进行加密通信。
前两步就是SSL/TLS的建立过程，也就是TLS握手阶段。
TLS 协议建⽴的详细流程：
- ClientHello
⾸先，由客户端向服务器发起加密通信请求，也就是 ClientHello 请求。
在这⼀步，客户端主要向服务器发送以下信息：
（1）客户端⽀持的 TLS 协议版本，如 TLS 1.2 版本。
（2）客户端⽣产的随机数（Client Random），后⾯⽤于⽣成「会话秘钥」条件之⼀。
（3）客户端⽀持的密码套件列表，如 RSA 加密算法。
- SeverHello
服务器收到客户端请求后，向客户端发出响应，也就是 SeverHello。服务器回应的内容有如下内容：
（1）确认 TLS 协议版本，如果浏览器不⽀持，则关闭加密通信。
（2）服务器⽣产的随机数（Server Random），也是后⾯⽤于⽣产「会话秘钥」条件之⼀。
（3）确认的密码套件列表，如 RSA 加密算法。
（4）服务器的数字证书。
3.客户端回应
客户端收到服务器的回应之后，⾸先通过浏览器或者操作系统中的 CA 公钥，确认服务器的数字证书的真实性。
如果证书没有问题，客户端会从数字证书中取出服务器的公钥，然后使⽤它加密报⽂，向服务器发送如下信息：
（1）⼀个随机数（ pre-master key ）。该随机数会被服务器公钥加密。
（2）加密通信算法改变通知，表示随后的信息都将⽤「会话秘钥」加密通信。
（3）客户端握⼿结束通知，表示客户端的握⼿阶段已经结束。这⼀项同时把之前所有内容的发⽣的数据做 个摘要，⽤来供服务端校验。
上⾯第⼀项的随机数是整个握⼿阶段的第三个随机数，会发给服务端，所以这个随机数客户端和服务端都 是⼀样的。
- 服务器的最后回应
服务器收到客户端的第三个随机数（ pre-master key ）之后，通过协商的加密算法，计算出本次通信的 「会话秘钥」。
然后，向客户端发送最后的信息：
（1）加密通信算法改变通知，表示随后的信息都将⽤「会话秘钥」加密通信。
（2）服务器握⼿结束通知，表示服务器的握⼿阶段已经结束。这⼀项同时把之前所有内容的发⽣的数据做 个摘要，⽤来供客户端校验。
⾄此，整个 TLS 的握⼿阶段全部结束。接下来，客户端与服务器进⼊加密通信，就完全是使⽤普通的 HTTP 协议，只不过⽤「会话秘钥」加密内容。