SSL/TLS

干啥的？ ：SSL（Secure Sockets Layer） 和 TLS（Transport Layer Security） 是一种用于在网络通信中提供安全性的协议。它们的主要目的是在客户端（如浏览器）和服务器之间建立加密连接，确保数据传输的安全性和隐私性。

SSL 是由 Netscape 开发的一种早期的安全协议，TLS 是 SSL 的继任者，修复了 SSL 中的许多安全漏洞。提供了更安全和高效的通信机制。
SSL有多个版本（SSL 1.0、2.0、3.0），但因安全性问题，SSL 3.0 及以下版本已被废弃。
TLS版本包括 TLS 1.0、1.1、1.2 和 1.3。当前推荐使用 TLS 1.2 或更高版本，因为它们提供了更好的安全性。

SSL/TLS工作原理的核心步骤

握手阶段（Handshake Protocol）

（1）客户端向服务器发送一个 ClientHello 消息，包含以下信息：
● 支持的 SSL/TLS 版本（如 TLS 1.2 或 TLS 1.3）。
● 支持的加密套件列表（Cipher Suites），包括加密算法和哈希算法。
● 客户端随机数（Client Random），用于后续密钥生成。
● 可选的扩展字段（如支持的压缩方法、ALPN 协议等）。

（2）服务器选择一个双方都支持的加密套件，并返回一个 ServerHello 消息，包含以下信息：
● 确定的 TLS 版本。
● 选定的加密套件。
● 随机数（Server Random），用于后续密钥生成。
● 可选的会话 ID（Session ID），用于会话恢复。

（3）服务器证书（Server Certificate）
服务器向客户端发送其数字证书，包含公钥和其他身份信息。

（4）客户端验证证书

（5）Server Key Exchange（可选）
如果选定的加密套件需要额外的密钥参数（如 Diffie-Hellman 参数），服务器会发送 Server Key Exchange 消息。

（6）Server Hello Done
服务器发送 Server Hello Done 消息，表示服务器已完成握手消息的发送。

（7）预主密钥交换（Key Exchange）

预主密钥（Pre-Master Secret）→ 主密钥（Master Secret）→ 会话密钥（Session Keys）
● 预主密钥的作用：作为初始的秘密值，提供一个随机且安全的变量因子生成主密钥。
● 主密钥的作用：作为中间密钥，提供更高的安全性和随机性扩展。
● 会话密钥的作用：实际用于数据加密和解密。
为啥不用预主密钥 直接生成 会话密钥，非要引入 主密钥呢？
1、增强安全性：预主密钥（Pre-Master Secret） + 客户端随机数（Client Random）+ 服务器随机数（Server Random）生成主密钥（Master Secret），增加了复杂性和不可预测性。
2、提供随机性扩展：预主密钥的长度通常是固定的（例如 48 字节），而主密钥可以通过 PRF 扩展为任意长度。
客户端随机数 + 服务器随机数 可以很容易被获取，生成主密钥为啥还用他？
虽然客户端随机数（Client Random）和服务器随机数（Server Random）在握手阶段会被明文传输，看似容易被获取，但它们在主密钥生成中的作用是不可替代的。
1、这些值本身是动态生成的，并且每次连接都会不同。这种动态性使得攻击者无法提前预测或重用之前的密钥生成过程。
2、客户端随机数和服务器随机数确保了每次连接的唯一性。如果攻击者试图重放之前的通信数据，新的随机数会使得生成的主密钥和会话密钥完全不同，从而阻止重放攻击。
3、支持前向安全性，即使长期密钥（如服务器私钥）被泄露，攻击者也无法推导出之前的主密钥和会话密钥。

常用密钥交换算法

● RSA 密钥交换
原理：客户端生成一个随机的预主密钥（Pre-Master Secret）。使用服务器的公钥（从证书中提取）加密预主密钥，并发送给服务器。服务器使用自己的私钥解密，获得预主密钥。
优点：实现简单，易于部署。
缺点：如果服务器私钥泄露，所有历史通信都可能被解密。
● Diffie-Hellman 密钥交换（DH 、ECDH、ECDHE）
Diffie-Hellman 加密协议介绍 （DH，DHE，ECDHE）

（8）生成会话密钥（Key Derivation）
● 计算主密钥（Master Secret）
预主密钥（Pre-Master Secret） + 客户端随机数（Client Random）+ 服务器随机数（Server Random），通过特定算法计算出主密钥（Master Secret）。

