过境加密

加密In Transit

1）控制的定义和界限

Transit加密是在网络传输的整个路径（浏览器↔服务器，服务↔服务，代理商↔经纪人，基地↔应用程序，数据中心↔数据中心）中保护数据，以便被动拦截和对链路的主动攻击不会泄露内容并且不允许在不进行检测的情况下对其进行修改。

涵盖的内容包括：公共和私有API（HTTP/HTTPS，gRPC），流媒体和经纪人（Kafka，NATS，RabbitMQ），WebSocket，网络基础和缓存，群集内的服务流量，VPN/跨数据中心和云端，DNS查询、移动/物联网客户端。

我们不能完全覆盖的内容是：端点攻击（主机/浏览器损害）、应用程序漏洞、登录名/转储泄漏。这可以通过单独的控制（A＆A，权利最小化，加密恢复，安全编写）来解决。

2）威胁模式和目标

风险：拦截/变换流量（MITM），协议/密码劫持，伪造证书/SA，密钥泄漏，SNI/元数据攻击，混合内容，不正确的TLS在平衡器上的破坏，不安全的服务间连接。

1.隐私+具有加密身份验证的完整性。

2.反对Downgrade（严格的政治和config）。

3.各方的识别（如有必要,服务器是相互的）。

4.管理的证书/密钥生命周期和审核。

5.不影响安全性的性能配置文件。

3）基本原则

默认情况下，TLS到处都是。外部和内部流量是密码。

现代版本。TLS 1.3作为标准；TLS 1.2-只有严格的政策。禁用1。0/1.1.

带有PFS的AEAD密码。AES-GCM或ChaCha20-Poly1305；通过（EC）DHE的PFS。
曲线/kay挖掘。X25519（最好是）或secp 256r1（P-256）。RSA密钥≥2048，优于ECDSA（P-256）。
mTLS在信任不足的地方。服务间渠道，admin-API，经纪人，基地-通过相互身份验证。
HSTS for Web。用于公共域的强制HTTPS+preload。
"Shifruem-i-on-shifruem"是有意识的。外围的TLS终端+对后端或端到端的passthrough加密-根据威胁模型进行选择。
Crypto-agility.能够以零停机时间更改曲线/套件/版本。

4）协议栈和脚本

4.1 HTTP/2, HTTP/3 (QUIC), gRPC, WebSocket

ALPN：HTTP/2为h2，HTTP/3为h3；禁止h2c（没有TLS）。
HTTP/3/QUIC：减少隐性、内联0-RTT和互联移动；0-RTT有选择地解决（重置风险）。
gRPC：在h2/h3之上；必定TLS,可选mTLS+per-RPC授权。
WebSocket：仅限wss：//；在代理/平衡器中-正确的域升级和TLS固定。

4.2服务间流量和服务

Sidecar模型（Istio/Linkerd等）。自动mTLS，权限策略，证书轮换。
SPIFFE/SPIRE.分散服务身份（SPIFFE ID），SVID证书，TTL短。
TLS参数集中。最大限度地减少服务代码中configs的差异。

4.3经纪人/流媒体/队列

Kafka/NATS/RabbitMQ：kliyent↔broker和broker↔broker的TLS；如果可能的话-mTLS。
TLS之上的SASL：如果mTLS不可行，则通过令牌/登录进行身份验证，但通道进行加密。
ACL和主题授权。加密≠访问控制。

4.4个数据库和缓存

PostgreSQL/MySQL/SQL Server：启用TLS，CN/SAN验证，pin SA/root。
Redis/Memcached：使用stunnel/TLS redis；禁止销售中的平原流量。

4.5网络/隧道

在数据中心/云之间：IPsec（IKEv2）或WireGuard（现代原语集）。
管理访问：具有现代KECH/密码的 SSH；密码禁令，只有/SSO密钥。

4.6个DNS和支持协议

TTPS上的DNS（DoH ）/TLS上的DNS（DoT）用于客户端，并在可能的情况下用于群集内部。
禁用溷合内容。https：//页面上没有任何内容。

5）证书、PKI和密钥管理

PKI模型：用于外部域-公共CA；对于内部流量-CA或SPIRE-CA。
自动化：ACME/Cert-Manager for Kubernetes，短TTL，自动旋转。
OCSP stapling и CRL.在前部包括滑动；定期更新链条。
Pinning-谨慎。在移动/台式机客户端中，带有紧急启动引擎的pin CA/SPKI。
密钥存储：HSM/KMS/秘密存储中的私有密钥；最少曝光；禁止拼写。

6）配置： 实用配置文件

• 版本：TLS 1。3（必修）,TLS 1.2 (fallback).

• TLS 1.3: `TLS_AES_128_GCM_SHA256`, `TLS_AES_256_GCM_SHA384`, `TLS_CHACHA20_POLY1305_SHA256`.
• TLS 1.2："ECDHE-ECDSA-AES 128-GCM-SHA 256"，"ECDHE-RSA-AES 128-GCM-SHA 256"（必要时为+变体AES256/CHACHA20）。
• 曲线：X25519, secp 256r1.
• 证书：ECDSA，最好是RSA-fallback。
• 安全标题："严格运输安全"，"X-Content-Type-Options"，"X-Frame-Options"（按案例），"Referrer-Policy"。
• Cookie："Secure"，"HttpOnly"，"SameSite"（设计Lax/Strict）。

