HTTP 425 Too Early: Chặn replay khi dùng TLS 1.3 0‑RTT

TLS 1.3 0‑RTT có thể gửi HTTP request trước khi handshake hoàn tất, giảm độ trễ cho kết nối quay lại. Nhưng cùng một request “sớm” có thể bị phát lại: một thao tác mua hàng, đổi email hay tạo job có nguy cơ chạy nhiều lần. HTTP 425 Too Early tồn tại để server từ chối rủi ro đó và yêu cầu client thử lại sau khi kết nối đã được xác lập đầy đủ.

Bài này giải thích 0‑RTT thực sự tối ưu điều gì, vì sao mã hóa không đồng nghĩa chống replay, cách header Early-Data đi qua CDN/reverse proxy, khi nào trả 425 và cách rollout không biến tối ưu vài mili giây thành lỗi nghiệp vụ. Nội dung được đối chiếu với TLS 1.3 RFC 8446, HTTP Early Data RFC 8470 và tài liệu ssl_early_data của Nginx.

1. 0‑RTT không phải “không cần handshake”

Ở lần kết nối TLS 1.3 đầu tiên, client và server vẫn cần handshake bình thường. Sau phiên đó, server có thể cấp session ticket; khi quay lại, client dùng PSK liên quan tới ticket để gửi early data cùng ClientHello, trước khi nhận ServerHello của phiên mới.

Do đó 0‑RTT:

• chỉ áp dụng cho session resumption khi client còn ticket phù hợp;
• có thể bị server từ chối và fallback về handshake thông thường;
• không loại bỏ TCP handshake khi HTTP/1.1 hoặc HTTP/2 chạy trên TCP;
• không phải bảo đảm rằng response đến nhanh hơn trong mọi điều kiện mạng;
• không nên được bật nếu workload không có request an toàn để gửi sớm.

Lợi ích thực tế phụ thuộc tỷ lệ kết nối resume, vị trí edge, giao thức vận chuyển, cache và hành vi client. Đo latency thực tế thay vì suy luận từ tên “zero round trip”.

2. Vì sao request đã mã hóa vẫn bị replay?

Early data được mã hóa bằng khóa dẫn xuất từ PSK cũ và chưa phụ thuộc vào ServerHello mới. RFC 8446 nêu hai tính chất yếu hơn dữ liệu TLS thông thường: early data không có forward secrecy theo cùng cách và không có bảo đảm non-replay giữa các connection.

Kẻ tấn công không nhất thiết đọc được payload. Chỉ cần ghi lại flight chứa ClientHello và early data rồi gửi lại tới server hoặc một node khác, họ có thể làm server xử lý lại hành động. Trong cluster, cửa sổ replication của anti-replay state hoặc ticket key dùng chung làm bài toán khó hơn.

Các hậu quả có thể gồm:

• tạo hai đơn hàng, hai lệnh chuyển hoặc hai job;
• đảo thứ tự hành động, ví dụ phát lại thao tác xóa sau một thao tác tạo mới;
• làm bẩn cache hoặc khai thác timing giữa các cache node;
• tiêu hao quota/rate limit bằng nhiều bản sao;
• kích hoạt webhook, email hoặc tác vụ downstream nhiều lần.

Tính bí mật và tính duy nhất là hai thuộc tính khác nhau. TLS có thể giữ nội dung bí mật nhưng ứng dụng vẫn phải thiết kế để một bản mã hợp lệ không tạo tác dụng phụ lặp lại.

3. Safe, idempotent và replay-safe không giống nhau

HTTP gọi GET, HEAD, OPTIONS và TRACE là các method “safe” về ngữ nghĩa: client không yêu cầu thay đổi trạng thái. PUT và DELETE được định nghĩa idempotent: lặp lại cùng request có intended effect tương đương một lần. Nhưng các nhãn này không tự làm endpoint an toàn trước replay.

Policy đúng nên là allowlist theo resource, không chỉ if method == GET. Endpoint được phép cần chịu được duplicate, reorder, timing observation và resource exhaustion trong threat model thực tế.

4. Early-Data header nối TLS terminator với origin

Ứng dụng thường không trực tiếp kết thúc TLS. CDN, load balancer hoặc Nginx nhận early data rồi chuyển request HTTP tới origin. RFC 8470 định nghĩa:

Early-Data: 1

