Kiểm thử TLS 1.3 session resumption và 0-RTT: đo nhanh nhưng không bỏ qua replay

Không nên bắt đầu bằng mục tiêu “bật 0-RTT”. Câu hỏi đúng là: với traffic profile thực tế, resumption cải thiện time-to-first-application-byte bao nhiêu; tỷ lệ handshake thành công có giữ ổn định khi ticket key xoay vòng; và loại request nào có thể được phép đi trong early data mà không tạo rủi ro replay.

RFC 8446 nêu rõ 0-RTT không có đầy đủ đặc tính bảo mật như dữ liệu 1-RTT, đặc biệt liên quan tới replay. Vì vậy, bài kiểm thử phải đồng thời đo hiệu năng và xác thực policy. Một phép đo latency đẹp nhưng cho phép lặp lại thao tác chuyển trạng thái không thể được coi là pass.

Topology tối thiểu gồm client/load generator, bộ mô phỏng điều kiện mạng, DNS nếu có, load balancer hoặc reverse proxy, cụm application server và hệ thống thu thập log/trace. Đồng hồ của các điểm đo phải đồng bộ; nếu chỉ dùng timestamp phía client, cần nói rõ giới hạn.

Ba nhóm phiên phải được gắn nhãn riêng:

• Luồng: Full handshake · Trạng thái client: Không có PSK/ticket hợp lệ · Kỳ vọng quan sát: TLS 1.3 hoàn tất trước application data
• Luồng: Resumption 1-RTT · Trạng thái client: Có PSK/ticket, không gửi early data · Kỳ vọng quan sát: Phiên được resume, application data sau handshake
• Luồng: Resumption 0-RTT · Trạng thái client: Có PSK/ticket và request đủ điều kiện · Kỳ vọng quan sát: Early data được chấp nhận hoặc từ chối theo policy

Giữ cố định phiên bản TLS library, cipher suite, key exchange group, certificate chain, OCSP behavior, kích thước response và HTTP version. Tách ảnh hưởng của DNS, TCP hoặc QUIC khỏi phép đo TLS. Nếu dùng connection pooling, phải ghi nhận tỷ lệ kết nối mới; nếu không, throughput ứng dụng có thể tăng trong khi handshake path chưa hề được kiểm thử.

Ticket lifetime, số ticket phát ra, ticket-key sharing giữa node, session cache và load-balancing affinity là biến số trọng yếu. Kiểm thử warm cache và cold cache thành hai phase. Khi thay đổi một biến, giữ nguyên traffic profile, concurrency và điều kiện latency/jitter/packet loss.

Nên thu p50/p95/p99 handshake latency, time-to-first-application-byte, handshakes per second, handshake success rate, resumed-session ratio, early-data acceptance ratio, retry/fallback ratio, CPU và memory của từng lớp. Đếm lỗi theo nguyên nhân như expired ticket, binder verification, replay rejection, certificate validation hoặc backend mismatch.

Bằng chứng tối thiểu gồm packet capture đã lọc dữ liệu nhạy cảm, log TLS có correlation ID, metrics của load generator, tài nguyên backend và bản cấu hình. Không suy ra 0-RTT chỉ từ latency; phải có dấu hiệu protocol hoặc log xác nhận early data được chấp nhận.

Policy phải dựa trên tính idempotent và side effect, không chỉ dựa trên HTTP method.

Pass/fail phải ghi ở cấp endpoint. Ví dụ, request đọc được phép 0-RTT nhưng request tạo tài nguyên phải bị trì hoãn hoặc từ chối early data và được retry an toàn sau handshake.

• Loại thao tác: Đọc nội dung cacheable, không cá nhân hóa · Cho phép 0-RTT mặc định?: Có thể · Điều kiện kiểm chứng: Replay không làm thay đổi trạng thái
• Loại thao tác: Truy vấn có token hoặc dữ liệu nhạy cảm · Cho phép 0-RTT mặc định?: Cân nhắc · Điều kiện kiểm chứng: Anti-replay, phạm vi token, logging
• Loại thao tác: Tạo đơn hàng, thanh toán, đổi cấu hình · Cho phép 0-RTT mặc định?: Không · Điều kiện kiểm chứng: Chỉ xử lý sau handshake 1-RTT
• Loại thao tác: Upload hoặc API không rõ idempotency · Cho phép 0-RTT mặc định?: Không · Điều kiện kiểm chứng: Chủ ứng dụng xác nhận semantics

Chạy baseline ở latency thấp trước, sau đó quét các profile đại diện cho LAN, WAN và mobile: tăng round-trip latency, thêm jitter có kiểm soát và packet loss ở mức nhỏ. Với mỗi profile, chạy full handshake, resumption 1-RTT và 0-RTT với cùng arrival model. Không dùng một concurrency cố định nếu nó làm thay đổi offered load giữa các mode.

Các phase đề xuất:

• Functional: một client, xác minh transcript và policy.
• Baseline: tải thấp, cache lạnh rồi cache ấm.
• Capacity: tăng connection rate tới ngưỡng mục tiêu.
• Impairment: quét latency, jitter và packet loss.
• Rotation: xoay ticket key, certificate hoặc rolling restart.
• Recovery: node lỗi, retry và hội tụ về trạng thái ổn định.

Tạo bản sao có kiểm soát của một early-data request trong môi trường lab. Pass khi endpoint có side effect không thực thi hai lần, hoặc bị chặn khỏi 0-RTT ngay từ policy. Không thực hiện thử nghiệm replay trên hệ thống sản xuất nếu chưa có phạm vi và phê duyệt.

Đưa ticket do node A phát tới node B để kiểm tra key sharing và hành vi khi không resume được. Mô phỏng cụm hỗn hợp trong giai đoạn nâng cấp; RFC 8446 khuyến nghị triển khai TLS 1.3 đồng nhất trước khi bật 0-RTT. Kiểm tra client retry khi server từ chối early data và xác nhận không nhân đôi request.

• Chốt endpoint, semantics và tiêu chí idempotency.
• Ghi phiên bản TLS stack, proxy, load balancer và application.
• Tắt connection reuse cho phase handshake-capacity; bật lại cho phase end-to-end.
• Làm sạch hoặc cố định session cache giữa các lần chạy.
• Xác minh ticket lifetime và key rotation trên mọi node.
• Thu packet capture, server log, load metrics và resource metrics cùng correlation ID.
• Lặp mỗi profile đủ lâu để p95/p99 ổn định.
• Thử early-data rejection, retry, node failure và rolling restart.
• Đối chiếu replay với trạng thái nghiệp vụ ở backend.
• Lưu cấu hình, thời gian và sai số của phép đo.

Kết quả chỉ áp dụng cho phiên bản TLS stack, topology, certificate chain, endpoint và traffic profile đã thử. Một proxy có thể terminate TLS và che khuất hành vi backend. Kết quả trên một node không chứng minh cụm nhiều vùng hoạt động đúng khi ticket key phân phối chậm.

Không quy đổi trực tiếp mức giảm handshake latency thành mức tăng trải nghiệm người dùng nếu DNS, TCP, application processing hoặc rendering chiếm phần lớn thời gian. 0-RTT là quyết định kết hợp giữa kiến trúc ứng dụng và bảo mật; load test không thay thế threat model.