Tại sao sử dụng HTTPS trong Giao thức DP-3T?
Tôi đang thảo luận về tính minh bạch của giao thức HTTPS đối với một ứng dụng phát hiện COVID-19 cụ thể. Các đối thủ cho rằng việc sử dụng HTTPS đang làm xáo trộn ứng dụng, rằng ứng dụng phải hoạt động minh bạch và gửi tất cả lưu lượng truy cập qua HTTP để họ có thể thấy những gì họ đang gửi, vì dữ liệu dù sao cũng là "ẩn danh".
Sau một số điều tra, tôi phát hiện ra rằng phần này đang tuân thủ nghiêm ngặt giao thức DP-3T , trong đó nói rằng "Ứng dụng mở kết nối TLS được mã hóa tới máy chủ và gửi mã ủy quyền [...]". Tôi biết chắc chắn rằng họ đã không đọc toàn bộ giao thức (tôi cũng vậy, chỉ một số phần của nó), nhưng ngay cả khi nghĩ đến điều này, họ tiếp tục nói rằng không có lý do gì để không bắt đầu sử dụng HTTP thuần túy bằng cách loại bỏ HTTPS. Họ đi xa hơn và nói rằng nếu nó xuất hiện trong giao thức, thì nó được thiết kế tồi.
Vậy lý do nào để sử dụng HTTPS trong một giao thức ẩn danh như DP-3T?
Trả lời
Kết nối TLS có 3 thuộc tính quan trọng, riêng biệt:
- quyền riêng tư, tức là bảo vệ chống nghe trộm
- xác thực, để đảm bảo các bên giao tiếp thực sự là người mà họ giả vờ là
- tính toàn vẹn, nghĩa là không thể sửa đổi dữ liệu trong quá trình truyền
Có vẻ như các đối thủ của bạn chỉ tranh luận chống lại cái đầu tiên, nhưng hai cái còn lại rất quan trọng đối với hầu hết các ứng dụng. Đặc biệt, đối với DP-3T, việc thiếu xác thực có nghĩa là kẻ tấn công có thể chặn đường truyền và đánh rơi nó trong khi ứng dụng nghĩ rằng mã đã được truyền thành công.
Và nói chung, TLS ngày nay rẻ và dễ cài đặt. Bạn sẽ cần một lý do chính đáng để không sử dụng nó hơn là một lý do để sử dụng nó. Trên thực tế, ít nhất là đối với iOS, yêu cầu rõ ràng rằng một ứng dụng sử dụng bảo mật truyền tải và các trường hợp ngoại lệ phải được biện minh.
Cùng với việc tội phạm mạng sẵn sàng nghe lén qua mạng không dây, các mạng phức tạp ngày nay thường mang một số lượng lớn các hộp trung gian giám sát khác nhau cho các mục đích khác nhau . Những thiết bị đó không chỉ nghe trộm mà đôi khi có thể sửa đổi dữ liệu được truyền theo những cách tùy ý, cố ý hoặc vô ý.
Ví dụ: thiết bị DPI do ISP lắp đặt có thể được thiết lập để thay thế quảng cáo trang Web bằng quảng cáo của ISP. Nếu được định cấu hình sai, thiết bị này sau đó cũng sẽ thay thế các phần không liên quan của mã Javascript hoặc XML trong các luồng dữ liệu được truyền bởi các ứng dụng di động hoặc các trang web.
Đây chỉ là một ví dụ.
Do đó, mô hình mối đe dọa hiện đại đối với các trang Web và ứng dụng dành cho thiết bị di động chỉ giả định HTTPS được mã hóa là phương tiện truyền tải. Ngày nay, HTTPS khá dễ thiết lập, nó miễn phí và loại bỏ một số lượng lớn các mối đe dọa không rõ ràng và phức tạp cũng như các lỗi tiềm ẩn đến mức dễ dàng và đáng tin cậy hơn nhiều - từ quan điểm hoạt động - để thiết lập nó hơn là không.
Các đối thủ cho rằng việc sử dụng HTTPS đang làm xáo trộn ứng dụng, rằng ứng dụng phải hoạt động minh bạch và gửi tất cả lưu lượng truy cập qua HTTP để họ có thể thấy những gì họ đang gửi, vì dữ liệu dù sao cũng là "ẩn danh".
Tôi sẽ giả định rằng "họ" in đậm đề cập đến người dùng cuối chứ không phải các nhà phát triển (vì nếu nó đề cập đến các nhà phát triển, thì đây là một vấn đề đơn giản của việc không sử dụng các kỹ thuật gỡ lỗi thích hợp như ghi nhật ký phía máy chủ ).
Trên thực tế, có bao nhiêu người dùng cuối của bạn sẽ chạy Wireshark hoặc một phần mềm tương tự? Trong số những người đủ thành thạo kỹ thuật để chạy Wireshark, có bao nhiêu người nghiêm túc nhận thấy lưu lượng truy cập HTTPS đáng ngờ? Nó có thể là giao thức phổ biến thứ hai (lớp 7) trên thế giới (sau SMTP, tôi có xu hướng tưởng tượng) và như bạn nói, giao thức DP-3T yêu cầu rõ ràng việc sử dụng nó. Bất kỳ ai cảm thấy nghi ngờ đều không biết đủ về công nghệ mạng để sử dụng Wireshark ngay từ đầu. Theo tôi, việc sử dụng HTTP không an toàn có nhiều khả năng gây ra sự nghi ngờ hơn là sử dụng HTTPS.
Mặt khác, bạn hoàn toàn có thể ẩn dữ liệu trong các luồng mạng không được mã hóa bằng cách sử dụng bất kỳ hình thức ẩn ký nào khác nhau (trong trường hợp này, bằng cách ẩn một số dữ liệu trong các ID tạm thời "ngẫu nhiên" được sử dụng bởi DP-3T và / hoặc trong khóa bí mật khi nó được tải lên cho một báo cáo lây nhiễm; cả hai đều là những đốm màu mờ của dữ liệu nhị phân không có cấu trúc có ý nghĩa để người dùng xem xét bên trong). Vì vậy, thực tế là người dùng cuối kỹ thuật có khả năng giám sát lưu lượng truy cập của ứng dụng của bạn không thực sự giúp ích nhiều cho sự tin tưởng.
Trong mọi trường hợp, chúng ta có thể thấy rõ rằng:
- Điều này không thuyết phục được người dùng không chuyên về kỹ thuật.
- Nó không có khả năng hiệu quả trong việc thuyết phục người dùng kỹ thuật rằng ứng dụng của bạn an toàn và có thể thuyết phục họ rằng ứng dụng của bạn không an toàn hoặc ít nhất là được thiết kế kém.
- Như được mô tả trong nhiều câu trả lời khác, TLS thực hiện những việc khác ngoài tính bảo mật và điều đó có thể ảnh hưởng đến tính bảo mật của việc triển khai của bạn theo những cách khác.
Ngoài những điểm xuất sắc được đưa ra trong các câu trả lời khác, chỉ mã hóa dữ liệu mà quyền riêng tư là mối quan tâm cho kẻ thù biết rằng đây là dữ liệu cần quan tâm đến quyền riêng tư và cho phép họ tập trung nỗ lực vào việc giải mã dữ liệu này.
Nói cách khác, ngay cả khi quyền riêng tư là mối quan tâm duy nhất của bạn, bạn nên mã hóa mọi thứ để kẻ thù không biết phải tìm ở đâu. Điều đó có nghĩa là sử dụng HTTPS, thay vì HTTP, nếu có.
Đây là một tài liệu tham khảo tôi tìm thấy. Mặc dù nó là về các giao thức khác nhau, nhưng ý tưởng cơ bản là giống nhau. Tự vệ qua e-mail :
Bạn càng có thể mã hóa nhiều tin nhắn của mình thì càng tốt. Nếu bạn chỉ mã hóa email thỉnh thoảng, mỗi tin nhắn được mã hóa có thể giương cao cờ đỏ cho các hệ thống giám sát. Nếu tất cả hoặc hầu hết email của bạn được mã hóa, những người làm giám sát sẽ không biết bắt đầu từ đâu.