Linux——网络（https）

目录

一、https

1. HTTPS的核心目标

2. HTTPS vs HTTP

3. SSL/TLS协议

TLS握手流程（以RSA密钥交换为例）

4. 数字证书与CA

5. 加密技术

6. HTTPS性能优化

7. 常见问题

8. 配置最佳实践

9. 未来趋势

二、加密过程

1. 总体流程概览

2. TLS 握手阶段（密钥协商）

步骤 1：Client Hello

步骤 2：Server Hello

步骤 3：证书验证

步骤 4：密钥交换

步骤 5：生成会话密钥

步骤 6：握手完成

3. 数据传输阶段（对称加密）

4. 关键加密技术

非对称加密（握手阶段）

对称加密（传输阶段）

哈希算法

5. 前向保密（Forward Secrecy）

6. TLS 1.3 的改进

7. 加密过程示例（TLS 1.3）

8. 为什么混合使用对称和非对称加密？

9. 常见攻击与防御

三、对比http和https

1. 基础概念

2. 核心区别

3. HTTPS 如何保障安全？

4. HTTPS 工作原理（简化流程）

5. 常见问题

6. 为什么 HTTPS 是未来趋势？

四、设计安全法案

1、技术原理简介

2、安全方案设计

3、优势分析

总结

一、https

1. HTTPS的核心目标

• 数据加密：防止第三方窃听或篡改通信内容。

• 身份认证：通过数字证书验证服务器身份，防止中间人攻击。

• 数据完整性：确保数据在传输过程中未被修改。

2. HTTPS vs HTTP

3. SSL/TLS协议

HTTPS的安全基础是SSL（Secure Sockets Layer） 或 TLS（Transport Layer Security） 协议（TLS是SSL的升级版，现主要使用TLS 1.2/1.3）。

TLS握手流程（以RSA密钥交换为例）

1. Client Hello

   • 客户端发送支持的TLS版本、加密套件列表、随机数（Client Random）。

2. Server Hello

   • 服务端选择TLS版本、加密套件，发送随机数（Server Random）和数字证书。

3. 证书验证

   • 客户端验证证书合法性（是否由可信CA签发，域名是否匹配，是否过期等）。

4. 密钥交换

   • 客户端生成预主密钥（Pre-Master Secret），用证书公钥加密后发送给服务端。

5. 生成会话密钥

   • 双方通过Client Random、Server Random和Pre-Master Secret生成对称密钥（Session Key）。

6. 加密通信

   • 后续数据传输使用Session Key进行对称加密（如AES）。

TLS 1.3优化：简化握手流程，支持0-RTT（零往返时间），减少延迟。

4. 数字证书与CA

• 数字证书：包含服务器公钥、域名、签发机构（CA）、有效期等信息。

• CA（Certificate Authority）：受信任的第三方机构（如Let's Encrypt、DigiCert），负责验证服务器身份并签发证书。

• 证书链：根CA → 中间CA → 服务器证书，浏览器通过预置的根证书信任链验证合法性。

• 自签名证书：未通过CA签发，浏览器会提示不安全，仅用于测试或内部环境。

5. 加密技术

• 对称加密（如AES、ChaCha20）：加密和解密使用同一密钥，速度快，用于传输数据。

• 非对称加密（如RSA、ECC）：公钥加密、私钥解密，用于密钥交换和身份认证。

• 哈希算法（如SHA-256）：确保数据完整性，防止篡改。

6. HTTPS性能优化

• 会话恢复（Session Resumption）：通过Session ID或Session Ticket复用之前协商的密钥，减少握手开销。

• OCSP Stapling：服务端主动提供证书状态信息，避免客户端查询OCSP服务器。

• TLS 1.3：减少握手步骤，支持更高效的加密算法。

• HSTS（HTTP Strict Transport Security）：强制浏览器使用HTTPS，避免降级攻击。

7. 常见问题

• 混合内容（Mixed Content）：HTTPS页面中加载HTTP资源（如图片、脚本），浏览器会阻止或警告。

• 证书过期：需定期更新证书（自动化工具如Certbot可解决）。

• 中间人攻击：伪造证书或CA可能被利用，需确保证书链完整可信。

8. 配置最佳实践

1. 使用TLS 1.2/1.3，禁用不安全的协议（如SSLv3、TLS 1.0/1.1）。

2. 选择强加密套件（如ECDHE-ECDSA-AES128-GCM-SHA256）。

3. 启用HTTP到HTTPS的自动重定向（301/302）。

4. 配置HSTS头（Strict-Transport-Security: max-age=31536000; includeSubDomains）。

5. 定期更新证书，推荐自动化工具（如Let's Encrypt）。

9. 未来趋势

• TLS 1.3普及：更安全、更高效。

• 量子安全加密：应对量子计算机威胁的新算法（如抗量子加密算法）。

• Certificate Transparency：增强证书签发透明度，防止恶意证书。

二、加密过程

