张今灵整理

应用层基础

ssh工作原理

参考

SSH的加密原理中，使用了RSA非对称加密算法。 整个过程是这样的： （1）远程主机收到用户的登录请求，把自己的公钥发给用户。 （2）用户使用这个公钥，将登录密码加密后，发送回来。 （3）远程主机用自己的私钥，解密登录密码，如果密码正确，就同意用户登录。

中间人攻击

SSH之所以能够保证安全，原因在于它采用了公钥加密，这个过程本身是安全的，但是实际用的时候存在一个风险：如果有人截获了登录请求，然后冒充远程主机，将伪造的公钥发给用户，那么用户很难辨别真伪。因为不像https协议，SSH协议的公钥是没有证书中心（CA）公证的，是自己签发的。

如果攻击者插在用户与远程主机之间（比如在公共的wifi区域），用伪造的公钥，获取用户的登录密码。再用这个密码登录远程主机，那么SSH的安全机制就不存在了。这种风险就是著名的”中间人攻击”（Man-in-the-middle attack）。那么SSH协议是怎样应对的呢？

用户需确认：客户端通常会提示用户确认这个公钥是否可信，用户需手动确认。

后续每次连接时，SSH 客户端会检查 ~/.ssh/known_hosts 文件中的记录，验证远程主机的公钥是否匹配。这种机制通过主机密钥的比对，可以有效防止中间人攻击。

公钥登录

把客户端端公钥手动保存在服务端。登录的时候，远程主机会向用户发送一段随机字符串，用户用自己的私钥加密后，再发回来。远程主机用事先储存的公钥进行解密，如果成功，就证明用户是可信的，直接允许登录shell，不再要求密码。

也就是数字签名。

DNS

dns是udp的，特别大的才会用tcp

dhcp是udp的

为什么DNS不用TCP?

无论是选择 UDP 还是 TCP，最核心的矛盾就在于需要传输的数据包大小，如果数据包小到一定程度，UDP 协议绝对最佳的选择。

当数据包大到一定程度，tcp握手等额外开销变得无足轻重时，自然是选择更可靠的tcp。

DNS 的解析过程

• 浏览器缓存
• 本地DNS服务器
• 根服务器
• 顶级域名服务器

httpDns

HTTPDNS使用HTTP与DNS服务器交互，代替传统的基于UDP的DNS协议，域名解析请求直接发送到HTTPDNS服务端，从而绕过运营商的Local DNS

• 传统的DNS有解析慢，更新不及时，转发跨运营商，nat跨运营商等问题，影响了流量的调度。
• HTTPDNS通过客户端sdk和服务端，直接解析dns，绕过了传统dns缺点，实现智能调度，同时从根本避免了劫持问题。

这个解释好些

参考

DNS 劫持即域名劫持，是通过将原域名对应的 IP 地址进行替换，从而使用户访问到错误的网站，或者使用户无法正常访问网站的一种攻击方式。

怎么应对 DNS 劫持？

• 直接通过 IP 地址访问网站，避开 DNS 劫持
• 由于域名劫持往往只能在特定的网络范围内进行，因此一些高级用户可以通过网络设置让 DNS 指向正常的域名服务器以实现对目标网址的正常访问，例如计算机首选 DNS 服务器的地址固定为 8.8.8.8。

Https

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

• 窃听风险，比如通信链路上可以获取通信内容，用户号容易没。
• 篡改风险，比如强制入垃圾广告，视觉污染，用户眼容易瞎。
• 冒充风险，比如冒充淘宝网站，用户钱容易没。

解决： 加密、认证、防篡改

HTTPS 在 HTTP 与 TCP 层之间加入了 SSL/TLS 协议。

可以很好的解决了上述的风险：

• 信息加密：交互信息无法被窃取，但你的号会因为「自身忘记」账号而没。
• 校验机制：无法篡改通信内容，篡改了就不能正常显示，但百度「竞价排名」依然可以搜索垃圾广告。
• 身份证书：证明淘宝是真的淘宝网，但你的钱还是会因为「剁手」而没。

HTTPS 解决方案

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

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

HTTPS 采用的是对称加密和非对称加密结合的「混合加密」方式：

• 在通信建立前采用非对称加密的方式交换「会话秘钥」，后续就不再使用非对称加密。
• 在通信过程中全部使用对称加密的「会话秘钥」的方式加密明文数据。

TLS 1.2

SSL/TLS 协议基本流程：

• 客户端向服务器索要并验证服务器的公钥。
• 双方协商生产「会话秘钥」。
• 双方采用「会话秘钥」进行加密通信。

