إن اشتراط أن يكون كل مستخدم لـ تور مُرحّلا من شأنه أن يساعد على توسيع نطاق الشبكة للتعامل مع جميع مستخدمينا، و قد يساعد تشغيل مُرحّل تور على إخفاء هويتك.
ومع ذلك، لا يمكن أن يُشكّل العديد من مستخدمي تور مُرحّلات جيدة — على سبيل المثال، يعمل بعض عملاء تور من وراء جدران حماية مقيدة، أو الاتصال عبر جهاز المودِم، أو بالأحرى ليسوا في وضع يمكنهم من خلاله ترحيل حركة المرور.
يعد توفير الخدمة لهؤلاء العملاء جزءا مهما من توفير إخفاء هوية فعال للجميع، نظرا لأن العديد من مستخدمي تور يخضعون لهذه القيود أو ما شابهها، كما أن إدراج هؤلاء العملاء يزيد من كمية عناصر المجموعة التي ستقوم بإخفاء الهويات.
بعد قول هذا، نريد تشجيع مستخدمي تور على تشغيل المُرحّلات، لذلك ما نريد فعله حقا هو تبسيط عملية إعداد المُرحّل وصيانته.
لقد أحرزنا تقدما كبيرا من خلال التهيئة السهلة في السنوات القليلة الماضية: تور جيد في الكشف التلقائي عما إذا كان يمكن الوصول إليه ومدى سعة القناة التي يمكن أن يقدمها.
هناك أربع خطوات نحتاج إلى معالجتها قبل أن نتمكن من القيام بذلك على الرغم من:
أولا، ما زلنا بحاجة إلى التحسين في تقدير المقدار الصحيح لسعة القناة تلقائيا للسماح به.
قد يكون التبديل إلى النقل عبر UDPهو أبسط إجابة هنا — إذ للأسف ليست إجابة بسيطة على الإطلاق.
ثانيا، نحتاج إلى العمل على قابلية التوسع، لكل من الشبكة (كيفية التوقف عن طلب أن تكون جميع مُرحّلات تور قادرة على الاتصال بجميع مُرحّلات تور) والدليل (كيفية التوقف عن مطالبة جميع مستخدمي تور بمعرفة جميع مُرحّلات تور ).
يمكن أن يكون لتغييرات كهذه تأثير كبير على إخفاء الهوية المحتملة والفعلية.
راجع القسم 5 من ورقة التحديات للحصول على التفاصيل.
مرة أخرى، سيساعد نقل UDP هنا.
ثالثا، نحتاج إلى فهم أفضل للمخاطر الناتجة عن السماح للمهاجم بإرسال حركة المرور عبر مُرحّلك بينما تقوم أيضا ببدء حركة مرورك لتكون مجهولة المصدر.
تشرح ثلاثة أوراق البحثية مختلفة طرقا لتحديد المُرحّلات في المسار عن طريق تشغيل حركة المرور من خلال المُرحّلات المُرشَّحة والبحث عن الانخفاضات في حركة المرور أثناء اشتغال المسار.
لا تعتبر هجمات الانسداد هذه مخيفة في سياق تور طالما أن المُرحّلات لا تقوم بدور العملاء أيضا.
ولكن إذا كنا نحاول تشجيع المزيد من العملاء على تشغيل وظيفة الترحيل أيضا (سواء كانت مُرحّلات الجسرأو كمُرحّلات عادية)، فنحن بحاجة إلى فهم هذا التهديد بشكل أفضل وتعلم كيفية التخفيف منه.
رابعا، قد نحتاج إلى نوع من نظام الحوافز لتشجيع الناس على نقل حركة المرور للآخرين، أو أيضا أن يصبحوا عقدا خروج.
إليك أفكارنا الحالية حول حوافز تور.
ساعدنا على القيام بكل ذلك!
سيكون من الجيد السماح للمكلفين بتشغيل مُرحّل بقول أشياء مثل رفض www.slashdot.org في سياسات خروجهم، بدلا من مطالبتهم بمعرفة مجالات عناوين IP التي يمكن أن يغطيها الموقع (ثم حظر المواقع الأخرى أيضا على تلك العناوين IP).
ومع ذلك، هناك مشكلتان.
أولاً، لا يزال بإمكان المستخدمين تجاوز هذا الحجب.
على سبيل المثال، يمكنهم طلب عنوان IP بدلا من اسم المضيف عند الخروج من شبكة تور.
هذا يعني أن المكلفين بتشغيله سيظلون بحاجة إلى معرفة جميع عناوين IP للوجهات المعنية.
المشكلة الثانية هي أنه سيسمح للمهاجمين عن بعد بحظر المواقع الاعتباطية.
على سبيل المثال، إذا قام المكلف بتشغيل تور بحظر www1.slashdot.org، ثم قام بعض المهاجمين بالتشويش على المُرحّل DNS الخاص بِتور أو قام بتغيير اسم المضيف بطريقة أخرى لإعطاء عنوان IP الخاص بموقع إخباري رئيس، ثم فجأة يقوم مُرحّل تور بحظر موقع الأخبار.
لا، لا يمكنك الوثوق بالشبكة لاختيار المسار.
يمكن أن توجهك المُرحّلات الخبيثة عبر أصدقائها المتواطئين معها.
هذا من شأنه أن يمنح الخصم القدرة على مراقبة كل حركة مرورك من البداية إلى النهاية.
سيكون هذا مفيدا لعدد من الأسباب:
سيجعل تور أكثر قدرة على التعامل مع البروتوكولات الجديدة مثل ”نقل الصوت عبر بروتوكول الانترنت VoIP“.
يمكن أن يحل الحاجة لذلك عبر جعل التطبيقات تدعم البروتوكول SOCKS.
لن تحتاج مُرحّلات الخروجأيضا إلى تخصيص الكثير من واصفات الملفات لجميع اتصالات الخروج.
نحن نسير في هذا الاتجاه. بعض المشاكل الصعبة هي:
تكشف حزم IP عن خصائص نظام التشغيل.
سنظل بحاجة إلى تطبيع الحزمة على مستوى طبقة IP، لإيقاف أشياء مثل هجمات تحديد الهوية ببصمات TCP.
نظرا لتنوع وتعقيد كومات TCP، إلى جانب الهجمات التي تتعقب بصمات الجهاز، يبدو أن أفضل رهان لدينا هو شحن كومتنا TCP الخاصة بمساحة المستخدم.
لا تزال التدفقات على مستوى التطبيق بحاجة إلى التنظيف.
سنظل بحاجة إلى تطبيقات من جانب المستخدم مثل Torbutton.
لذلك لن تصبح مجرد مسألة التقاط الحزم وإخفاء هويتها في طبقة IP.
ستستمر بعض البروتوكولات في تسريب المعلومات.
على سبيل المثال، يجب علينا إعادة كتابة طلبات بروتوكول نظام أسماء النطاقات بحيث يتم تسليمها إلى خادم نظام أسماء النطاقات غير قابل للربط بدلا من خادم نظام أسماء النطاقات في مزود خدمة الانترنت الخاص بالمستخدم؛ وعليه، يجب أن نفهم البروتوكولات التي ننقلها.
DTLS (مخطط البيانات TLS) ليس له مستخدمون بشكل أساسي، ومن المؤكد أن IPsec كبير.
بمجرد أن نختار آلية النقل، نحتاج إلى تصميم بروتوكول تور جديد شامل لتجنب هجمات وضع الوسوم (tagging attacks) وغيرها من المشاكل المحتملة لإخفاء الهوية، وكذا مشاكل النزاهة، بما أننا الآن نسمح بعمليات الإسقاط وإعادة الإرسال وما إلى ذلك.
سياسات الخروج لحزم IP الاعتباطية تعني بناء نظام آمن للكشف عن التسلل (IDS, Intrusion Detection System).
يخبرنا المكلفون بتشغيل العقد أن سياسات الخروج هي أحد الأسباب الرئيسة التي تجعلهم يرغبون في تشغيل تور.
إن إضافة ”النظام الآمن للكشف عن التسلل“ للتعامل مع سياسات الخروج من شأنه أن يزيد من تعقيد أمان تور، ومن المحتمل ألا يعمل على أي حال، كما يتضح من خلال الأوراق البحثية حول النظام الآمن للكشف عن التسلل ومضاداته.
يتم حل العديد من مشكلات التعسف في الاستخدام المحتملة من خلال حقيقة أن تور يقوم فقط بنقل تدفقات TCP الصالحة (على عكس IP الاعتباطي، بما في ذلك الحزم المشوهة والإغراق بالحزم IP).
تصبح سياسات الخروج أكثر أهمية عندما نصبح قادرين على نقل حزم IP.
نحتاج أيضا إلى وصف سياسات الخروج بشكل مُحكَم في دليل تور، بحيث يمكن للعملاء التنبؤ بالعقد التي ستسمح لحزمهم بالخروج.
يحتاج العملاء أيضًا إلى توقع جميع الحزم التي سيرغبون في إرسالها في جلسة قبل اختيار عقدة خروجهم!
يجب إعادة تصميم مساحات الاسم الداخلية لـ تور.
نحن ندعم عناوين الخدمة البصلية « onion. » من خلال اعتراض العناوين عند تمريرها إلى عميل تور.
سيتطلب القيام بذلك على مستوى طبقة IP واجهة أكثر تعقيدا بين تور ومحلل محلي لنظام أسماء النطاقات .