Chứng chỉ TLS "phản đối" giấu thông điệp trong khóa công khai

Một kỹ sư đã công bố thủ thuật tạo chứng chỉ SSL/TLS hợp lệ, được tổ chức cấp chứng chỉ tin cậy ký duyệt, nhưng nhúng một thông điệp bằng văn bản vào chính khóa công khai RSA. Đây là cách phản đối mang tính kỹ thuật đối với quy trình cấp phát chứng chỉ phức tạp hiện nay.

Điều đáng chú ý là chứng chỉ vẫn hoạt động bình thường, và người dùng có thể đọc thấy thông điệp ngay trong trình xem chứng chỉ của trình duyệt.

Vì sao tác giả khó chịu với SSL/TLS?

Theo tác giả, việc dựng một website công khai hiện đòi hỏi phải trải qua một "điệu nhảy" ACME phức tạp. Chứng chỉ lại hết hạn sau vài tháng, nên dù đã tự động hóa, người vận hành vẫn phải đảm bảo công cụ ACME luôn truy cập được bản ghi DNS hoặc máy chủ web.

Tác giả còn chỉ ra nghịch lý: chứng chỉ được cấp qua kết nối không mã hóa, và từng có tổ chức cấp chứng chỉ tin cậy dùng khóa bảo mật "rất an toàn" kiểu như số 4. Tuy vậy, tác giả vẫn muốn mã hóa lưu lượng web vì nghe lén thụ động là rủi ro có thật — chỉ là việc chống nghe lén không nhất thiết phải gắn với toàn bộ hệ thống chứng chỉ.

Phần duy nhất có thể kiểm soát: khóa công khai

Trong chứng chỉ, phần duy nhất người sở hữu trực tiếp kiểm soát là khóa công khai. Cách đơn giản nhất để có một chứng chỉ "xấu" là dùng khóa riêng dạng số đẹp (vanity key), ví dụ 313333333337, một trong những số nguyên tố "eleet" nổi tiếng.

Nhưng khóa yếu thì không ai biết trừ khi thử phá. Vì thế tác giả chọn cách phản đối rõ ràng hơn: nhúng hẳn một đoạn văn vào khóa công khai để bất kỳ ai xem chứng chỉ cũng đọc được.

Cơ chế RSA và chỗ để giấu thông điệp

Với RSA, khóa được tạo bằng cách chọn hai số nguyên tố lớn p và q, nhân lại thành modulus n. Số mũ công khai e thường là 65537 (0x10001) vì ít bit được bật giúp mã hóa nhanh hơn.

Tác giả cho biết tổ chức cấp chứng chỉ đã dùng sẽ từ chối ký khóa có số mũ công khai không chuẩn, nên không thể tùy biến ở e. Phần còn lại là n, dài 2.048 hoặc 4.096 bit do người dùng kiểm soát — địa điểm lý tưởng để giấu thông điệp.

Quy trình gồm các bước:

• Chọn hai số nguyên tố ngẫu nhiên và tính n.
• Sửa các byte của n để đưa thông điệp vào phần mã hóa base64.
• Do n đã bị sửa không còn là tích của p và q, đặt lại q = n/p, làm tròn và tìm số nguyên tố kế tiếp gần giá trị đó — thường chỉ cần thay đổi q vài trăm đơn vị.

Vì p và q có kích thước tương đương, thay đổi nhỏ ở q chỉ ảnh hưởng nửa ít quan trọng của tích. Miễn là thông điệp nằm ở nửa trên của n, nó nhiều khả năng sống sót nguyên vẹn. Sau đó, p và q mới được dùng để dựng khóa riêng RSA hợp lệ theo cách thông thường, rồi gửi CSR (yêu cầu ký chứng chỉ) cho tổ chức cấp chứng chỉ.

Tinh chỉnh vị trí và gia hạn

Vì base64 xử lý theo nhóm ba byte, thông điệp có thể bị lệch hàng và không đọc được. Nhưng bố cục chứng chỉ là cố định, nên có thể dịch vị trí thông điệp cho đến khi hiển thị đúng — tác giả ước tính cần dưới bốn lần thử.

Base64 thiếu phần lớn dấu câu nhưng có đủ bảng chữ cái ASCII, với khoảng 150 ký tự (RSA-2048) hoặc 320 ký tự (RSA-4096) — đủ chỗ cho những câu đùa. Một lựa chọn khác là nhắm vào dạng base16 hiển thị trong trình xem chứng chỉ của trình duyệt, cho nhiều chỗ hơn (2 ký tự mỗi byte thay vì 0,75) nhưng đòi hỏi chọn từ ngữ kỹ càng.

Gia hạn chứng chỉ được thực hiện bằng cách gửi lại CSR và lặp thử thách ACME, có thể tự động hóa.

Đánh đổi bảo mật

Thủ thuật này dĩ nhiên làm giảm entropy (độ ngẫu nhiên) của khóa riêng. Tác giả lập luận khóa vẫn an toàn vì các phương pháp gần tương tự từng được xem như một dạng nén khóa: nếu nửa trên của modulus cố định ở giá trị ai cũng biết, phần đó không cần truyền hay lưu. Các kỹ thuật hiện đại có thể cố định tới 2/3 khóa, giảm kích thước xuống 1/3 so với RSA chuẩn mà vẫn giữ mức an toàn tương đương — dù hướng này phần lớn đã bị bỏ để chuyển sang các hệ mật mã dùng khóa nhỏ trực tiếp.

Tác giả cũng thừa nhận hai rủi ro: việc chỉnh q có thể tạo ra các số nguyên tố quá gần nhau, khiến n bị phân tích và lộ khóa riêng; hoặc giá trị d quá nhỏ cũng là vấn đề. Cả hai đều khó xảy ra nhưng script của tác giả không kiểm tra các giá trị không an toàn này.

Dù vậy, với một website công khai, tác giả cho rằng điều đó vẫn chấp nhận được: TLS hiện đại có forward secrecy (bí mật chuyển tiếp), nên kể cả khi khóa riêng bị lộ, kẻ nghe lén vẫn phải thực hiện tấn công man-in-the-middle mới đọc được lưu lượng.

Góc nhìn

Với lập trình viên và kỹ sư vận hành tại Việt Nam, thủ thuật này là lời nhắc rằng chứng chỉ TLS không phải "hộp đen" bất khả xâm phạm: phần khóa công khai, phần mở rộng và tên miền đều có thể bị tùy biến, và điều đó vừa là công cụ học tập vừa là rủi ro nếu ai đó dùng để tạo cảm giác tin cậy giả.

Bài viết cũng minh họa giá trị của việc hiểu sâu cơ chế RSA thay vì chỉ chạy lệnh tạo chứng chỉ. Khi đã hiểu p, q và n liên hệ ra sao, việc đánh giá một chứng chỉ lạ trở nên dễ hơn nhiều.

Cuối cùng, mối bất mãn với độ phức tạp của ACME và vòng đời chứng chỉ ngắn là chuyện mà nhiều đội vận hành chia sẻ. Các giải pháp thay thế như tự động hóa bằng certbot phổ biến, hay những hệ mật mã dùng khóa nhỏ gọn, đáng để xem xét khi thiết kế hệ thống — miễn là vẫn đảm bảo luồng gia hạn chạy ổn định.