其实就是客户端请求服务端拿到公钥，和证书里公钥比对，成功则继续。这轮请求应答可以交换自己的一个随机字符串，记录A，B

客户端用这个公钥加密个字符串C到服务端。

现在客户端、服务端都有了ABC，然后共同算法生成对称密钥key。

HTTPS、SSL、TLS三者之间的联系和区别

• SSL 是早期的加密协议，已经被认为不安全，逐渐被 TLS 替代。
• TLS 是 SSL 的改进版，提供更强的安全性和性能。
• HTTPS 是 HTTP 的加密版本，通过 SSL/TLS 协议确保通信的机密性、完整性和身份认证。

握手是两个来回

TLS 1.3

以上是TLS 1.2的握手过程，现在新出了TLS 1.3

ECDHE（Elliptic Curve Diffie-Hellman Ephemeral）是一种基于椭圆曲线的 临时 Diffie-Hellman（DH）密钥交换协议，用于安全地在两个通信方之间建立共享密钥，同时提供 前向安全性（Forward Secrecy）（每次会话使用 **新的临时密钥对，即使黑客获取服务器私钥，也无法解密过去的通信数据。）**。

• 服务器和客户端各自生成一个随机的私钥（私钥不能泄露）。
• 使用椭圆曲线算法计算对应的公钥，然后交换公钥。
• 双方使用对方的公钥和自己的私钥计算共享密钥（因为 ECC 满足交换性质，所以计算出的密钥相同）。
• 使用该共享密钥进行对称加密通信（如 AES）。

会话恢复

TLS 1.2 和 TLS 1.3 在会话恢复（Session Resumption）机制上存在显著不同。TLS 1.3 引入了 Pre-Shared Key (PSK) 和 0-RTT，相比 TLS 1.2 提高了效率和安全性。

TLS 1.2 有两种主要的会话恢复机制：

1. Session ID（基于服务器端存储）

   • 客户端和服务器在 TLS 握手时协商一个 Session ID。

   • 服务器会在本地存储会话数据（如主密钥）。

   • 客户端下次连接时，发送之前的 Session ID，服务器检查其缓存：
     • 如果找到：握手变为 1-RTT，直接恢复加密连接。
     • 如果未找到：执行完整 TLS 1.2 握手。

   • 缺点

     • 服务器必须维护会话缓存，影响可扩展性（不适用于大型分布式系统）。
     • 服务器重启后，所有会话失效。

2. Session Ticket（基于客户端存储）

   • 服务器在握手结束时，使用 NewSessionTicket 发送一个 Session Ticket 给客户端。
   • 该 Ticket 由服务器 加密存储会话信息，客户端无需了解内部内容，只需在下次连接时提供它。
   • 服务器通过解密 Session Ticket 恢复会话。
   • 缺点
     • 前向安全性问题：如果攻击者获取服务器的 Ticket 加密密钥，就可以解密所有会话。
     • 无状态会话恢复：服务器无需存储会话信息，适合大规模部署（如 CDN）。

TLS 1.3 移除了 Session ID 和旧的 Session Ticket 机制，统一使用 Pre-Shared Key (PSK) 和 0-RTT（可选），具有更高的安全性和性能优化。

1. Pre-Shared Key (PSK)

• 客户端和服务器在首次 TLS 1.3 握手时，服务器会发送 NewSessionTicket。

• 客户端保存这个 Session Ticket（它实际上就是一个 PSK）。

• 下次连接时，客户端在

  ClientHello
  

  中发送：

  • 该 PSK（Session Ticket）
  • 用于密钥交换的 Key Share

• 服务器检查 Ticket 是否有效：

  • 如果有效，则使用 PSK 恢复会话，并进行 1-RTT 连接（仍需 Finished 验证）。
  • 如果无效，执行完整 TLS 1.3 握手。

改进点：

• 前向安全性增强：每次恢复会话时，PSK 都会结合新的 ECDHE 密钥交换 生成新的密钥。
• 支持多个 Session Ticket：服务器可以在 NewSessionTicket 发送多个 Ticket，允许客户端选择最优的 PSK。

2. 0-RTT（Zero Round Trip Time）

• 客户端如果 使用缓存的 PSK 并支持 0-RTT，可以在 ClientHello 时直接发送 加密的应用层数据（如 HTTP 请求）。
• 服务器可以立即处理这些数据，而不需要等待完整的握手完成。

优点：

• 0-RTT 大幅减少延迟，适合低延迟应用（如 HTTPS/QUIC）。
• 可以与 TLS 1.3 PSK 机制结合，提高安全性。