• 客户端证书是必需的。
• 客户端SVID的短TTL（小时/天），自动旋转。
• 策略：谁可以连接到谁（基于intent/通过 mesh授权工作）.

7）性能和可靠性

硬件加速：AES-NI/ARMv8 Crypto，首选ChaCha20-Poly1305没有AES-NI的CPU。
Session resumption: TLS 1.3 tickets;思考生命周期（珀斯与安全之间的平衡）。
0-RTT：仅限于等效请求；保护自己免受重播（服务器反重播机制）。
平衡器/代理人：明确选择终端vs passthrough；终止-重新加密到后端。
观察力：ALPN握手/错误/谈判指标，TLS 1％。3、证书到期、OCSP状态。

8）测试和验证

TLS配置文件扫描。定期检查受支持的版本/繁文/曲线和HSTS/OCSP。
消极测试：禁止降级，拒绝弱肉汁，拒绝没有SNI/没有有效链证书的连接。
Pentest通道：MITM模拟，移动客户端的打孔检查，0-RTT中继尝试。
混沌测试：证书到期/撤销，OCSP/CA不可用。

9）频繁的错误以及如何避免错误

已启用TLS,但没有主机验证。我们总是检查CN/SAN，禁止"InsecureSkipVerify"。
混合内容。在https页面上阻止http资源,使用CSP。

弱/过时的版本和套餐。禁用TLS 1。0/1.1, CBC/RC4/3DES.

内部没有重新加密。从平衡器到应用程序的平原流量是风险。
长寿证书。做短的TTL和自动更新。
不正确的SNI/ALPN代理。在TLS pass tru/termination中正确传输SNI/ALPN。

10）迷你食谱（配置片段）

Nginx（前线，TLS 1。3/1.2, HSTS, OCSP stapling):

ssl_protocols      TLSv1. 3 TLSv1. 2;
ssl_ciphers       TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
ssl_prefer_server_ciphers on;
ssl_ecdh_curve     X25519:P-256;
ssl_stapling      on;
ssl_stapling_verify   on;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

transport_socket:
name: envoy. transport_sockets. tls typed_config:
"@type": type. googleapis. com/envoy. extensions. transport_sockets. tls. v3. DownstreamTlsContext common_tls_context:
tls_params:
tls_minimum_protocol_version: TLSv1_3 validation_context:
trusted_ca: { filename: /etc/tls/ca. crt }
tls_certificates:
certificate_chain: { filename: /etc/tls/tls. crt }
private_key:   { filename: /etc/tls/tls. key }
require_client_certificate: true

[Interface]
PrivateKey = <priv>
Address  = 10. 10. 0. 1/24
[Peer]
PublicKey = <pub>
AllowedIPs = 10. 10. 0. 0/24
Endpoint  = gw. example. com:51820
PersistentKeepalive = 25

11）政策与合规性

最低要求：TLS 1.3在可能的情况下；TLS 1.2-具有有限的suits集。
监管性：PCI DSS/finsector-禁止弱版本/套装；强制轮换和审计。
零信任方法：每个工作负载的身份，持续验证和服务级别的政策。

12）操作和SLO

SLO：TLS 1上成功握手的≥99％，流量的≥95％。3,0%溷合内容。
Alerts：证书到期（<14天）,握手故障增加,TLS 1份额下降。3、OCSP stapling错误。
过程：紧急更换SA/根，召回受损密钥，禁用0-RTT。

13）支票单

• 已禁用TLS 1。0/1.1和弱小的suits，包括AEAD和PFS。
• ALPN设置（h2/h3）；禁止h2c。
• HSTS已启用（用于公共领域）,没有溷合内容。
• 自动更新证书,OCSP stapling运行。
• 内部通道受到mTLS（或等效的WireGuard/IPsec）的保护。
• 已验证客户端/SDK中的主机/链验证。

• 监视TLS/ALPN版本/错误和演示。
• crypto-agility计划（翻译成新的套件/曲线）。
• 偶尔的运河五角星和configs的咆哮。

14) FAQ

问：TLS是否仅在外围就足够了？
哦不内部流量也必须加密（mTLS/tunnels/mesh），尤其是在云层和多范围时。

问：需要0-RTT吗？
答：针对偶数请求逐点打开,否则由于重播风险而关闭。

问： 如何选择数据中心？IPsec还是WireGuard?

答：WireGuard更简单，更快，IPsec是成熟且广泛支持的。如果配置正确,两者都是有效的。

问：如何保护webhooks"在路上"？
答：具有现代配置文件的HTTPS+验证发送者证书（如果mTLS）+有效载荷签名和计时器验证（请参阅Webhook交付保证，签名和查询验证）。

• "At Rest加密"
• "身份验证和授权"
• "；请求的签字和核实"；
• "S2S认证"
• "密钥管理和旋转"