Một tuần sau khi lộ ra việc eMudhra tạo khóa CA trung gian quá yếu, Cloudflare công bố dữ liệu theo dõi cho thấy chứng chỉ SSL giả mạo đã xuất hiện chỉ vài giờ sau khi lỗi bị công khai, trong khi một phần lớn thiết bị vẫn chưa được vá. Bài viết ngày 30/10/2026 của Cloudflare là bản cập nhật quan trọng cho sự cố mà Canh Deal đã đưa tin trong bài eMudhra lộ khóa CA, trình duyệt chặn chứng chỉ SSL trung gian.

Tóm tắt nhanh

  • Vấn đề: tám khóa CA trung gian của eMudhra yếu đến mức khóa riêng có thể tính ra từ chứng chỉ công khai.
  • Bắt tay dùng khóa yếu: khoảng 22.000 lượt trong gần một tuần trên mạng Cloudflare.
  • Chứng chỉ giả mạo: khoảng 160 lượt bắt tay đáng chú ý, có chứng chỉ được tạo chưa đầy một giờ sau khi lỗi công khai.
  • Thiết bị chưa vá: 30 đến 40% Android WebView vẫn chấp nhận chuỗi chứng chỉ yếu.
  • Nghe lén: Cloudflare chưa thấy bằng chứng khóa yếu bị dùng để chặn kết nối của Cloudflare.

Sự cố bắt đầu từ đâu?

Cloudflare biết tới tám khóa yếu của eMudhra ngày 19/10/2026. Theo Cloudflare, eMudhra đã chọn "số 4" cho một khóa dài 115 chữ số, các giá trị yếu khác gồm 56, 66, 115, 155, 156, 230 và 237. Vì khóa riêng của CA trung gian có thể được khôi phục từ chứng chỉ công khai, bất kỳ ai cũng có thể ký chứng chỉ cho tên miền tùy ý, và các client chưa vá, không bắt buộc Certificate Transparency sẽ tin chứng chỉ đó.

eMudhra cho biết sẽ rút khỏi mảng CA công cộng và quy lỗi cho một script tạo khóa, nhưng chưa công bố script này. Cloudflare còn ghi nhận eMudhra từng ký một danh sách thu hồi (CRL) bằng khóa có thể là đúng, rồi ký lại bằng chính khóa yếu.

Cloudflare đã thấy gì trong một tuần?

22.000 lượt bắt tay và chứng chỉ giả mạo

Khoảng hai phần ba trong số 22.000 lượt bắt tay là truy cập các trang thử nghiệm. Gần như toàn bộ phần còn lại đến từ máy chủ origin tự cấp chứng chỉ từ CA trung gian yếu. Mọi lượt bắt tay được cấu hình xác minh chứng chỉ đều bị từ chối.

Đáng chú ý là khoảng 160 lượt bắt tay dùng chứng chỉ ghi tên miền của các tổ chức không liên quan, một số gắn với thiết bị IoT tiêu dùng, có thời hạn trên hai năm, dài hơn mức mọi CA công cộng được phép cấp. Một chứng chỉ giả mạo mang thời điểm 18:19 UTC ngày 20/10/2026, chưa đầy một giờ sau khi báo cáo lỗi trên Mozilla được công khai. Cloudflare nhận định các chứng chỉ này giống chứng chỉ mặc định của máy chủ hơn là nỗ lực nghe lén, nhưng nhấn mạnh dữ liệu không loại trừ được tấn công có chủ đích.

Phía người dùng: thiết bị nhúng vá chậm

Cloudflare gửi khoảng 50 triệu lượt thăm dò qua trang challenge trong một tuần để đo mức độ vá ở trình duyệt. Kết quả cho thấy trình duyệt hiện đại đã cập nhật phần lớn đã an toàn, nhưng bot và trình duyệt cũ hầu như chưa vá. Android WebView, trình duyệt nhúng trong nhiều ứng dụng di động, còn khoảng 30 đến 40% chấp nhận chuỗi yếu. Tính theo các mạng lớn (ASN), hơn một nửa lượt thăm dò vẫn chấp nhận chuỗi chứng chỉ đã bị lộ và xu hướng gần như đứng yên sau cuối tuần đầu tiên.

Về hệ thống nội bộ, Cloudflare vá các proxy Pingora phía origin chỉ trong vài giờ ngày 19/10 và đến thời điểm viết bài đã vá xong mọi hệ thống ưu tiên cao.

Chủ website và quản trị máy chủ cần làm gì?

  1. Cập nhật kho chứng chỉ tin cậy trên máy chủ (gói ca-certificates trên Debian/Ubuntu), máy trạm và trình duyệt. Cloudflare dẫn tới trang hướng dẫn do Dennis Jackson tổng hợp; lập trình viên dùng macOS cần làm theo phần riêng cho Apple.
  2. Kiểm tra chuỗi chứng chỉ của chính mình: nếu website, API hoặc thiết bị nội bộ dùng chứng chỉ từ chuỗi eMudhra, cần chuyển sang CA khác. Tham khảo bài cài SSL Let's Encrypt bằng Certbot.
  3. Bắt buộc Certificate Transparency ở client khi có thể, đặc biệt với ứng dụng di động dùng WebView.
  4. Khách hàng Cloudflare dùng WARP hoặc Tunnel làm theo các bước trong bài hướng dẫn đầu tiên của Cloudflare.

Cloudflare cũng kêu gọi ngành cập nhật kho chứng chỉ tin cậy nhanh hơn, vì danh sách root tĩnh không theo kịp những lỗ hổng diễn biến nhanh như thế này. Nếu bạn cần ôn lại cách các loại chứng chỉ hoạt động, xem bài chứng chỉ SSL là gì.

Nguồn tham khảo