主密钥计算的位置
客户端 和 服务器 各自独立完成主密钥（Master Secret）的计算。
为什么不在一个地方计算？
安全性：如果主密钥只在一方计算，另一方需要通过网络接收主密钥，这会增加被窃听或篡改的风险。
如果不一致怎么办？
主密钥计算完成后，客户端和服务端会进一步使用主密钥派生出会话密钥，并用这些会话密钥加密后续的通信数据。如果主密钥不一致，生成的会话密钥会不同，加解密会出问题，从而检测到问题。

● 派生出会话密钥（Session Keys）
主密钥派生出其他秘钥
● 会话密钥 用于 数据加密
● MAC密钥 用于 完整性验证

（9）更改加密状态（ChangeCipherSpec）
ChangeCipherSpec 消息本身非常简单，只包含一个字节的数据。其值固定为 0x01，表示“切换加密模式”的指令。
客户端和服务器分别发送 ChangeCipherSpec 是用来通知对方 “我已经准备好使用我们协商好的加密算法和密钥进行加密通信了。”

SSL/TLS 协议规定：
● 如果 ChangeCipherSpec 消息在网络中丢失或乱序，TCP 层会自动重传或重新排序。
● 客户端必须先发送 ChangeCipherSpec 和 Finished 消息。服务器在接收到这些消息后，才会发送自己的 ChangeCipherSpec 和 Finished 消息。

1、客户端发送 ChangeCipherSpec
客户端完成密钥协商后，发送 ChangeCipherSpec 消息，表示将切换到加密状态。
2、客户端发送 Finished 消息
紧接着 ChangeCipherSpec，客户端发送加密的 Finished 消息。（Finished消息是第一个使用协商好的加密算法和会话密钥保护的消息）
3、服务器接收并处理
● 服务器接收到客户端的 ChangeCipherSpec 后，切换到加密状态。
● 服务器尝试解密客户端的 Finished 消息。如果解密成功且验证Finished消息成功，则说明：客户端已经完成了密钥协商且和服务端秘钥一致。且客户端发送了 ChangeCipherSpec 消息，并切换到了加密状态。
4、服务器发送 ChangeCipherSpec
服务器完成密钥协商后，发送 ChangeCipherSpec 消息给客户端，表示将切换到加密状态。
5、服务器发送 Finished 消息：
紧接着 ChangeCipherSpec，服务器发送加密的 Finished 消息。
6、客户端接收并处理：
● 客户端接收到服务器的 ChangeCipherSpec 后，切换到加密状态。
● 客户端尝试解密服务器的 Finished 消息。如果解密成功且验证Finished消息成功，则说明：服务器已经完成了密钥协商且和客户端秘钥一致。且服务端已经发送了 ChangeCipherSpec 消息，并切换到了加密状态。

服务器切换到加密状态的时机
第一次切换：当服务器接收到客户端的 ChangeCipherSpec 消息后，切换到加密状态以解密客户端的 Finished 消息。
第二次切换：当服务器发送自己的 ChangeCipherSpec 消息后，再次确认切换到加密状态以发送加密的 Finished 消息。
服务器的加密状态切换是双向的，既依赖于客户端的行为（接收到客户端的 ChangeCipherSpec），也依赖于自身的动作（发送自己的 ChangeCipherSpec）。这种设计确保了握手过程的安全性和一致性。
客户端切换到加密状态的时机
第一次切换：当客户端完成密钥协商后，发送自己的 ChangeCipherSpec 消息时，切换到加密状态以发送加密的 Finished 消息。
第二次切换：当客户端接收到服务器的 ChangeCipherSpec 消息后，再次确认切换到加密状态以解密服务器的加密消息。

如果一方没有收到对方的 ChangeCipherSpec 消息怎么办？
如果一方没有及时收到对方的 ChangeCipherSpec 消息，通常会有以下几种处理方式：
超时重传：如果一方在合理的时间内没有收到对方的 ChangeCipherSpec 消息，它可能会重新发送 ChangeCipherSpec 消息，或者触发握手超时机制，重新发起握手。
握手失败：如果多次重传后仍未收到对方的响应，握手将被视为失败，连接会被关闭。

