طرح‌های جایگزینی که (فعلا) انجام نمی‌دهیم

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

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

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

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

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

4. DTLS (Datagram TLS) اساسا کاربر ندارد و IPsec مطمئنا بزرگ است. اکنون که اجازه ارسال، ارسال مجدد، و غیره را می‌دهیم، هنگامی که مکانیزم انتقال را انتخاب کردیم، باید یک پروتکل Tor سرتاسری جدید برای جلوگیری از حملات برچسب‌گذاری و سایر مشکلات احتمالی ناشناس بودن و یکپارچگی طراحی کنیم.

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

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

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

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

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

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

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

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

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

لطفا در مورد این‌ها کمک کنید!

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

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

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

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