Không, bạn không thể tin tưởng mạng lưới chọn ra một lối path được.
Các rơ-le hiểm độc có thể định tuyến bạn thông qua lũ bạn bè thông đồng của chúng.
Điều này sẽ mang lại cho đối phương khả năng theo dõi được tất cả các lưu lượng traffic của bạn cả đầu và cuối end-to-end.
Điều này có thể trở nên tiện lợi bởi một số các lý do:
Nó có thể làm cho Tor trở nên tốt hơn trong việc xử lý các giao thức mới như là VoIP.
Nó có thể giải đáp cho toàn bộ nhu cầu được socks-hoá các ứng dụng.
Các rơ-le đầu ra exit cũng sẽ không cần phải chỉ định nhiều những bộ mô tả descriptor tập tin cho tất cả các kết nối đầu ra exit.
Chúng ta đang đi theo đường lối này. Một số các vấn đề khó đó là:
Các gói packet IP tiết lộ các đặc điểm của Hệ điều hành.
Chúng ta sẽ vẫn cần phải thực hiện bình thường hoá gói packet ở cấp độ IP, để dừng hẳn những điều như là các cuộc tấn công dấu vết fingerprinting TCP.
Cứ cho sẵn mức độ đa dạng và phức tạp của các stack TCP, cùng với các cuộc tấn công dấu vết fingerprinting của thiết bị, nó có vẻ như màn đặt cược tốt nhất của chúng ta đó chính là gửi đi chính stack TCP không-gian-người-dùng của chính chúng ta.
Các dòng Stream ở cấp độ ứng dụng vẫn cần phải được dọn dẹp.
Chúng ta sẽ vẫn cần có các ứng dụng hướng-về-người-dùng như là Torbutton.
Do đó nó sẽ không trở thành chỉ là một vấn đề về việc bắt lấy các gói packet và ẩn danh hoá chúng tại lớp layer IP.
Một số giao thức protocol nhất định sẽ vẫn để lộ rò rỉ thông tin.
Ví dụ, chúng ta phải viết lại các yêu cầu DNS để cho chúng được giao vận tới máy chủ DNS không thể bị liên kết được, hơn là máy chủ DNS tại một nhà cung cấp dịch vụ Internet ISP của người dùng; do đó, chúng ta cần phải hiểu được các giao thức protocol mà chúng ta đang transport vận chuyển.
DTLS (datagram TLS) về mặt cơ bản là không có người dùng, và IPsec nhất định là rộng lớn rồi.
Một khi chúng ta đã chọn ra cơ cấu transport vận chuyển, chúng ta cần phải thiết kế một giao thức protocol Tor hai đầu end-to-end mới để phòng tránh các cuộc tấn công dán nhãn tagging và các vấn đề ẩn danh và toàn vẹn tiềm năng khác hiện nay mà chúng ta cho phép thả drop, gửi lại, v.v...
Các chính sách quy tắc quy định đầu ra exit cho các gói packet IP bất kỳ có nghĩa là xây dựng một Hệ thống Phát hiện Xâm nhập (IDS - Intrusion Detection System) bảo mật.
Các điều hành viên nút giao nói cho chúng tôi rằng các chính sách quy định đầu ra exit là một trong số các lý do chính yếu mà họ sẵn lòng chạy Tor.
Việc thêm một IDS vào để xử lý các chính sách quy định đầu ra exit sẽ làm tăng thêm độ phức tạp an ninh của Tor, và nó có khả năng sẽ chẳng hoạt động dù sao chăng nữa, như được chỉ ra bởi toàn bộ ngành về IDS và các bài báo chống-IDS.
Có nhiều các vấn đề về lạm dụng tiềm năng được giải quyết bằng sự thật rằng, Tor chỉ transport vận chuyển các dòng stream TCP hợp lệ (trái ngược với IP bất kỳ, bao gồm cả các gói packet không đúng dạng và các dòng flood IP.)
Các chính sách quy định đầu ra exit trở nên ngày càng quan trọng hơn khi chúng ta trở nên có thể transport vận chuyển các gói packet IP.
Chúng ta cũng cần phải mô tả một cách ngắn gọn các chính sách quy định đầu ra exit trong thư mục Tor, để cho các ứng dụng/máy khách có thể tiên liệu được các nút giao nào sẽ cho phép các gói packet của chúng được thoát ra.
Các máy khách cũng cần phải dự đoán được tất cả các gói packet mà chúng sẽ muốn gửi đi trong một phiên session trước khi lựa chọn ra nút giao đầu ra exit của chúng!
Các khoảng trống của tên-nội-bộ-Tor có thể sẽ cần phải được thiết kế lại.
Chúng tôi hỗ trợ các địa chỉ dịch vụ onion có chứa ".onion" bằng cách đánh chặn các địa chỉ khi chúng được chuyền tới ứng dụng/máy khách Tor.
Việc thực hiện điều này ở cấp độ IP sẽ yêu cầu một giao diện phức tạp hơn giữa Tor và bộ giải mã resolver DNS cục bộ.
Cũng là một điều tốt khi để các điều hành viên rơ-le nêu những điều kiểu như reject www.slashdot.org trong các chính sách quy định đầu ra exit của họ, hơn là yêu cầu chúng phải biết được tất cả không gian địa chỉ IP mà có thể được bao phủ bởi trang web (và rồi cũng chặn block các trang web khác tại các địa chỉ IP đó).
Mặc dù vậy, vẫn có hai vấn đề.
Đầu tiên, người dùng vẫn có thể vượt qua được các khoá chặn block này.
Ví dụ, họ có thể yêu cầu địa chỉ IP thay vì tên máy chủ hostname khi họ thoát ra khỏi mạng lưới Tor Network.
Điều này có nghĩa là các vận hành viên sẽ vẫn cần phải biết được tất cả các địa chỉ IP cho các điểm đến bị nghi vấn.
Vấn đề thứ hai đó là nó sẽ cho phép các kẻ tấn công từ xa thực hiện việc kiểm duyệt các trang web tuỳ ý.
Ví dụ, nếu một điều hành viên Tor chặn block www1.slashdot.org, và sau đó một số kẻ tấn công đầu độc DNS của rơ-le Tor hoặc thay vào đó thay đổi tên máy chủ hostname để giải mã địa chỉ IP cho một trang web tin tức lớn, rồi sau đó một cách bất ngờ, rơ-le Tor đó cũng đang chặn trang web tin tức ấy.
Việc yêu cầu mỗi một người dùng Tor trở thành một rơ-le sẽ có thể trợ giúp việc mở rộng mạng lưới để có thể xử lý giúp tất cả người dùng của chúng ta, và việc chạy một rơ-le Tor có thể có ích cho tính ẩn danh của bạn.
Dù sao thì, có nhiều người dùng Tor không thể trở thành các rơ-le tốt — ví dụ, một số máy khách Tor vận hành từ đằng sau các tường lửa hạn chế, kết nối thông qua modem, hoặc ngoài ra có thể không ở một vị trí tốt mà họ có thể chuyển tiếp rơ-le lưu lượng traffic.
Việc cung cấp dịch vụ tới các ứng dụng/máy khách này là một phần trọng yếu của việc cung cấp bảo mật ẩn danh hiệu quả cho tất cả mọi người, vì có nhiều người dùng Tor là đối tượng của những sự áp chế, giới hạn tương tự và việc bao gồm những máy khách này sẽ gia tăng kích thước của tập hợp nhóm ẩn danh.
Dẫu vậy, chúng tôi thực sự mong muốn động viên việc người dùng Tor chạy các rơ-le, do đó, điều mà chúng tôi muốn thực hiện đó là đơn giản hoá quá trình cài đặt và bảo trì một rơ-le.
Chúng tôi đã thực hiện được nhiều tiến độ với cấu hình đơn giản trong một vài năm qua: Tor khá là tốt trong việc tự động xác định, điều tra ra liệu nó có khả năng được truy cập tới hay không và có bao nhiêu băng thông mà nó có thể đề nghị cung cấp.
Trước khi có thể làm điều này, có bốn bước mà chúng ta cần phải sắp xếp giải quyết:
Trước tiên, chúng ta vẫn cần phải làm tốt hơn trong việc tự động ước lượng số lượng băng thông đúng đắn để cho phép.
Điều đó có thể là việc chuyển đổi sang transport vận chuyển UDP chính là câu trả lời đơn giản nhất tại đây — ơn trời, nó cũng chẳng phải là một câu trả lời dễ dàng gì.
Thứ hai, chúng ta cần nghiên cứu về khả năng mở rộng, đồng thời của cả mạng lưới (làm thế nào để ngừng yêu cầu rằng, tất cả các rơ-le Tor có khả năng kết nối tới tất cả các rơ-le Tor) và của cả thư mục (làm thế nào để ngừng yêu cầu rằng, tất cả các người dùng Tor biết về tất cả các rơ-le Tor).
Các thay đổi như thế này có thể có ảnh hưởng rộng lớn tới tính ẩn danh tiềm năng và thực tế.
Hãy xem Mục 5 của bài viết Các thử thách để biết thêm các chi tiết.
Transport vận chuyển UDP cũng có thể giúp ích tại đây.
Thứ ba, chúng ta cần phải hiểu rõ hơn các nguy cơ từ việc để cho kẻ tấn công gửi lưu lượng traffic thông qua rơ-le của bạn trong khi bạn cũng đang bắt đầu khởi chạy lưu lượng traffic đã ẩn danh hoá của chính bạn.
Ba nghiên cứu khác nhau mô tả các cách thức để nhận diện các rơ-le trong một mạch nối bằng cách chạy lưu lượng traffic thông qua các rơ-le ứng viên và tìm kiếm các dấu hiệu bất thường trong khi mạch nối đang hoạt động.
Các cuộc tấn công áp đảo gây tắc nghẽn này là không hề đáng sợ chút nào trong bối cảnh đối với Tor một khi các rơ-le không phải cũng là các máy khách.
Nhưng nếu chúng ta cũng đang cố gắng vận động nhiều máy khách hơn nữa để bật kích hoạt tính năng rơ-le (kể cả là như các rơ-le cầu Bridge hoặc như các rơ-le thông thường), thì chúng ta cần phải hiểu được mối nguy cơ này tốt hơn và tìm hiểu cách làm thế nào để giảm bớt chúng.
Thứ tư, chúng ta có lẽ cần một số kiểu kế hoạch khuyến khích để cổ động người dùng chuyển tiếp rơ-le lưu lượng traffic cho mọi người khác, và/hoặc trở thành các nút giao đầu ra exit.
Đây là những suy nghĩ hiện tại của chúng tôi về các ưu đãi khích lệ Tor.
Xin hãy giúp đỡ về tất cả những điều này!