什么是 HTTPS？它是如何解决安全性问题的？

什么是 HTTPS？

HTTPS（HyperText Transfer Protocol Secure）是一种安全的通信协议，用于在计算机网络上安全地传输超文本（如网页、图像、视频等）和其他数据。它是 HTTP 协议的安全版本，通过使用加密技术来保护通信的安全性和隐私性。

HTTP 是超文本传输协议，信息是明文传输，存在安全风险的问题。HTTPS 则解决 HTTP 不安全的缺陷，在 TCP 和 HTTP 网络层之间加入了 SSL/TLS 安全协议，使得报文能够加密传输。HTTPS 在 TCP 三次握手之后，还需进行 SSL/TLS 的握手过程，才可进入加密报文传输。

HTTPS 解决了 HTTP 哪些问题？

HTTP 由于是明文传输，所以安全上存在以下三个风险：

1. 可以通过抓包获取用户的私密信息
2. 伪造服务器发送信息，骗取钱财
3. 可以对报文进行篡改

HTTPS 在 HTTP 与 TCP 层之间加入了 SSL/TLS 协议，可以很好的解决了上述的风险：

• 信息加密：交互信息无法被窃取。
• 校验机制：无法篡改通信内容，篡改了就不能正常显示。
• 身份证书：证明服务器的可靠性。

HTTPS 是如何解决上面的三个风险的？

• 混合加密的方式实现信息的机密性，解决了窃听的风险。
• 摘要算法的方式来实现完整性，它能够为数据生成独一无二的「指纹」，指纹用于校验数据的完整性，解决了篡改的风险。
• 将服务器公钥放入到数字证书中，解决了冒充的风险。

1. 对称加密和非对称加密

在正式开始讲解加密的方式之前，这里对「对称加密」和「非对称加密」做一些补充：

对称加密，双方持有相同的密钥，加密和解密都是使用这个密钥

非对称加密，服务器持有私钥，而向客户端去分发公钥，这两个密钥可以双向加解密的，比如可以用公钥加密内容，然后用私钥解密，也可以用私钥加密内容，公钥解密内容。

非对称加密算法常常用于**「私钥加密，公钥解密」的方式**来验证 消息发送者 的方式，比如常见的数字签名算法，采用的就是这种方式，大致流程是这样的：

1. 发送方使用自己的私钥对消息的摘要进行加密，生成数字签名
2. 发送方将原始消息和数字签名一起发送给接收方，
3. 接收方使用发送方的公钥对数字签名进行解密，得到消息的摘要或哈希值。
4. 接收方使用相同的哈希函数对收到的消息进行摘要处理，生成一个新的消息摘要。
5. 接收方将生成的本地摘要与解密得到的摘要进行比较，以验证消息的完整性和真实性。

2. 混合加密

HTTPS 首先解决的是交互信息被窃取的问题，即本次会话中发送的所有消息 只有 双方能够解读。

HTTPS 采用的是 对称加密 + 非对称加密 的混合方法来加密双方的通信。

为什么要采用混合加密的方法呢？无论使用哪种方法，双方都要去 互通 密钥，既然有这个互通的环节，那这个消息就有可能被拦截，带来了伪造消息等风险。

所以所以要保证 正式对话 的时候使用的密钥是加密传递的。

1. 当客户端向服务器发送信息的时候，服务器会发送一个可以证明自己身份的 数字证书，客户端可以从合法的数字证书中拿到 公钥，用户接收到数字证书之后，就会先去验证证书的有效性。
2. 验证成功后，客户端就可以信任服务器的身份；随后，客户端生成一个随机的会话密钥，并使用服务器发送的公钥对会话密钥进行加密。
3. 客户端发送这个会话密钥给服务器，服务器收到客户端发送的加密后的会话密钥后，使用私钥解密会话密钥。
4. 客户端和服务器使用已经建立的会话密钥来加密和解密传输的数据，建立安全的通信通道。
5. 在建立了安全通信通道后，后续的通信都将使用会话密钥进行加密和解密，保证通信的安全性和隐私性。

如果对公钥理解不深的话，很可能会有这样的疑问：如果公钥被拦截，那我不就可以假装这个用户给服务器发信息了吗？

实际上，公钥只是建立安全链接的方式，并不代表用户的信息，客户端的身份验证通常是在建立安全连接之后的一个步骤，通过额外的验证机制来完成。这些机制可能包括使用用户名和密码进行身份验证、使用客户端证书进行身份验证等。

也就是拿到了公钥其实就是拿到给服务器建立连接的机会，意义并不大。

3. 数字证书

实现客户端和服务器之间通信只有双方能解密，但有没有可能这个服务器本身就是伪造的呢？

我给一个假的服务器唰唰唰把我的个人信息都发过去了，造成的危害就极大了。

其实要解决这个问题也很简单，就是服务器要有证明自己身份的证书，这个证书证明了它是一个合法合规的服务器，如果使用这种服务器做一些违法的事情，根据注册信息来溯源也会非常简单；客户端可以根据这个证书来验证服务器的可靠性，拿到数字证书，验证完之后，客户端就知道这个服务器靠谱，可以发送信息了。

