Kiểm thử TLS 1.3 0-RTT: replay, session resumption và tính đúng của ứng dụng

Với session resumption, server có thể cho phép client gửi application data sớm trong ClientHello. Lợi ích tiềm năng là giảm thời gian đến byte hoặc response đầu tiên trên đường truyền có round-trip time cao. Tuy nhiên early data không có forward secrecy đối với PSK bị lộ và có thể bị replay; chấp nhận TLS không đồng nghĩa thao tác ứng dụng chỉ xảy ra một lần.

RFC 8470 bổ sung cơ chế HTTP Early Data và mã trạng thái 425 Too Early để origin yêu cầu client thử lại sau khi handshake hoàn tất. Đây là công cụ phối hợp, không phải lớp chống replay tự động cho mọi framework, CDN hay API gateway.

Topology tối thiểu gồm client generator, network emulator, TLS terminator/load balancer, hai backend và kho trạng thái hoặc database quan sát được. Bổ sung hai node/zone nếu production chia sẻ ticket key hoặc anti-replay state. Đo ở client, trước/sau terminator và tại audit log nghiệp vụ.

Phải ghi rõ nơi kết thúc TLS, nơi phát session ticket, vòng đời key, phạm vi chia sẻ key, cách route resumption và nơi quyết định cho phép early data. Một capture ngoài terminator không thể tự chứng minh backend đã xử lý request một hay hai lần.

Khóa phiên bản TLS library, cipher suite, ticket lifetime, key rotation, clock, load balancer policy, backend version, keep-alive và cache trước baseline. Traffic profile nêu rõ tỷ lệ kết nối mới/resumed, RTT, loss, concurrent connections, request size và tỷ lệ request idempotent so với có tác dụng phụ.

Quét các biến: early data bật/tắt; ticket hợp lệ/hết hạn; cùng hoặc khác terminator; restart node; rotate key; client clock lệch; failover zone; HTTP method; request có body; retry ở client/proxy; và network duplicate/reordering. 0-RTT acceptance rate thấp có thể do policy chủ ý, không nhất thiết là lỗi.

Đo handshake success, resumption rate, early-data offered/accepted/rejected, time to first byte, completion time, CPU và connection rate. Với tính đúng, đo số request logic duy nhất, số lần commit, duplicate side effect, idempotency-key hit và response 425. Báo percentile thay vì chỉ average.

Bằng chứng gồm TLS key log hoặc capture phù hợp quy định lab, event log của terminator, backend trace, database/audit event, client retry log và cấu hình ticket/anti-replay. Correlation ID cần tồn tại xuyên qua proxy đến nghiệp vụ.

Ma trận là điểm bắt đầu. Quyết định cuối phải dựa trên semantics thực tế; tên HTTP method không đủ chứng minh idempotence.

• GET nội dung tĩnh — Early data mặc định: Có thể cân nhắc; Rủi ro cần thử: cache/authorization sai ngữ cảnh; Kiểm soát đề xuất: cache key và policy rõ ràng
• GET có tác dụng phụ — Early data mặc định: Không nên coi là an toàn; Rủi ro cần thử: tăng counter/kích hoạt job; Kiểm soát đề xuất: sửa semantics hoặc chặn 0-RTT
• POST thanh toán/đặt lệnh — Early data mặc định: Từ chối; Rủi ro cần thử: duplicate transaction; Kiểm soát đề xuất: 1-RTT + idempotency key
• Telemetry ingest — Early data mặc định: Tùy thiết kế; Rủi ro cần thử: duplicate record; Kiểm soát đề xuất: event ID và dedup ở ứng dụng
• Authentication action — Early data mặc định: Thận trọng; Rủi ro cần thử: replay token/thao tác; Kiểm soát đề xuất: policy riêng, audit đầy đủ

Lấy baseline full handshake, sau đó resumption không early data và cuối cùng 0-RTT. Dùng cùng RTT/loss profile, request set và thời lượng để so sánh. Xác minh server phản hồi đúng khi ticket hết hạn hoặc early data bị từ chối: client phải tiếp tục/retry theo giao thức mà không nhân đôi nghiệp vụ.

Chạy tải tăng theo bậc và steady state đủ dài để quan sát key rotation. Tách latency tiết kiệm do 0-RTT khỏi lợi ích của connection reuse, cache hoặc TLS offload. Nếu không, kết quả sẽ gán nhầm nguyên nhân.

Checklist thực hành:

• Phân loại endpoint theo semantics và tác dụng phụ.
• Ghi baseline full handshake và resumed handshake.
• Kiểm tra offered/accepted/rejected early data.
• Đối soát mỗi request với một business transaction ID.
• Thử 425 Too Early và retry path.
• So sánh p50/p95/p99 latency cùng error/duplicate rate.

Trong lab, ghi lại một request early data vô hại có correlation key, sau đó phát lại dưới các điều kiện cùng node, khác node, trước/sau restart và trước/sau key rotation. Mục tiêu là quan sát lớp nào phát hiện hoặc vô hiệu hóa replay. Không dùng giao dịch thật, thông tin nhạy cảm hoặc hệ thống ngoài phạm vi cho phép.

Failover có thể làm anti-replay state không đồng nhất hoặc làm resumption bị từ chối. Cả hai cần được diễn giải đúng: từ chối 0-RTT rồi hoàn tất 1-RTT có thể là hành vi an toàn. Điều đáng ngại là request được chấp nhận nhiều lần và tạo duplicate side effect.

Triển khai theo allowlist endpoint, canary traffic và tỷ lệ nhỏ. Theo dõi early-data acceptance, 425, retry, duplicate business event, error rate và latency. Có nút tắt 0-RTT độc lập với toàn bộ TLS 1.3 để rollback nhanh mà không hạ chuẩn giao thức.

Runbook cần định nghĩa chủ sở hữu ticket key, lịch rotation, phạm vi chia sẻ state, phản ứng khi clock lệch, backend failover và cách truy vấn audit theo correlation ID. Sau thay đổi CDN/proxy/library, phải chạy regression thay vì giả định policy cũ còn nguyên.

Test không thể chứng minh “không bao giờ replay”; nó chỉ chứng minh hành vi trong topology, cửa sổ thời gian, phiên bản và trường hợp đã thử. Một endpoint idempotent ở phiên bản hôm nay có thể trở thành có tác dụng phụ sau thay đổi logic.

Kết luận phải tách ba lớp: TLS chấp nhận early data, HTTP/proxy xử lý retry, và ứng dụng bảo toàn tính đúng. Chỉ khi cả ba có bằng chứng mới có thể phê duyệt 0-RTT cho endpoint cụ thể.

• 0-RTT / early data: dữ liệu ứng dụng gửi cùng giai đoạn bắt đầu resumption.
• PSK: pre-shared key dùng cho session resumption trong TLS 1.3.
• Session ticket: thông tin giúp client nối lại phiên theo policy server.
• Replay: phát lại dữ liệu hợp lệ để hệ thống xử lý thêm lần nữa.
• Idempotency: lặp cùng thao tác không làm đổi kết quả ngoài lần đầu.
• 425 Too Early: phản hồi HTTP cho biết request cần thử lại sau handshake.
• Anti-replay state: trạng thái/cơ chế dùng để hạn chế chấp nhận dữ liệu lặp.