Header này báo rằng request đã được truyền trong early data ở một hop trước. Gateway không được xóa header hợp lệ khi forward. Nếu gateway không biết origin có hiểu và xử lý đúng Early-Data, nó không nên chuyển request sớm; nên đợi handshake hoàn tất hoặc trả 425.

Ranh giới tin cậy rất quan trọng. Origin chỉ nên nhận traffic từ proxy được kiểm soát. Proxy cần chuẩn hóa header dựa trên trạng thái TLS thật thay vì tin tùy ý header ngoài Internet. Nếu một request giả mạo Early-Data: 1 lọt tới ứng dụng và bị trả 425 thì thường chỉ gây từ chối request đó; nguy hiểm hơn là làm mất dấu request thực sự đến qua early data.

5. HTTP 425 Too Early hoạt động thế nào?

Server trả 425 khi không muốn mạo hiểm xử lý một request có thể bị replay:

HTTP/1.1 425 Too Early
Cache-Control: no-store
Content-Length: 0

Client đã gửi request trong early data được kỳ vọng thử lại; lần retry không được gửi trong early data. 425 không cacheable mặc định và payload không đại diện cho resource đích.

Server không nên dùng 425 như lỗi nghiệp vụ chung. Theo RFC 8470, server chỉ nên trả mã này khi biết request đến trong early data hoặc có Early-Data: 1; nếu không, client có thể không hiểu rằng nó cần retry.

Một request mang Early-Data: 1 không trở nên an toàn chỉ vì origin chờ thêm vài mili giây. Header cho biết request đã đi qua early data ở hop trước và có thể đã bị phát lại. Nếu resource không replay-safe, phải từ chối bằng 425.

6. Cấu hình Nginx: chỉ bật sau khi origin hiểu policy

Nginx cung cấp ssl_early_data và biến $ssl_early_data. Cấu hình tối thiểu để truyền tín hiệu tới upstream:

server {
    listen 443 ssl;
    server_name api.example.com;

    ssl_protocols TLSv1.3;
    ssl_early_data on;

    location / {
        proxy_set_header Early-Data $ssl_early_data;
        proxy_set_header Host $host;
        proxy_pass http://app_backend;
    }
}

$ssl_early_data có giá trị 1 khi handshake chưa hoàn tất và early data đang được dùng, còn lại rỗng. Không bật directive chỉ vì phần mềm hỗ trợ. Trước đó phải xác minh:

• origin chặn mọi resource không được allowlist;
• header không bị hop trung gian xóa hoặc ghi đè sai;
• mọi node có cùng policy;
• client thực sự retry đúng sau 425;
• log/metric phân biệt early, rejected và retry;
• session ticket, cache và anti-replay policy được đánh giá ở phạm vi toàn cluster.

Nếu origin chưa hỗ trợ, lựa chọn an toàn và đơn giản là để ssl_early_data off.

7. Middleware phải dùng allowlist theo endpoint

Ví dụ Laravel/PHP dưới đây chỉ cho phép early data với hai nhóm GET đã được đánh giá, còn lại trả 425:

<?php

namespace App\Http\Middleware;

use Closure;
use Illuminate\Http\Request;
use Symfony\Component\HttpFoundation\Response;

final class RejectUnsafeEarlyData
{
    public function handle(Request $request, Closure $next): Response
    {
        if ($request->header('Early-Data') !== '1') {
            return $next($request);
        }

        $allowed = $request->isMethod('GET') && (
            $request->is('assets/*') ||
            $request->is('catalog/public/*')
        );

        if (! $allowed) {
            return response('', 425)
                ->header('Cache-Control', 'no-store');
        }

        return $next($request);
    }
}

Middleware phải chạy trước session mutation, CSRF rotation, rate-limit có side effect, audit event nghiệp vụ hoặc controller. Ngay cả endpoint allowlist cũng cần kiểm tra middleware phía trước có ghi database, cập nhật “last seen”, tạo cache miss job hoặc phát event hay không.

Không dùng danh sách phủ định kiểu “chặn POST, cho phần còn lại”. Route mới sẽ vô tình được cho phép. Allowlist buộc mỗi endpoint mới phải được review trước khi hưởng 0‑RTT.

8. Idempotency key là lớp bảo vệ bổ sung, không phải giấy phép bật 0‑RTT

Idempotency key rất hữu ích cho retry hợp lệ của POST: server lưu kết quả theo key và trả lại cùng kết quả khi request lặp. Tuy nhiên nó không tự giải quyết toàn bộ replay:

