Địa điểm để xem là tiêu chuẩn được đề xuất TURN, RFC 5766. Tiêu chuẩn cung cấp một phương tiện để chuyển tiếp các gói UDP chứa dữ liệu ứng dụng giữa một máy khách và một peer:
Khi đã tạo xong, máy khách có thể gửi dữ liệu ứng dụng đến máy chủ cùng với dấu hiệu ngang hàng dữ liệu sẽ được gửi và máy chủ sẽ chuyển tiếp dữ liệu này tới đồng đẳng phù hợp. Máy khách gửi dữ liệu ứng dụng đến máy chủ bên trong tin nhắn TURN; tại máy chủ, dữ liệu được trích xuất từ tin nhắn TURN và được gửi tới peer trong một gói dữ liệu UDP. Theo hướng ngược lại, một peer có thể gửi dữ liệu ứng dụng trong một datagram UDP đến địa chỉ truyền tải chuyển tiếp cho việc phân bổ; sau đó máy chủ sẽ đóng gói dữ liệu này bên trong tin nhắn TURN và gửi nó cho khách hàng cùng với một dấu hiệu cho biết bạn đã gửi dữ liệu nào.
Lớp cao nhất TURN phân tích là lớp UDP. Nó không hiểu hoặc sửa đổi lớp dữ liệu ứng dụng (trong trường hợp của bạn, giao thức WebRTC). Tiêu chuẩn cho biết:
Ứng dụng có nhu cầu đảm bảo dữ liệu của nó không bị thay đổi hoặc giả mạo phải bảo vệ toàn vẹn dữ liệu ở cấp ứng dụng.
Điều này ngụ ý rằng bạn có thể bảo vệ toàn vẹn dữ liệu ứng dụng của bạn và TẮT sẽ chuyển tiếp mà không sửa đổi. Bạn cũng có thể xem các chi tiết của giao thức TURN (mà tôi sẽ không lặp lại ở đây) cho thấy nó chỉ đơn thuần là kết thúc tốt đẹp và chuyển tiếp dữ liệu ứng dụng.
Cuối cùng, tiêu chuẩn nói trên nghe trộm:
bảo mật cho dữ liệu ứng dụng chuyển tiếp bằng cách lần lượt là tốt nhất được cung cấp bởi các giao thức ứng dụng riêng của mình, vì chạy Lật TLS không bảo vệ dữ liệu ứng dụng giữa máy chủ và máy ngang hàng . Nếu tính bảo mật của dữ liệu ứng dụng là quan trọng, thì ứng dụng sẽ mã hóa hoặc bảo vệ dữ liệu của nó.Ví dụ: , đối với phương tiện truyền thông thời gian thực, bảo mật có thể được cung cấp bởi bằng SRTP.
Đề xuất trong trích đoạn này là để bảo vệ tính bảo mật bằng cách mã hóa dữ liệu ứng dụng bằng giao thức như DTLS-SRTP, mà WebRTC sử dụng.
Vì TURN không giải thích hoặc sửa đổi dữ liệu ứng dụng, nó không thêm bất kỳ lỗ hổng bảo mật nào cho lưu lượng dữ liệu ứng dụng WebRTC không có mặt mà không sử dụng TURN. Dữ liệu WebRTC được mã hóa giữa các điểm cuối WebRTC.
Bây giờ, không ai có thể đảm bảo rằng không có cách nào cho máy chủ TURN truy cập vào bí mật. " Một máy chủ TURN giả mạo có thể cố gắng tấn công người trung gian trên kết nối của bạn cũng dễ dàng như bất kỳ ai khác có thể chặn các gói mạng của bạn. Chỉ đúng khi sử dụng rơle TURN không làm suy yếu bảo mật WebRTC.
Miễn là DTLS được triển khai và sử dụng đúng cách và giả sử thuật toán và mật mã DTLS an toàn, lưu lượng truy cập WebRTC phải được bảo mật từ đầu đến cuối. Một phần của việc sử dụng bất kỳ chương trình dựa trên SSL nào yêu cầu xác minh chứng chỉ của điểm cuối khác, giống như HTTPS. Và cũng giống như HTTPS, điều này sẽ yêu cầu trao đổi nhận dạng chứng nhận ngoài băng tần trước đó hoặc sử dụng một bên thứ ba đáng tin cậy. Và cũng giống như HTTPS, nếu chứng chỉ không được xác minh chính xác thì cửa sẽ mở cho một cuộc tấn công MITM (bởi bất kỳ ai, không chỉ các máy chủ TURN).
Câu trả lời này chắc chắn đi đúng hướng. Rõ ràng, việc mã hóa phải được thực hiện ở lớp ứng dụng, để mã hóa đầu cuối hoạt động. Nhưng 1. Tôi không chắc chắn 100%, nếu "Lớp cao nhất TURN phân tích là lớp UDP.": Có các tùy chọn dtls và tls trong https://code.google.com/p/rfc5766-turn-server/wiki/máy chủ. Và 2. Tôi không chắc chắn 100%, nếu WebRTC thực hiện trao đổi khóa cho DTLS với máy chủ TURN hoặc với máy khách khác. Tôi đã không tìm thấy bất cứ điều gì về điều đó trong spec WebRTC. –
@ChrisLercher, Bản thân giao thức TURN có thể được bảo vệ bởi TLS hoặc DTLS cho kết nối giữa máy khách và máy chủ (TLS được cho phép trong RFC 5766; DTLS là một sự nâng cao rõ ràng). Mã hóa này gói gọn lưu lượng giữa máy khách và máy chủ và trên đầu trang của bất kỳ mã hóa nào trong lớp ứng dụng. Trong mã nguồn mở, mô tả về các tùy chọn '--no-tls' và' --no-dtls' (được định nghĩa trong mainrelay.c, được sử dụng trong netengine.c) thực sự nói rằng điều này áp dụng cho * trình nghe khách *, chỉ ra các ổ cắm cho lớp giao thức TURN. – rhashimoto
@ChrisLercher, WebRTC không chỉ định bắt tay DTLS vì đó là một phần của DTLS. DTLS chỉ là phiên bản TLS được UDP nhúng, vì vậy nó có thể đảm bảo mã hóa đầu cuối. Nhưng cũng giống như HTTPS, nó chỉ hoạt động nếu bạn xác minh chứng chỉ của đồng đẳng - nếu không, bạn có thể sử dụng tấn công MITM. Và, giống như HTTPS, việc triển khai WebRTC phải kiểm tra chứng chỉ để bảo mật. Điều này được đề cập trong phần 8.3.5 của dự thảo W3C: Chờ tất cả các kết nối DTLS được thiết lập và kiểm tra xem dấu vân tay chứng chỉ trên tất cả các kết nối có khớp với kết nối được cung cấp bởi IdP hay không. – rhashimoto