（10）握手完成（Finished）
Finished 消息包含一个基于主密钥，标签，握手历史的哈希值，用于验证完整性，确保握手未被篡改。
● 标签是一个固定的字符串，客户端：“client finished”，服务器：“server finished”
● 握手消息（Handshake Messages）是指从 Client Hello 到 Change Cipher Spec 之间的所有握手消息的拼接内容。

具体流程
参考上文ChangeCipherSpec的流程，如果双方的 Finished 消息匹配，则握手成功，进入加密通信模式。

如何验证Finished消息?
1、客户端接收到服务器发送的 Finished 消息后，提取其中的 VerifyData。
2、客户端使用相同的 PRF 算法，结合（主密钥，标签，握手历史记录）重新计算 VerifyData：
3、如果客户端计算出的 VerifyData 与接收到的 VerifyData 一致，则说明：
● 服务器使用的主密钥正确。
● 握手过程中所有消息未被篡改。
同样地，服务器验证客户端的 Finished 消息也如上步骤。如果任一方的验证失败，握手将终止，连接会被关闭。

加密通信阶段（Encrypted Communication Phase）

（1）对称加密
使用握手阶段生成的会话密钥（Session Key）对数据进行加密和解密。常见的对称加密算法包括 AES、ChaCha20 等。对称加密算法（如 AES）效率高，适合大规模数据传输。
（2）消息认证码（MAC）
每条消息都附带一个 MAC（Message Authentication Code），用于确保数据的完整性。
（3）重新协商（可选）
如果客户端和服务器希望在未来的连接中快速恢复会话，可以使用会话 ID 或会话票据（Session Ticket）机制。
会话恢复避免了重新执行完整的握手过程，从而提高了性能。

会话恢复（Session Resumption）

为了提高效率，SSL/TLS 提供了会话恢复机制，避免每次连接都重新进行完整的握手。
（1）会话 ID
在握手阶段，服务器分配一个唯一的会话 ID。
客户端可以在后续连接中使用该会话 ID 来恢复之前的会话。
（2）会话票据（Session Ticket）
服务器可以将加密的会话状态存储在客户端（称为会话票据）。
客户端在后续连接中提交会话票据以恢复会话。

---

SSH

Secure Shell Protocol（安全外壳协议），SSH 可以创建一个加密的“隧道”，将其他非加密协议（如 HTTP、SMTP）封装在其中，确保数据传输的安全性。

SSH 加密机制的核心步骤

1）建立 TCP 连接
客户端与服务器通过 TCP 协议建立初始连接。这是所有后续通信的基础。

2）版本协商
双方交换 SSH 协议版本信息（如 SSH-2.0），确保双方使用相同的协议版本。

3）算法协商
客户端和服务器协商以下参数：
● 密钥交换算法： 如 Diffie-Hellman（DH）、ECDH 等。
● 加密算法： 如 AES、ChaCha20 等。
● MAC 算法： 如 HMAC-SHA256 等。
● 压缩算法： 如 zlib 等。

4）密钥交换
（1）生成共享密钥
使用 DH 或 ECDH 算法进行密钥交换。双方基于公钥密码学生成一个共享的秘密值（Shared Secret）。
（2）计算会话密钥
根据共享的秘密值、交换的随机数以及其他参数，派生出会话密钥（Session Key）。会话密钥用于后续的对称加密通信。

如何验证共享秘密的一致性？
1、共享秘密被用来派生出会话密钥，如果双方能够成功解密对方的消息，则说明共享秘密一致。（这条能说明不能解密那么他们肯定是不一致的，但是能解密不一定就代表是一致的，因为不一定保证解密内容是对的的）
2、消息认证码（MAC）：每条消息附带一个 MAC 值，用于验证消息的完整性和共享秘密的一致性。（MAC能保证解密内容也是对的，结合第一条，既能解密，解密内容又是对的，这样就保证了共享秘密一定是一致的）

4）客户端验证服务器的身份
1、服务器向客户端发送自己的公钥证书（通常是基于 RSA 或 ECDSA 的公钥）。
2、客户端验证服务器的公钥是否可信（通常通过 CA 或本地信任存储）。
3、如果验证失败，连接将被终止。