1. 总体流程概览

HTTPS 加密分为两个阶段：

1. TLS 握手阶段：通过非对称加密交换密钥，验证身份。

2. 数据传输阶段：使用对称加密密钥加密通信内容。

2. TLS 握手阶段（密钥协商）

步骤 1：Client Hello

• 客户端向服务端发送以下信息：

  • 支持的 TLS 版本（如 TLS 1.2/1.3）。

  • 支持的加密套件（Cipher Suites，如 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256）。

  • 客户端随机数（Client Random）。

步骤 2：Server Hello

• 服务端选择 TLS 版本和加密套件，返回以下信息：

  • 服务端随机数（Server Random）。

  • 数字证书（包含服务端公钥、域名、CA 信息等）。

  • （可选）要求客户端提供证书（双向认证场景）。

步骤 3：证书验证

• 客户端验证服务端证书：

  1. 证书链验证：检查证书是否由受信任的 CA 签发（通过预置的根证书）。

  2. 域名匹配：确认证书中的域名与访问的域名一致。

  3. 有效期检查：确保证书未过期。

  4. 吊销状态检查：通过 OCSP 或 CRL 验证证书未被吊销。

步骤 4：密钥交换

根据加密套件选择不同的密钥交换算法（如 RSA 或 ECDHE）：

• RSA 密钥交换（已逐渐淘汰，缺乏前向保密）：

  1. 客户端生成预主密钥（Pre-Master Secret）。

  2. 用服务端证书的公钥加密 Pre-Master Secret，发送给服务端。

  3. 服务端用私钥解密获取 Pre-Master Secret。

• ECDHE 密钥交换（现代主流，支持前向保密）：

  1. 服务端生成临时椭圆曲线参数（EC Diffie-Hellman 参数）并签名后发送给客户端。

  2. 客户端和服务端分别生成临时公私钥对，交换公钥。

  3. 双方通过椭圆曲线算法计算共享密钥（Pre-Master Secret）。

步骤 5：生成会话密钥

• 双方通过以下三个随机值生成主密钥（Master Secret）：

  • Client Random

  • Server Random

  • Pre-Master Secret

• 基于 Master Secret，使用伪随机函数（PRF）派生出 对称加密密钥（Session Key），用于后续通信。

步骤 6：握手完成

• 客户端和服务端交换加密后的 Finished 消息，验证握手过程是否一致且未被篡改。

3. 数据传输阶段（对称加密）

• 双方使用协商好的 Session Key 进行对称加密通信，常用算法如：

  • AES-GCM（高效且支持认证加密）。

  • ChaCha20-Poly1305（移动设备优化算法）。

• 每次通信的数据包会附加 消息认证码（MAC） 或使用 AEAD（Authenticated Encryption with Associated Data） 确保数据完整性。

4. 关键加密技术

非对称加密（握手阶段）

• 用途：身份认证（证书中的公钥）和密钥交换。

• 算法：

  • RSA（传统，无前向保密）。

  • ECDHE（现代，支持前向保密，即使私钥泄露，历史会话也无法解密）。

对称加密（传输阶段）

• 用途：加密实际传输的 HTTP 数据。

• 优势：计算效率高，适合大数据量加密。

• 算法：AES（128/256 位）、ChaCha20 等。

哈希算法

• 用途：生成消息摘要，验证数据完整性。

• 算法：SHA-256、SHA-384（TLS 1.2/1.3 主流）。

5. 前向保密（Forward Secrecy）

• 核心思想：每次会话使用临时密钥（Ephemeral Key），即使服务端私钥泄露，历史会话也无法解密。

• 实现方式：通过 ECDHE 或 DHE 密钥交换算法生成临时密钥。

• 重要性：防止攻击者长期保存密文后通过私钥破解。

6. TLS 1.3 的改进

1. 简化握手流程：

   • 合并 Client/Server Hello 步骤，减少往返次数（1-RTT 或 0-RTT）。

2. 废弃不安全算法：

   • 移除了 RSA 密钥交换、SHA-1、RC4 等弱算法。

3. 0-RTT 模式：

   • 允许客户端在首次握手时发送加密数据（需权衡重放攻击风险）。

7. 加密过程示例（TLS 1.3）

Client                                  Server
------                                 ------
Client Hello
（支持的版本、加密套件、Client Random）
       --------------->
                                       Server Hello
                                       （选择版本、加密套件、Server Random）
                                       Certificate（证书）
                                       Server Parameters（ECDHE 公钥）
                                       CertificateVerify（签名验证）
                                       Finished
                         <---------------
Client Parameters（ECDHE 公钥）
Finished
       --------------->
[应用数据（加密）]
       <--------------->

8. 为什么混合使用对称和非对称加密？

• 非对称加密：解决密钥分发问题，但计算开销大。

• 对称加密：高效，适合数据加密，但需安全分发密钥。

• 结合优势：用非对称加密安全交换对称密钥，再用对称加密处理数据。

