Trao đổi khóa hậu lượng tử thêm một trường mới vào ClientHello. Cách ML-KEM và ML-DSA định hình lại dấu vân tay JA3/JA4 và ý nghĩa với việc phát hiện.
Năm 2026, mật mã hậu lượng tử không còn chỉ là chủ đề nghiên cứu mà đã bắt đầu xuất hiện trong các lần bắt tay TLS ở môi trường production. Cloudflare gần đây lập luận rằng các thuật toán chữ ký cổ điển không thể đơn giản chờ đợi các phương án thay thế hậu lượng tử tốt hơn, còn APNIC đã theo dõi thực tế vận hành của việc triển khai PQC trên các mạng lưới. Cả hai bài viết đều nói về việc triển khai, không phải về fingerprinting — nhưng cơ chế mà chúng mô tả lại thay đổi chính ClientHello mà TLS fingerprinting qua JA3/JA4 vẫn luôn đọc. Bài viết này nói về tác dụng phụ đó: trao đổi khóa và chữ ký hậu lượng tử thực sự làm gì với dấu vân tay TLS của bạn.
Điểm mấu chốt
- Trao đổi khóa hậu lượng tử thêm một nhóm được hỗ trợ mới vào ClientHello, không phải một giao thức mới. Các cơ chế lai như
X25519MLKEM768nằm trong chính các extensionsupported_groupsvàkey_sharemà JA3/JA4 đã băm từ trước. - Các key share lớn hơn nhiều. Một key share X25519 cổ điển chỉ 32 byte; một key share ML-KEM-768 lai vượt xa 1.000 byte — đôi khi đủ để đẩy ClientHello vượt qua ranh giới UDP hoặc TCP bị phân mảnh.
- ML-DSA ảnh hưởng đến một extension khác là
signature_algorithms, dùng cho chữ ký của quá trình bắt tay chứ không phải trao đổi khóa — một thay đổi riêng biệt nhưng bổ sung trong cùng một thông điệp. - Mức độ hỗ trợ không đồng đều giữa các trình duyệt và phiên bản, vì vậy việc client có đưa ra nhóm PQC hay không — và ở vị trí nào — trở thành một tín hiệu fingerprinting mới, hiện đang có độ entropy cao.
- JA4 đã xử lý đúng điều này. Vì nó sắp xếp các extension và cipher suite theo giá trị số trước khi băm, việc client bật hay tắt hỗ trợ PQC chỉ thay đổi tập giá trị đã sắp xếp đi vào hàm băm — chứ không phá vỡ định dạng như cách JA3 nhạy cảm với thứ tự sẽ gặp phải.
Điều gì thực sự mới trong ClientHello
TLS fingerprinting hoạt động được là vì ClientHello — cipher suite, extension, nhóm được hỗ trợ, key share — do thư viện TLS quyết định, không phải do người dùng. Trao đổi khóa hậu lượng tử không thêm loại thông điệp mới hay một vòng trao đổi mới; nó thay đổi nội dung của hai trường vốn đã có trong cùng ClientHello đó:
supported_groupscó thêm một hoặc nhiều nhóm được đặt tên mới cho trao đổi khóa lai, đáng chú ý nhất làX25519MLKEM768— sự kết hợp giữa Diffie-Hellman đường cong elliptic cổ điển X25519 và cơ chế đóng gói khóa dựa trên lattice ML-KEM-768, được NIST chuẩn hóa thành FIPS 203. Bản dự thảo trao đổi khóa lai ML-KEM cho TLS của IETF quy định chính xác cách việc này được thỏa thuận bên trong TLS 1.3.key_sharemang theo vật liệu khóa thực tế cho bất kỳ nhóm nào mà client sẵn sàng gửi trước. Đây chính là nơi PQC để lại dấu vân tay lớn nhất: chỉ riêng khóa công khai của ML-KEM-768 đã là 1.184 byte, vượt xa 32 byte của X25519, nên một key share lai lớn hơn một key share cổ điển hơn một bậc độ lớn.
Chữ ký lại là một câu chuyện khác. ML-DSA (Module-Lattice Digital Signature Algorithm, FIPS 204) xuất hiện trong extension signature_algorithms, chi phối cách bản thân quá trình bắt tay được xác thực — không phải cách khóa chung được suy ra. Một client hoặc server có thể hỗ trợ trao đổi khóa hậu lượng tử, chữ ký hậu lượng tử, cả hai, hoặc không cái nào, và mỗi tổ hợp là một mẫu hình riêng biệt, có thể quan sát được trong ClientHello.
Tại sao là lai, không phải hậu lượng tử thuần túy
Mọi nhóm hậu lượng tử được triển khai trong TLS ngày nay đều là lai: nó kết hợp một thuật toán cổ điển (X25519) với một thuật toán hậu lượng tử (ML-KEM) thay vì thay thế hoàn toàn X25519. Khóa chung được suy ra từ cả hai, vì vậy kẻ tấn công phải phá vỡ cả bài toán đường cong elliptic lẫn bài toán lattice mới khôi phục được nó — một chiến lược phòng hộ trước khả năng ML-KEM, một tiêu chuẩn còn tương đối non trẻ, hóa ra có điểm yếu chưa được phát hiện. Chiến lược phòng hộ đó cũng chính là lý do bài viết của Cloudflare nhìn nhận ML-DSA theo cách này: các lược đồ chữ ký hậu lượng tử mới hơn và ít được kiểm chứng qua thời gian hơn trao đổi khóa, nên việc chờ đợi một phương án giả định tốt hơn là một chi phí thực sự, chứ không chỉ là sự thận trọng.
Tại sao đây là một tín hiệu fingerprinting
Một máy chủ làm fingerprinting không cần bất kỳ hạ tầng mới nào để nhận ra PQC — JA3 và JA4 đã băm toàn bộ supported_groups và danh sách extension từ trước. Điều thay đổi là những gì các giá trị băm đó giờ đây mã hóa:
Định vị phiên bản và bản build. Hỗ trợ PQC được triển khai dần dần — Chrome bật X25519MLKEM768 theo mặc định trong các khoảng phát hành cụ thể, các trình duyệt khác theo sau theo lịch trình riêng. Một ClientHello có hoặc không có nhóm lai này, kết hợp với mọi thứ khác mà JA4 đã đọc, không chỉ thu hẹp xuống "đây là Chrome" mà còn xác định gần đúng phiên bản Chrome nào.
Kiểm tra tính nhất quán cho các client giả mạo. Logic tương tự mà TLS fingerprinting đã áp dụng cho phát hiện bot — liệu handshake có khớp với những gì User-Agent tuyên bố lẽ ra phải tạo ra hay không — giờ có thêm một trường mới, hiện có tính phân biệt rất cao. Một thư viện thu thập dữ liệu hoặc công cụ giả lập TLS cũ chưa được cập nhật để thêm nhóm PQC sẽ không khớp với một User-Agent tự nhận là phiên bản trình duyệt hiện tại — giống hệt cách một handshake của Python requests không khớp với User-Agent Chrome ngày nay.
Kích thước, chứ không chỉ nội dung, giờ cũng mang tính thông tin. Vì key share của ML-KEM lớn hơn nhiều so với key share cổ điển, kích thước thô của chính ClientHello trở thành một tín hiệu thô — một ClientHello có hỗ trợ PQC rõ ràng lớn hơn ngay cả trước khi ai đó phân tích từng trường riêng lẻ.
Điểm khác biệt ở tầng mạng: ClientHello lớn hơn
Một extension key_share lớn hơn đồng nghĩa với một ClientHello lớn hơn, và điều đó có hệ quả bên dưới tầng TLS. Qua TCP, các thông điệp bắt tay TLS vốn đã được phép trải rộng trên nhiều segment TCP, nên một ClientHello lớn hơn phần lớn chỉ có nghĩa là nhiều dữ liệu hơn một chút trước khi hoàn tất bắt tay. Qua QUIC, nơi TLS ClientHello được mang trong gói Initial, một ClientHello lớn hơn đáng kể nhiều khả năng đòi hỏi client phải gộp nhiều datagram UDP hoặc dựa vào cơ chế xử lý giới hạn khuếch đại của kết nối — một trường hợp biên mà một số thiết bị trung gian và stack QUIC cũ trước đây xử lý không nhất quán. Không điều nào trong số này phá vỡ bắt tay trong một triển khai tuân thủ chuẩn, nhưng đây là thêm một nơi mà hỗ trợ PQC bộc lộ ra như một hành vi có thể quan sát được, phụ thuộc vào triển khai, thay vì một thay đổi nội bộ vô hình.
Ý nghĩa đối với các hệ thống phát hiện
Không điều gì trong số này tạo ra một hạng mục phát hiện mới — nó chỉ là một tập giá trị mới bên trong các hạng mục đã tồn tại sẵn. Một hệ thống phát hiện bot hoặc chống gian lận kiểm tra tính nhất quán của dấu vân tay TLS có thêm một trục nữa để suy luận: liệu tư thế PQC của client này có khớp với những gì trình duyệt và phiên bản mà nó tuyên bố lẽ ra phải tạo ra không, và tư thế đó có nhất quán giữa các yêu cầu trong cùng một phiên không? Một VPN hoặc proxy chặn bắt kết thúc và thiết lập lại kết nối TLS riêng của nó sẽ mang theo mức hỗ trợ PQC của thư viện TLS riêng của nó (hoặc thiếu nó), độc lập với client gốc — cùng một dấu hiệu đã tố cáo các proxy kết thúc TLS ngày nay, chỉ là có thêm một trường để so sánh.
Đối với bức tranh fingerprinting trình duyệt rộng hơn, đây là một tín hiệu ở tầng mạng, không phải tín hiệu có thể quan sát qua JavaScript — bạn không thể đọc ClientHello TLS của một trang từ các thuộc tính navigator. Nó đứng cạnh TLS fingerprinting và HTTP/3/QUIC fingerprinting như thêm một mảnh ghép nữa mà server nhìn thấy trước cả khi trình duyệt của bạn render bất cứ thứ gì.
Câu hỏi thường gặp
TLS hậu lượng tử có làm chậm kết nối của tôi không?
Không đáng kể, và chủ yếu ở giai đoạn bắt tay, không phải thông lượng liên tục. Các key share lớn hơn thêm một lượng nhỏ băng thông và tính toán một lần cho bắt tay; với hầu hết kết nối trên mạng hiện đại, điều này gần như không thể nhận ra. Nó quan trọng hơn ở các mạng bị giới hạn nghiêm ngặt hoặc các đường truyền nhạy cảm với việc phân mảnh ClientHello, như đã nêu ở trên.
Tôi có thể tắt trao đổi khóa hậu lượng tử để giảm entropy dấu vân tay không?
Bạn có thể, nếu trình duyệt của bạn cung cấp tùy chọn đó, nhưng nhiều khả năng điều này sẽ khiến bạn dễ bị nhận diện hơn, chứ không phải ít hơn. Khi các nhóm hỗ trợ PQC trở thành tiêu chuẩn trong các bản phát hành trình duyệt hiện tại, một ClientHello rõ ràng thiếu chúng trông giống như một bản build lỗi thời hoặc một client bị chỉnh sửa có chủ đích — đánh đổi một tín hiệu fingerprinting này lấy một tín hiệu đáng ngờ hơn.
ML-KEM có giống ML-DSA không?
Không. ML-KEM (FIPS 203) là một cơ chế đóng gói khóa dùng cho trao đổi khóa — nó xuất hiện trong supported_groups/key_share như một phần của nhóm lai như X25519MLKEM768. ML-DSA (FIPS 204) là một thuật toán chữ ký dùng để xác thực bắt tay, xuất hiện trong signature_algorithms thay vào đó. Cả hai đều là hậu lượng tử, dựa trên lattice, và được NIST chuẩn hóa, nhưng chúng giải quyết các bài toán khác nhau và xuất hiện ở các trường khác nhau trong ClientHello.
Điều này có ảnh hưởng đến dấu vân tay JA3 khác với JA4 không?
Có, khác biệt hơn hầu hết các thay đổi giao thức khác. JA3 băm cipher và extension theo đúng thứ tự client gửi, nên nó nhạy cảm với việc một thư viện sắp xếp nhóm PQC mới thêm vào giữa các nhóm hiện có như thế nào. JA4 sắp xếp cả hai trước khi băm, nên nó có khả năng chống chịu tốt với khác biệt về thứ tự và chỉ phản ánh tập giá trị thực tế — bao gồm cả việc có nhóm PQC hay không — khiến nó trở thành lựa chọn ổn định hơn để theo dõi sự chuyển đổi này. Xem TLS Fingerprinting: Cách JA3/JA4 Nhận Diện Client của Bạn để biết JA3 và JA4 khác nhau ra sao nói chung.
