ملزم ساختن هر کاربر به اجرای یک رله به مقیاس‌کردن شبکه برای مدیریت همهٔ کاربران ما کمک می‌کند، همچنین اجرای یک رلهٔ Tor ممکن است به ناشناسی شما کمک کند. بااین‌حال، بسیاری از کاربران Tor نمی‌توانند رله‌های خوبی باشند — برای مثال، برخی از کلاینت‌های Tor پشت فایروال‌های محدودکننده قرار دارند، از طریق مودم وصل می‌شوند یا در هرصورت در موقعیتی نیستند که بتوانند ترافیک رله کنند. ارائهٔ خدمات به این کلاینت‌ها، بخش مهمی از فراهم نمودن ناشناسی موثر برای همه است، زیرا بسیاری از کاربران Tor با این‌ موارد یا محدودیت‌های مشابه مواجه هستند و به حساب آوردن این کلاینت‌ها، میزان ناشناسی را افزایش می‌دهد.

همان‌طور که گفته شد، ما می‌خواهیم کاربران Tor را تشویق کنیم تا رله‌ها را اجرا کنند، بنابراین آنچه واقعا خواهان انجامش هستیم تسهیل فرایند راه‌اندازی و نگهداری یک رله است. ما در چند سال گذشته با پیکربندی آسان پیشرفت زیادی را رقم زده‌ایم: Tor در تشخیص خودکار قابل‌دسترس بودن آن و میزان پهنای‌باندی که می‌تواند ارائه دهد خوب است.

با این وجود چهار مرحله وجود دارد که باید قبل از اینکه بتوانیم این کار را انجام دهیم به آن‌ها توجه کنیم :

• اول، ما هنوز باید در برآورد خودکار مقدار مناسب پهنای‌باندی که اجازه می‌دهیم بهتر شویم. ممکن است سوئیچ به انتقال UDP ساده‌ترین پاسخ در اینجا باشد - که متأسفانه اصلاً پاسخ ساده‌ای نیست.

• دوم، ما باید هم روی مقیاس‌پذیری شبکه (چگونگی توقف نیاز اتصال همهٔ رله‌های Tor به تمام رله‌های Tor) و هم مقیاس‌پذیری شاخه (چگونگی توقف نیاز به شناختن همهٔ رله‌های Tor توسط تمام کاربران Tor) کار کنیم. چنین تغییراتی می‌توانند تأثیر زیادی بر ناشناسی بالقوه و بالفعل داشته باشند. برای جزئیات بیشتر بخش ۵ مقالهٔ چالش‌ها را ببینید. باز هم، حامل UDP در اینجا کمک‌ می‌کند.

• سوم، ما باید از خطرات ارسال ترافیک مهاجم از طریق رله شما را در زمانی که خود شما نیز ترافیک ناشناس خود را راه‌اندازی کرده‌اید، آگاه شویم. سه مقاله مقاله‌های تحقیقاتی مختلف روش‌هایی را برای شناسایی رله‌ها در مدار بوسیلهٔ ارسال ترافیک از طریق رله‌های کاندید و جستجوی افت در ترافیک هنگامی که مدار فعال است، شرح می‌دهند. این حملات انسداد در Tor چندان ترسناک نیستند تا زمانی که رله‌ها هیچ‌گاه همزمان کلاینت نباشند. اما اگر می‌خواهیم کلاینت‌های بیشتری را تشویق کنیم که عملکرد رله را فعال کنند (چه به‌شکل رلهٔ پل یا به‌شکل رلهٔ معمولی)، باید این تهدید را بهتر بفهمیم و یاد بگیریم که چگونه آن را کاهش دهیم.

• چهارم، ممکن است به نوعی طرح تشویقی نیاز داشته باشیم تا مردم را تشویق کنیم که ترافیک را برای دیگران انتقال دهند و یا تبدیل به گره‌های خروجی شوند. ایده‌های فعلی ما در مورد مشوق‌های Tor را در اینجا ببینید.

لطفاً در همهٔ این زمینه‌ها کمک کنید!

خوب است که به اپراتورهای رله اجازه دهیم مواردی مانند reject www.slashdot.org را در سیاست‌های خروج خود بگویند، به‌جای این‌که از آن‌ها بخواهیم تمام فضای نشانی IP را که می‌تواند توسط وب‌سایت پوشش داده شود، یاد بگیرند (و سپس وب‌سایت‌های دیگر را در آن نشانی‌های IP مسدود کنند).

هر چند دو مشکل وجود دارد. اول، کاربران هنوز می‌توانند این بلوک‌ها را دور بزنند. برای مثال، آن‌ها هنگام خروج از شبکهٔ Tor می‌توانند نشانی IP را به جای نام میزبان درخواست کنند. این بدین معناست که اپراتورها هنوز باید تمام نشانی‌های IP را برای مقاصد مدنظر یاد بگیرند .