5）客户端向服务器证明自己的身份
● 密码认证： 用户输入密码，服务器验证密码是否正确。
● 公钥认证：
1、服务器生成一段随机数据（挑战数据），并将其发送给客户端。
2、客户端收到挑战数据后，用自己的私钥对这段数据进行签名。
3、客户端将签名发送回服务器。
4、服务器用客户端的公钥（私钥保存在客户端，公钥上传到服务器，这就是我们平时配置的公钥）解密签名，得到原始的哈希值。服务器重新计算挑战数据的哈希值，并与解密后的哈希值进行比较。如果两者一致，则证明签名有效，客户端身份验证成功。如果不一致，则验证失败。

为什么需要挑战数据？
防止重放攻击：每次认证过程中的数据都是唯一的，攻击者无法通过重放旧的签名来通过认证。
验证私钥持有者：只有拥有对应私钥的客户端才能生成有效的签名，从而证明自己是合法用户。

● 其他方式： 如键盘交互认证、GSSAPI 认证，单点登录（SSO）等。

6）加密通信
客户端和服务器开始使用协商好的对称加密算法和共享的秘钥（session key）加密所有后续通信。
具体包括：
● 数据加密： 所有传输的数据都经过对称加密，确保机密性。
● 消息认证： 每条消息都附带 MAC（消息认证码），确保数据的完整性和防止篡改。
● 序列号： 每条消息都有唯一的序列号，防止重放攻击。

SSH优点
● 安全性高，适合私有数据的传输。
● 提供灵活的身份验证方式。
● 支持双向通信（既可读取也可写入）。

SSH缺点
● 配置较复杂（私钥保存在客户端，公钥上传到服务器）。
● 可能受防火墙限制（需要开放 SSH 端口，默认为 22）。

SSH使用场景
1、远程登录：系统管理员可以通过 SSH 登录到远程服务器，执行各种管理任务。 主要因为：SSH确保在客户端与服务器之间传输的所有数据（包括登录凭据、命令和输出）都经过加密。即使网络环境不安全（如公共 Wi-Fi），也能保证通信的安全。
2、文件传输：SSH 提供了基于其加密通道的文件传输协议（SFTP），可以安全地上传或下载文件。 主要因为：和1原因一致。
3、SSH 支持端口转发功能 ： 主要因为：SSH 协议本身提供了一个安全的加密通道，所有通过该通道传输的数据都会被加密。当使用端口转发时，SSH 将其他协议的流量（如 HTTP、SMTP）封装到其加密通道中进行传输。这种加密机制确保了转发的流量在传输过程中不会被窃听或篡改。

SSH 和 SSL 区别

使用用途
SSH 直接绑定到特定的应用场景（如远程登录、文件传输），而 SSL/TLS 是一个通用的中间层协议，可以封装任意应用层协议。用于保护应用层协议数据传输安全性。广泛应用于HTTPS、电子邮件（SMTP、IMAP、POP3）、文件传输（FTPS）等场景。

什么是命令行访问？
命令行访问是指用户通过终端或命令行界面与远程服务器进行交互。
SSH 如何实现安全的命令行访问？
SSH 自身的安全性
什么是加密通信通道？
加密通信通道是指在客户端和服务器之间建立一个专用的、加密的连接。所有通过该通道传输的数据都会被加密，防止被第三方窃听或篡改。

握手过程
SSL/TLS 主要面向服务器级认证（基于 X.509 证书），SSH 的身份验证机制主要面向用户级认证（如公钥或密码）。
SSL/TLS 的核心步骤并不强制要求验证客户端身份，而是根据实际场景灵活选择是否启用双向认证。SSH 的核心步骤要求验证客户端身份。

SSL/TLS：
使用证书机制验证服务器身份。
密钥交换算法包括 RSA、DH、ECDH 等。
握手完成后进入加密通信阶段。

SSH：
使用证书机制验证服务器身份。
密钥交换算法包括 DH 或 ECDH 。
支持多种用户身份验证方式（如密码、公钥、键盘交互）。
在握手完成后进入加密通信阶段。

记录层协议
SSL/TLS：记录层协议复杂，支持多种内容类型（如应用数据、警报、握手消息）。能够封装任意应用层协议。
SSH：记录层协议简单，主要用于传输加密数据和 MAC 值。不区分不同的应用层协议。

性能和优化方向的不同
SSL/TLS：更注重大规模数据传输的性能优化。支持会话恢复（Session Resumption）以减少握手开销。
SSH：更注重交互式会话的性能优化。支持压缩功能以提高传输效率。