缺点：

• 可能遭受重放攻击（Replay Attack），攻击者可以重发 0-RTT 请求导致意外重复交易。
• 解决方案：
  • 服务器仅允许幂等操作（如 GET 请求）。
  • 服务器使用 Anti-Replay 机制（如时间窗口、唯一标识）。

TLS 1.2 vs TLS 1.3 会话恢复对比

延迟对比

• TCP 握手，我们熟悉的 TCP 三次握手需要需要 1 个 RTT；因为第三次可以发送数据

• TLS 握手，以目前应用最广泛的 TLS 1.2 而言，需要 2 个 RTT。对于非首次建连，可以选择启用会话重用，则可缩小握手时间到 1 个 RTT
• HTTP 业务数据交互，假设 abc.com 的数据在一次交互就能取回来。那么业务数据的交互需要 1 个 RTT；经过上面的过程分析可知，要完成一次简短的 HTTPS 业务数据交互，需要经历：新连接 4RTT + DNS；会话重用 3RTT + DNS。

下图对比了 TLS 各版本与场景下的延时对比：

认证

通过使用 证书 来对通信方进行认证。

数字证书认证机构（CA，Certificate Authority）是客户端与服务器双方都可信赖的第三方机构。

服务器的运营人员向 CA 提出公开密钥的申请，CA 在判明提出申请者的身份之后，会对已申请的公开密钥做数字签名，然后分配这个已签名的公开密钥，并将该公开密钥放入公开密钥证书后绑定在一起。

进行 HTTPS 通信时，服务器会把证书发送给客户端。客户端取得其中的公开密钥之后，先使用数字签名进行验证，如果验证通过，就可以开始通信了。

完整性保护

SSL 提供报文摘要功能来进行完整性保护。

HTTP 也提供了 MD5 报文摘要功能，但不是安全的。例如报文内容被篡改之后，同时重新计算 MD5 的值，通信接收方是无法意识到发生了篡改。

HTTPS 的报文摘要功能之所以安全，是因为它结合了加密和认证这两个操作。试想一下，加密之后的报文，遭到篡改之后，也很难重新计算报文摘要，因为无法轻易获取明文。

HTTPS 的缺点

• 因为需要进行加密解密等过程，因此速度会更慢；

• 需要支付证书授权的高额费用。

Https QA

https就绝对安全了嘛

在用户未知情情况下是安全的，但部分场景是保证不了的。假如用户对中间人进行授权信任。

在客户端授权的情况下，可以组建中间人网络，而抓包工具便是作为中间人的代理。通常，HTTPS抓包工具会生成一个证书(类比的假证书)，用户安装在客户端或添加信任。此时，客户端先与抓包工具通信，抓包工具再将请求转发到服务器，服务器返回的信息，抓包工具可进行处理或输出，然后再返回给客户端。

另一方面，本地随机数可能被窃取，窃取后安全也是保证不了的。

HTTPS 会加密 URL 吗？

HTTPS 通过 SSL/TLS 协议确保了客户端与服务器之间交换的数据被加密，这包括 HTTP 头部和正文。

而 URL 是 HTTP 头部的一部分，因此这部分信息也是加密的。

但因为涉及到 SSL 握手的过程，所以域名信息会被暴露出来，需要注意。另外，完整的 URL 可能在 Web 服务器的日志中记录，这些日志可能是明文的。还有，URL 在浏览器历史记录中也是可见的。

HTTPS怎么保证建立的信道是安全的？

主要通过 SSL/TLS 协议的多层次安全机制，首先在握手阶段，客户端和服务器使用得是非对称加密，生成的会话密钥只有服务器的私钥才能解密，而私钥只有服务器持有。

在数据传输阶段，即使攻击者拦截了通信数据，没有会话密钥也无法解密。

HTTPS 能抓包吗？

可以，HTTPS 可以抓包，但因为通信内容是加密的，需要解密后才能查看。其原理是通过一个中间人，伪造服务器证书，并取得客户端的信任，然后将客户端的请求转发给服务器，将服务器的响应转发给客户端，完成中间人攻击。

Web 页面请求过程

1. 没有IP, 就广播，然后通过交换机连接的DHCP服务器会配置IP地址以及网关路由器的地址。
2. 通过ARP获取网关路由器的MAC地址
3. DNS找到目的地IP
4. TCP 三次握手
5. 返回页面。

1. DHCP 配置主机 IP 等信息