مشکل دوم این است که به مهاجمان راه دور اجازهٔ سانسور وب‌سایت‌های دل‌خواه را می‌دهد . برای مثال، اگر یک اپراتور Tor دامنهٔ www1.slashdot.org را مسدود کند و سپس مهاجمی DNS رلهٔ Tor را آلوده کند یا به طریقی دیگر، آن نام میزبان را تغییر دهد تا به نشانی IP یک وب‌سایت خبری بزرگ ترجمه شود، آنگاه آن رلهٔ Tor یکباره سایت خبری را مسدود می‌کند.

خیر، شما جهت انتخاب مسیر نمی‌توانید به شبکه اعتماد کنید. رله های مخرب می‌توانند شما را از طریق دوستان تبانی‌ کردهٔ خود هدایت کنند . این به متخاصم این توانایی را می‌دهد که تمام ترافیک شما را به‌صورت سرتاسر ببیند.

این کار به چند دلیل مفید خواهد بود: این باعث می‌شود Tor بتواند پروتکل‌‌های جدید مانند VoIP را بهتر مدیریت کند. این کار می‌تواند کل نیاز برنامه‌ها به استفاده از SOCKS را برطرف کند. رله‌های خروج نیز نیازی به تخصیص تعداد زیادی توصیفگر فایل برای تمامی اتصالات خروج نخواهند داشت.

ما در حال حرکت به این سو هستیم. برخی از مسائل دشوار عبارتند از:

1. بسته‌های IP ویژگی‌های سیستم‌عامل را آشکار می‌کند. ما همچنان باید نرمال‌سازی بسته‌ها در سطح IP را انجام دهیم تا مواردی مانند حملات انگشت‌نگاری TCP را متوقف سازیم. این‌طور به نظر می‌رسد که با توجه به تنوع و پیچیدگی پشته‌های TCP همراه با حملات انگشت‌نگاری دستگاه، بهترین شرط ما ارسال پشتهٔ TCP در فضای کاربری خودمان باشد.

2. جریان‌های در سطح برنامه هنوز نیاز به پاک‌سازی دارند. ما همچنان به برنامه‌های سمت کاربر مانند Torbutton نیاز خواهیم داشت. بنابراین موضوع تنها گرفتن بسته‌ها و ناشناس‌سازی آن‌ها در لایهٔ IP نخواهد بود.

3. بعضی از پروتکل‌ها همچنان اطلاعات را نشت می‌دهند. برای مثال، ما باید درخواست‌های DNS را بازنویسی کنیم تا به‌جای سرور DNS در ISP کاربر، به یک سرور DNS غیرقابل‌پیوند به کاربر رسانده شوند؛ بنابراین، ما باید متوجه باشیم که چه پروتکل‌هایی را منتقل می‌کنیم.

4. DTLS (داده‌نگار TLS) اساساً کاربر ندارد و IPsec قطعاً بزرگ است. اکنون که اجازهٔ دفع، ارسال‌های مجدد، و جز آن‌ها را می‌دهیم، همین‌که یک سازوکار حامل را انتخاب کردیم، باید یک پروتکل Tor سر-تا-سری جدید برای جلوگیری از حملات برچسب‌گذاری و سایر مشکل‌های بالقوهٔ ناشناسی و صحت طراحی کنیم.

5. سیاست‌های خروج برای بسته‌های IP اختیاری به معنای ساختن یک سامانهٔ تشخیص نفوذ امن (IDS) است. اپراتورهای گرهٔ ما به ما می‌گویند که سیاست‌های خروج، یکی از دلایل اصلی است که آن‌ها مایل به اجرای Tor هستند. افزودن یک IDS به سیاست‌های خروج، پیچیدگی امنیتی Tor را افزایش خواهد داد و به هر حال , همانطور که در کل زمینهٔ IDS و اوراق ضد IDS مشهود است، احتمالاً عملی نخواهد بود . بسیاری از مشکلات بالقوه سوء استفاده با این واقعیت حل می‌شوند که Tor تنها جریان‌های TCP معتبر را منتقل می‌کند ( برخلاف IP اختیاری شامل بسته‌های معیوب و سیل‌ IP . ) در حالی که قابلیت انتقال بسته‌های IP را پیدا می‌کنیم، سیاست‌های خروج اهمیت بیشتری پیدا می‌کنند. ما همچنین باید سیاست‌های خروج را به‌طور فشرده در شاخهٔ Tor توصیف کنیم تا کلاینت‌ها بتوانند پیش‌بینی کنند که کدام گره‌ها به بسته‌هایشان اجازه خروج می‌دهند . کلاینت‌ها همچنین باید تمام بسته‌هایی را که می‌خواهند قبل از انتخاب گرهٔ خروجی خود در یک نشست ارسال کنند، پیش‌بینی نمایند!

6. فضاهای نام داخلی Tor باید بازطراحی شوند. ما نشانی‌های سرویس پیازی «onion.» را هنگامی که به مشتری Tor ارسال می‌شوند، با رهگیری نشانی‌ها پشتیبانی می‌کنیم. انجام این کار در سطح IP به رابط پیچیده‌تری بین Tor و تحلیل‌گر DNS محلی نیاز دارد.