好未来直播课使用WebRTC技术，如何防止中间人攻击和数据窃听？请说明安全措施。

1) 【一句话结论】好未来直播课WebRTC通过TLS加密信令、DTLS加密ICE交换、SRTP加密媒体流，结合证书验证，实现端到端加密与身份认证，有效防范中间人攻击和数据窃听。

2) 【原理/概念讲解】老师口吻，解释WebRTC安全架构：
WebRTC的安全设计围绕“信令安全”和“媒体流安全”两个核心：

• 信令（Signaling）：用于交换会话描述（SDP）和ICE候选，是建立连接的“导航图”。若信令未加密，攻击者可篡改SDP（如替换服务器地址）或窃听ICE候选（获取网络路径信息），导致MITM。因此需通过TLS加密信令通道（如WebSocket over TLS），确保信令传输的机密性和完整性。
• ICE（Interactive Connectivity Establishment）：用于自动协商网络路径（如NAT穿越）。ICE交换包含候选地址（IP+端口），若未加密，攻击者可劫持候选，干扰连接。WebRTC通过**DTLS（Datagram Transport Layer Security）**加密ICE交换，保护候选信息。
• 媒体流（Audio/Video）：WebRTC默认使用**SRTP（Secure Real-time Transport Protocol）**加密音视频数据，确保数据在传输过程中不被窃听。SRTP基于DTLS提供加密、认证和完整性保护，实现端到端加密。

类比：信令像“会议邀请函”，必须通过“加密信箱”传递（TLS）；ICE候选像“会议地点坐标”，需加密防止被篡改（DTLS）；媒体流像“会议内容”，需加密防止被偷听（SRTP）。

3) 【对比与适用场景】

措施	定义/特性	使用场景	注意点
TLS加密信令	用TLS协议加密WebSocket等信令通道	所有WebRTC信令交换（如SDP）	需证书验证（防止MITM）
DTLS加密ICE交换	用DTLS加密ICE候选交换	ICE路径协商阶段	确保候选信息机密性
SRTP加密媒体流	用SRTP加密音视频数据	音视频传输阶段	需与DTLS配合，提供端到端加密

4) 【示例】
伪代码示例（信令与媒体加密流程）：

1. 客户端A向信令服务器发送SDP（描述本地媒体能力），服务器通过TLS加密传输。
2. 服务器转发SDP给客户端B，B回复SDP，服务器再次通过TLS加密。
3. 客户端A和B交换ICE候选（如“udp://192.168.1.100:12345”），通过DTLS加密交换。
4. 建立连接后，客户端A的音频流通过SRTP加密，传输到客户端B，确保数据不被窃听。

5) 【面试口播版答案】
“好未来直播课WebRTC的安全措施围绕‘端到端加密’和‘身份验证’展开。首先，信令部分采用TLS加密的WebSocket通道，确保会话描述（SDP）和ICE候选交换不被窃听或篡改，防止中间人攻击。其次，ICE路径协商通过DTLS加密，保护候选地址的机密性，避免攻击者劫持网络路径。最后，音视频媒体流使用SRTP加密，实现端到端加密，彻底防止数据窃听。这些措施共同保障了直播课的通信安全。”

6) 【追问清单】

• 问题1：如何处理自签名证书（如测试环境）？
  • 回答要点：测试环境可配置信任自签名证书的CA，生产环境强制使用受信任的CA证书，确保客户端验证服务器的身份。
• 问题2：DTLS握手过程中如何防止重放攻击？
  • 回答要点：DTLS使用非对称加密（如RSA或ECDHE）和随机数（如Nonce）生成会话密钥，结合MAC（消息认证码）防止重放攻击。
• 问题3：当客户端与服务器位于不同NAT网络时，如何确保DTLS连接的可靠性？
  • 回答要点：WebRTC的DTLS支持NAT穿越，通过STUN/TURN服务器辅助，确保连接稳定，同时加密保护数据。
• 问题4：如果媒体流加密密钥泄露，如何快速更新密钥？
  • 回答要点：采用密钥协商机制（如DTLS的密钥更新），结合短生命周期密钥（如每分钟更新），降低密钥泄露风险。
• 问题5：是否考虑过跨域信令的安全？
  • 回答要点：信令服务器部署在HTTPS域名下，客户端通过CORS（跨域资源共享）配置，确保跨域通信时仍通过TLS加密，防止跨域攻击。

7) 【常见坑/雷区】

• 坑1：忽略信令安全，仅提及DTLS/SRTP，导致MITM风险。
• 坑2：混淆DTLS和SRTP的作用，将DTLS误认为媒体加密，或SRTP误认为信令加密，混淆安全组件职责。
• 坑3：未提及证书验证，仅说DTLS加密，无法防止MITM。
• 坑4：忽略NAT穿越的安全，未说明DTLS支持NAT，认为NAT穿越会暴露安全风险。
• 坑5：未考虑密钥管理，未提及密钥更新机制，导致认为密钥泄露后无法修复。