9. 常见攻击与防御

• 中间人攻击（MITM）：通过伪造证书拦截通信。
  防御：严格验证证书链和域名。

• 重放攻击：重复发送截获的加密数据。
  防御：使用随机数（Nonce）和会话密钥时效性。

• 降级攻击：迫使使用弱加密协议。
  防御：配置 HSTS 强制 HTTPS，禁用旧协议（如 SSLv3）。

三、对比http和https

1. 基础概念

• HTTP（HyperText Transfer Protocol）
  用于在客户端（如浏览器）和服务器之间传输超文本（如网页），是互联网数据通信的基础。默认端口 80，不加密，数据以明文传输。

• HTTPS（HTTP Secure）
  在 HTTP 基础上加入 SSL/TLS 加密层，通过加密和身份验证保护数据安全。默认端口 443，URL 以 https:// 开头，地址栏显示“锁”标志。

2. 核心区别

3. HTTPS 如何保障安全？

• 加密传输

  • TLS 握手：通过非对称加密（如 RSA、ECC）交换密钥，再切换为对称加密（如 AES）传输数据，兼顾安全与效率。

  • 混合加密机制：非对称加密协商密钥 + 对称加密传输数据。

• 身份验证

  • 服务器需提供由 CA（证书颁发机构） 签发的 SSL 证书，验证网站身份，防止“钓鱼网站”。

• 数据完整性

  • 使用 MAC（消息认证码） 或 哈希算法（如 SHA-256）确保数据未被篡改。

4. HTTPS 工作原理（简化流程）

1. 客户端发起请求
   浏览器连接到服务器的 443 端口，发送支持的加密算法列表。

2. 服务器响应证书
   服务器返回 SSL 证书（含公钥）和选择的加密算法。

3. 密钥交换
   客户端验证证书有效性，生成对称加密的“会话密钥”，用服务器公钥加密后发送。

4. 加密通信
   双方使用会话密钥进行对称加密通信。

5. 常见问题

• Q：HTTPS 会拖慢网站速度吗？
  A：早期因加密计算影响性能，但现代硬件优化（如 TLS 1.3、会话复用）已大幅降低延迟，性能损失可忽略。

• Q：如何获取 SSL 证书？
  A：可购买（如 DigiCert、Symantec），或使用免费证书（Let's Encrypt）。证书分三种类型：

  • DV（域名验证）：验证域名所有权，适合个人网站。

  • OV（组织验证）：验证企业身份，适合商业网站。

  • EV（扩展验证）：显示公司名称，需严格审核（现逐渐淡出）。

• Q：为何 HTTPS 页面加载 HTTP 资源会报错？
  A：浏览器会阻止 混合内容（Mixed Content），防止 HTTP 资源破坏整体安全性。

6. 为什么 HTTPS 是未来趋势？

• 浏览器强制要求：Chrome/Firefox 将 HTTP 标记为“不安全”。

• HTTP/2 和 HTTP/3：主流浏览器仅支持 HTTPS 下的新协议，提升传输效率。

• 法规合规：如 GDPR、PCIDSS 要求敏感数据必须加密。

四、设计安全法案

1、技术原理简介

1. 对称加密：加密和解密使用相同密钥，速度快但密钥管理困难。

1. 非对称加密：使用一对密钥（公钥和私钥），公钥公开，私钥保密，主要用于密钥交换和数字签名。

1. 数字证书：由权威机构颁发，用于证明公钥持有者身份的文件。

2、安全方案设计

1. 密钥交换阶段：

• • 发送方生成一个随机的对称密钥。

• • 发送方使用接收方的公钥对对称密钥进行加密。

• • 加密后的对称密钥发送给接收方。

• • 接收方使用自己的私钥解密，得到对称密钥。

1. 数据传输阶段：

• • 发送方使用对称密钥对数据进行加密。

• • 加密后的数据发送给接收方。

• • 接收方使用相同的对称密钥进行解密。

1. 身份认证阶段：

• • 发送方和接收方在通信前交换数字证书。

• • 双方验证对方证书的有效性，确保身份真实可靠。

1. 完整性保护阶段：

• • 发送方使用哈希算法计算数据的哈希值。

• • 发送方使用自己的私钥对哈希值进行签名。

• • 接收方收到数据后，重新计算哈希值，并使用发送方的公钥验证签名。

3、优势分析

1. 保密性：对称加密保证数据传输的机密性，非对称加密确保对称密钥的安全交换。

1. 完整性：哈希算法和数字签名确保数据在传输过程中未被篡改。

1. 认证性：数字证书实现通信双方的身份认证。

总结

HTTPS 通过加密和身份验证彻底解决了 HTTP 的安全缺陷，已成为现代网站的标配。尽管初期部署需配置证书，但其对隐私保护、SEO 及用户体验的提升远超成本。随着技术进步，HTTPS 的性能损耗几乎可忽略，未来全面普及已成必然。