• hai bản sao có thể tới hai region trước khi idempotency record được đồng bộ;
• check-then-act không atomic vẫn cho phép cả hai chạy;
• side effect downstream có thể phát trước khi record được commit;
• TTL, scope người dùng và canonical request không đúng gây collision hoặc tái sử dụng;
• replay có thể gây resource exhaustion dù kết quả nghiệp vụ được deduplicate.

Vì vậy giao dịch nhạy cảm nên bị 425 ở lớp early-data, rồi sau retry 1‑RTT vẫn dùng idempotency key, unique constraint, transaction/outbox và consumer idempotency. Đây là defense in depth.

9. Cluster và CDN: nhất quán quan trọng hơn tốc độ

Anti-replay tại TLS layer có thể dùng ticket age, cửa sổ thời gian hoặc state dùng chung, nhưng RFC 8446 không coi đó là bảo vệ tuyệt đối cho ứng dụng. Trong multi-region, cùng một flight có thể chạm các node với trạng thái chưa đồng bộ.

Kiểm tra các câu hỏi sau trước khi bật ở edge:

• CDN bật 0‑RTT cho toàn zone hay theo hostname/path?
• CDN tự chặn method unsafe hay chuyển Early-Data: 1 tới origin?
• Origin có thể phân biệt header do edge tin cậy với header từ client trực tiếp?
• Mọi region có cùng phiên bản middleware và allowlist?
• Retry sau 425 có đi sang region khác và tạo side effect không?
• Cache key có vô tình chứa/không chứa header làm response phân mảnh hoặc trộn lẫn?

Nếu không thể trả lời bằng tài liệu nhà cung cấp và thử nghiệm, tắt early data thường là quyết định hợp lý. 1‑RTT TLS 1.3 đã nhanh; độ phức tạp replay chỉ đáng nhận khi số liệu chứng minh lợi ích.

10. Quan sát và kiểm thử

Đừng chỉ đếm tổng số 425. Tối thiểu cần:

• số request early theo route, method, edge/region và client;
• tỷ lệ được xử lý, bị 425 và được retry thành công;
• latency p50/p95/p99 của resumed connection so với 1‑RTT;
• duplicate business key, unique-constraint conflict và idempotency hit;
• tỷ lệ auth/payment/API error sau rollout;
• rate-limit và cache behavior khi replay simulation.

Trong môi trường cô lập, cần kiểm thử ít nhất bốn trường hợp:

1. Request allowlist trong early data được xử lý đúng.
2. Request nhạy cảm có Early-Data: 1 nhận 425 trước mọi side effect.
3. Client retry cùng request sau handshake và chỉ tạo một kết quả.
4. Hai bản sao đồng thời tới hai node vẫn không tạo side effect trùng nhờ ràng buộc ứng dụng.

Không thử replay giao dịch thật trên production. Dùng staging giống production, tài khoản test và endpoint không gây thiệt hại.

11. Lỗi triển khai thường gặp

12. Checklist production

• Xác nhận workload có lợi ích đo được từ resumed early data.
• Liệt kê endpoint replay-safe bằng allowlist, owner và lý do.
• Đảm bảo edge/proxy truyền Early-Data: 1 chính xác.
• Đặt middleware trước mọi side effect và trả 425 cho route còn lại.
• Kiểm thử client retry không dùng early data.
• Giữ idempotency, unique constraint và outbox cho giao dịch sau retry.
• Kiểm tra tính nhất quán policy ở mọi node/region.
• Canary nhỏ, đo latency, 425, retry, duplicate và business error.
• Có rollback bằng cách tắt early data tại TLS terminator.

Kết luận

TLS 1.3 0‑RTT đổi một phần độ trễ lấy mô hình an toàn yếu hơn trước replay. HTTP 425 là cơ chế để origin nói “hãy gửi lại sau khi handshake hoàn tất”, không phải một mã lỗi chung. Thiết kế đáng tin cậy cần allowlist theo resource, bảo toàn tín hiệu Early-Data qua proxy, từ chối trước side effect và tiếp tục dùng idempotency ở tầng nghiệp vụ. Nếu lợi ích chưa được đo hoặc chuỗi proxy-origin chưa thống nhất, tắt 0‑RTT là lựa chọn kỹ thuật hoàn toàn hợp lý.