Mã hóa đầu cuối là một lớp bảo vệ bổ sung, không phải lý do để bỏ qua cảnh báo TLS hoặc tin vào mã đã bị sửa đổi.
TLS và mã hóa đầu cuối tạo ra hai ranh giới khác nhau. Những ranh giới này cũng quan trọng khi đánh giá VPN và proxy. TLS thường bảo vệ kết nối giữa thiết bị của bạn và dịch vụ; mã hóa đầu cuối được triển khai đúng và có xác thực bảo vệ nội dung cuộc trò chuyện đến tận thiết bị của người nhận. Đọc được lớp TLS không nhất thiết đồng nghĩa với việc đọc được nội dung mã hóa đầu cuối, nhưng không thể từ đó kết luận rằng bảo mật TLS không còn quan trọng.
Nếu một bên trung gian có thể kết thúc kết nối bảo mật, họ có thể không chỉ xem dữ liệu truyền đi mà còn sửa đổi phản hồi hoặc mã của ứng dụng web. Vì vậy, “vượt qua TLS bằng LVR1” không phải là cách mô tả phù hợp về bảo mật của một ứng dụng nhắn tin.
Chứng chỉ gốc cho phép kiểm tra như thế nào?
Trong kết nối HTTPS, thiết bị kiểm tra chuỗi chứng chỉ của máy chủ và tên máy chủ. Nếu bên trung gian đưa ra một chứng chỉ mà ứng dụng coi là hợp lệ, họ có thể tạo hai kết nối riêng biệt: một với người dùng và một với máy chủ thật. Khi đó, bên trung gian là điểm kết thúc của một trong các kết nối TLS, chứ không phải kẻ nghe lén đã phá được mã hóa chỉ bằng cách nhìn vào các gói tin.
Chỉ cài đặt một chứng chỉ tùy ý là chưa đủ; ứng dụng phải tin cậy chứng chỉ đó và các bước kiểm tra kết nối cũng phải được chấp nhận. Tài liệu cấu hình bảo mật mạng của Android giải thích rằng chính sách tin cậy có thể khác nhau giữa các ứng dụng. Các ứng dụng nhắm đến Android 7.0 trở lên mặc định không tin cậy chứng chỉ do người dùng thêm vào, trừ khi có cấu hình khác.
Đây là một cơ chế kỹ thuật chung. Không có bằng chứng thì không thể dựa vào đó để kết luận về một nhà mạng, quốc gia hay sự cố cụ thể. Chỉ riêng tình trạng gián đoạn hoặc lọc lưu lượng không chứng minh rằng việc kiểm tra TLS đã thành công.
Khi TLS được mở ra, có thể thấy những gì?
| Loại dữ liệu hoặc tình huống | Hệ quả có thể có của việc kiểm tra TLS |
|---|---|
| Nội dung chỉ được HTTPS bảo vệ | Bên trung gian được tin cậy có thể thấy văn bản rõ |
| Tin nhắn đã được mã hóa bằng khóa hợp lệ của người nhận | Bên trung gian thường thấy bản mã, không phải nội dung tin nhắn |
| Dữ liệu định tuyến, phiên hoặc các yêu cầu phụ | Mức độ lộ thông tin phụ thuộc vào định dạng và thiết kế của dịch vụ |
| Mã của phiên bản web được chuyển qua cùng tuyến đường | Việc sửa đổi mã có thể đe dọa bảo mật của thiết bị đầu cuối |
| Dịch vụ không truy cập được hoặc lưu lượng bị chặn | Chỉ riêng mã hóa không thiết lập được kết nối |
Khả năng bảo vệ nội dung của E2EE cũng phụ thuộc vào tính xác thực của khóa người nhận và tính toàn vẹn của phần mềm ở cả hai phía. Nếu kẻ tấn công thay thế khóa ban đầu hoặc sửa đổi ứng dụng có thể nhìn thấy tin nhắn trước khi mã hóa, chỉ có AES hay ML-KEM là chưa đủ.
Vì sao phiên bản web cần TLS an toàn?
Ứng dụng web thường nhận mã thực thi từ máy chủ. Nếu mã đó độc hại, nó có thể truy cập nội dung trước khi mã hóa hoặc sau khi giải mã. Không thể đánh giá mã hóa đầu cuối tách rời cách mã được phân phối và thực thi.
Với phiên bản được cài đặt, tính xác thực của gói phần mềm, các bản cập nhật và tính toàn vẹn của hệ điều hành cũng quan trọng. Chữ ký gói và kiểm tra giá trị băm có ích, nhưng không phải là phép kiểm tra toàn diện về bảo mật ứng dụng. Mô hình mối đe dọa của Livara cũng nêu rằng nếu kẻ tấn công thay đổi cả tệp và giá trị băm được hiển thị, việc giá trị băm khớp nhau tự nó không chứng minh được tính xác thực.
Livara đưa ra những tuyên bố gì?
Theo tài liệu bảo mật của Livara, tin nhắn trực tiếp dùng LVR1 và các nhóm riêng tư tương thích dùng LGS1. Tài liệu mô tả sự kết hợp giữa P-256 và ML-KEM-768 cùng việc mã hóa nội dung tin nhắn. Những mô tả này là tuyên bố của sản phẩm, không phải kết quả kiểm toán độc lập trong bài viết này.
Cùng trang đó cũng nói rõ rằng siêu dữ liệu định tuyến được giữ lại và các kênh phát hành là công khai. Vì vậy, kết luận đúng không phải là “mọi thông tin đều được che giấu” hay “không cần bất kỳ sự tin cậy nào đối với mạng”. Kết luận là cần xem xét việc bảo vệ nội dung riêng tư tách biệt với kết nối, phân phối khóa, mã ứng dụng và siêu dữ liệu.
Nên làm gì khi có cảnh báo chứng chỉ?
- Đừng bỏ qua cảnh báo của trình duyệt hoặc ứng dụng để tiếp tục một cuộc trò chuyện nhạy cảm.
- Kiểm tra ngày trên thiết bị và địa chỉ chính xác của dịch vụ; không phải lỗi chứng chỉ nào cũng là một cuộc tấn công.
- Nếu đó là thiết bị của tổ chức, hãy hỏi quản trị viên có thẩm quyền về chính sách quản lý và các chứng chỉ đã cài đặt; đừng tự ý thay đổi những cài đặt được quản lý.
- Đừng cài đặt chứng chỉ hoặc hồ sơ cấu hình chỉ vì một tin nhắn không rõ nguồn gốc yêu cầu.
- Trong các cuộc trò chuyện nhạy cảm, hãy đối chiếu dấu vân tay của khóa với người liên hệ qua một kênh độc lập; việc đối chiếu khóa không thay thế cho việc xử lý cảnh báo TLS.
Câu hỏi thường gặp
VPN có giải quyết được tất cả những vấn đề này không?
Không. VPN có thể thay đổi tuyến đường nơi lưu lượng bị quan sát, nhưng không tự động khắc phục thiết bị nhiễm mã độc, chứng chỉ độc hại được tin cậy hoặc mã web đã bị sửa đổi.
Xác thực mà không gửi mật khẩu đã đủ chưa?
Chưa. Giao thức xác thực, quản lý phiên và mã hóa tin nhắn đảm nhiệm những chức năng khác nhau. Một trang đăng nhập giả hoặc mã độc có thể lấy chính dữ liệu người dùng nhập trước khi giao thức được thực thi.
Nguyên tắc thực tế: E2EE là một lớp bảo vệ có giá trị; đừng coi đó là lý do để bỏ qua chứng chỉ, tính xác thực của ứng dụng hay việc xác minh khóa.