每个证书背后都要有一个权威的机构，数字证书也不例外，在计算机里，这个权威的机构就是 CA （数字证书认证机构），注册 CA 证书需要如下的信息：

1. 证书持有者的身份信息：包括姓名、组织名称（如果是组织）、电子邮件地址等。这些信息将包含在数字证书的主体字段中。
2. 证书的密钥对：包括公钥和私钥。公钥将包含在数字证书中，而私钥将被持有者用于加密和解密通信。
3. 证书使用的目的：例如身份验证、数据加密等。
4. 证书颁发机构（CA）的选择：证书可以由公共 CA（如 Let’s Encrypt、DigiCert 等）或私有 CA（组织内部的 CA）签发。
5. 证书有效期：指定证书的开始日期和到期日期。证书在到期日期之后将不再被认为是有效的。
6. 其他可选信息：根据实际需求，可能需要提供其他信息，例如组织的注册号码、地址、电话号码等。

那还有个问题，数字证书能否被伪造呢？只要拿到上面的部分信息就可以伪造了，那来看看哪些情况我们可以伪造证书（笑）：

1. 私钥泄露：如果证书持有者的私钥被泄露，攻击者可以使用该私钥签发伪造的数字证书。
2. 证书颁发机构（CA）被攻击：如果攻击者能够入侵或操纵证书颁发机构（CA），他们可以签发伪造的数字证书。这种攻击可能包括对 CA 基础设施的入侵、社会工程攻击或其他形式的欺诈。
3. 中间人攻击：攻击者可以在客户端和服务器之间插入自己的数字证书，从而模拟客户端与服务器之间的通信。这种攻击称为中间人攻击，通常用于窃听或篡改通信。

好像没有哪个是好实现的，而且还不一定有效，所以数字证书可以极大的保证通信的安全性。
4. 数字证书的签发和验证

证书签发流程：

1. 证书申请：证书的申请者（通常是服务器管理员或个人）向证书颁发机构（CA）提交证书申请。申请通常包括证书持有者的身份信息、公钥等。
2. 身份验证：CA 对证书申请者进行身份验证，以确保申请者的身份信息是真实的和可信的。身份验证通常包括验证申请者的身份证明文件、组织信息等。
3. 生成密钥对：如果身份验证通过，CA 会生成证书持有者的密钥对，包括公钥和私钥。私钥将由证书持有者保密，而公钥将包含在证书中。
4. 生成证书请求（CSR）：证书持有者生成一个包含公钥和身份信息的证书请求（Certificate Signing Request，CSR），并将其发送给 CA。
5. 证书签发：CA 收到 CSR 后，会对其进行验证，确认证书持有者的身份和公钥信息。如果一切正常，CA 将使用自己的私钥对证书请求进行签名，生成数字证书。
6. 数字证书颁发：CA 将签发的数字证书发送回给证书持有者，数字证书包含了证书持有者的公钥、身份信息、证书有效期等。

数字证书的有效期结束后，需要再次申请并获取新的数字证书，以保持通信的安全性和有效性。

证书验证流程：

1. 接收数字证书：验证者（如客户端）从通信对方（如服务器）处接收到数字证书。
2. 验证证书链：验证者首先检查数字证书是否由受信任的 CA 签发。如果证书是由受信任的 CA 签发的，则证书被认为是可信的。否则，验证者会继续验证证书链，直到找到根证书为止。
3. 验证证书的有效期：验证者检查数字证书的有效期，确保当前日期在证书的有效期内。
4. 验证证书的吊销状态：验证者检查证书是否被吊销。这可以通过证书吊销列表（CRL）或在线证书状态协议（OCSP）来实现。
5. 验证数字签名：验证者使用颁发 CA 的公钥来验证数字证书的数字签名。如果签名有效，则可以确信证书内容没有被篡改。
6. 可选的附加验证：根据实际需要，验证者可能会进行其他验证，例如验证证书中的主体信息是否与通信方匹配，或者额外的验证证书中包含的其他信息。

签发证书的时候，CA 使用签名加密的其实是通过证书信息生成的哈希值，作为一个签名使用，而不是加密整个证书，用户通过公钥对签名解密，再去进行验证就可以保证 证书没有被篡改过。

然后用户对证书的验证其实是一个信任链的过程，即 根证书 => 中间证书 => 实际的证书，证书的签发通常不是由根证书签发的，而是借助中间的证书，客户端在验证的时候只需要查询中间证书是否信任本次发送的证书即可。

当用户收到一个证书的时候，先去检测它的上层的证书是哪个，直到请求到根证书，而用户会持有一个根证书清单，请求到根证书后回去验证证书是否在这个清单上。

然后再去检测根证书是否信任下层的证书，逐次检查直到检查到服务器发送来的证书，这样就能验证证书的有效性了。