• 假设主机最开始没有 IP 地址以及其它信息，那么就需要先使用 DHCP 来获取。
• 主机生成一个 DHCP 请求报文，并将这个报文放入具有目的端口 67 和源端口 68 的 UDP 报文段中。
• 该报文段则被放入在一个具有广播 IP 目的地址(255.255.255.255) 和源 IP 地址（0.0.0.0）的 IP 数据报中。
• 该数据报则被放置在 MAC 帧中，该帧具有目的地址 FF:<zero-width space>FF:<zero-width space>FF:<zero-width space>FF:<zero-width space>FF:FF，将广播到与交换机连接的所有设备。
• 连接在交换机的 DHCP 服务器收到广播帧之后，不断地向上分解得到 IP 数据报、UDP 报文段、DHCP 请求报文，之后生成 DHCP ACK 报文，该报文包含以下信息：IP 地址、DNS 服务器的 IP 地址、默认网关路由器的 IP 地址和子网掩码。该报文被放入 UDP 报文段中，UDP 报文段有被放入 IP 数据报中，最后放入 MAC 帧中。
• 该帧的目的地址是请求主机的 MAC 地址，因为交换机具有自学习能力，之前主机发送了广播帧之后就记录了 MAC 地址到其转发接口的交换表项，因此现在交换机就可以直接知道应该向哪个接口发送该帧。
• 主机收到该帧后，不断分解得到 DHCP 报文。之后就配置它的 IP 地址、子网掩码和 DNS 服务器的 IP 地址，并在其 IP 转发表中安装默认网关。

2. ARP 解析 网关路由器 MAC 地址

• 主机通过浏览器生成一个 TCP 套接字，套接字向 HTTP 服务器发送 HTTP 请求。为了生成该套接字，主机需要知道网站的域名对应的 IP 地址。
• 主机生成一个 DNS 查询报文，该报文具有 53 号端口，因为 DNS 服务器的端口号是 53。
• 该 DNS 查询报文被放入目的地址为 DNS 服务器 IP 地址的 IP 数据报中。
• 该 IP 数据报被放入一个以太网帧中，该帧将发送到网关路由器。
• DHCP 过程只知道网关路由器的 IP 地址，为了获取网关路由器的 MAC 地址，需要使用 ARP 协议。
• 主机生成一个包含目的地址为网关路由器 IP 地址的 ARP 查询报文，将该 ARP 查询报文放入一个具有广播目的地址（FF:FF:FF:FF:FF:FF）的以太网帧中，并向交换机发送该以太网帧，交换机将该帧转发给所有的连接设备，包括网关路由器。
• 网关路由器接收到该帧后，不断向上分解得到 ARP 报文，发现其中的 IP 地址与其接口的 IP 地址匹配，因此就发送一个 ARP 回答报文，包含了它的 MAC 地址，发回给主机。

3. DNS 解析域名

• 知道了网关路由器的 MAC 地址之后，就可以继续 DNS 的解析过程了。
• 网关路由器接收到包含 DNS 查询报文的以太网帧后，抽取出 IP 数据报，并根据转发表决定该 IP 数据报应该转发的路由器。
• 因为路由器具有内部网关协议（RIP、OSPF）和外部网关协议（BGP）这两种路由选择协议，因此路由表中已经配置了网关路由器到达 DNS 服务器的路由表项。
• 到达 DNS 服务器之后，DNS 服务器抽取出 DNS 查询报文，并在 DNS 数据库中查找待解析的域名。
• 找到 DNS 记录之后，发送 DNS 回答报文，将该回答报文放入 UDP 报文段中，然后放入 IP 数据报中，通过路由器反向转发回网关路由器，并经过以太网交换机到达主机。

4. HTTP 请求页面

• 有了 HTTP 服务器的 IP 地址之后，主机就能够生成 TCP 套接字，该套接字将用于向 Web 服务器发送 HTTP GET 报文。
• 在生成 TCP 套接字之前，必须先与 HTTP 服务器进行三次握手来建立连接。生成一个具有目的端口 80 的 TCP SYN 报文段，并向 HTTP 服务器发送该报文段。
• HTTP 服务器收到该报文段之后，生成 TCP SYN ACK 报文段，发回给主机。
• 连接建立之后，浏览器生成 HTTP GET 报文，并交付给 HTTP 服务器。
• HTTP 服务器从 TCP 套接字读取 HTTP GET 报文，生成一个 HTTP 响应报文，将 Web 页面内容放入报文主体中，发回给主机。
• 浏览器收到 HTTP 响应报文后，抽取出 Web 页面内容，之后进行渲染，显示 Web 页面。