اقتراح لنوع نفق وكيل HTTP مستند إلى المضيف
هذا الاقتراح يهدف لحل “مشكلة الهوية المشتركة” في استخدام HTTP عبر I2P التقليدي عن طريق تقديم نوع جديد من نفق وكيل HTTP. يتمتع هذا النوع من الأنفاق بسلوك مكمل يهدف إلى منع أو تقليل فائدة التتبع الذي يقوم به مشغلي الخدمات المخفية المحتمل أن يكونوا عدائيين، ضد وكيل المستخدم المستهدف (المتصفحات) وتطبيق I2P Client نفسه.
ما هي مشكلة “الهوية المشتركة”؟
تحدث مشكلة “الهوية المشتركة” عندما يشارك وكيل المستخدم على شبكة تراكبية معنونها بشكل تشفير هوية تشفيرية مع وكيل مستخدم آخر. يحدث هذا، على سبيل المثال، عندما يتم تكوين كل من Firefox و GNU Wget لاستخدام نفس وكيل HTTP.
في هذا السيناريو، من الممكن للخادم جمع وتخزين العنوان التشفيري (الوجهة) المستخدم للرد على النشاط. يمكن أن يتم التعامل مع هذا كـ “بصمة” تكون دائمًا فريدة بنسبة 100% لأنها تنشأ من مصدر تشفيري. هذا يعني أن الربط الذي يتم ملاحظته بسبب مشكلة الهوية المشتركة هو مثالي.
لكن هل هي مشكلة؟ ^^^^^^^^^^^^^^^^^^^^
تعتبر مشكلة الهوية المشتركة مشكلة عندما يرغب وكلاء المستخدم الذين يتحدثون نفس البروتوكول في عدم الارتباط. تمت الإشارة إلى ذلك لأول مرة في سياق HTTP في هذا الموضوع على Reddit، مع الوصول إلى التعليقات المحذوفة بفضل pullpush.io. في ذلك الوقت كنت واحدًا من أكثر المستجيبين نشاطًا، وفي ذلك الوقت كنت أعتقد أن المشكلة صغيرة. خلال السنوات الثماني الماضية، تغيرت الظروف ورأيي فيها، وأنا الآن أعتقد أن التهديد الذي يشكله ربط الوجهة الخبيث يزيد بشكل كبير مع زيادة المواقع التي تسعى إلى إنشاء “بروفايل” لمستخدمين محددين.
هذا الهجوم له عتبة دخول منخفضة جدًا. يتطلب فقط أن يشغل مشغل الخدمة المخفية خدمات متعددة. بالنسبة للهجمات على الزيارات المعاصرة (زيارات متعددة في نفس الوقت)، فهذا هو المتطلب الوحيد. بالنسبة للربط غير المعاصر، يجب أن تكون إحدى تلك الخدمات هي خدمة تستضيف “حسابات” تنتمي إلى مستخدم واحد مستهدف بالتتبع.
حاليًا، أي مشغل خدمة يستضيف حسابات مستخدمين سيكون قادرًا على ربطها بالنشاط عبر أي مواقع يتحكمون فيها باستغلال مشكلة الهوية المشتركة. يمكن أن تكون Mastodon، Gitlab، أو حتى المنتديات البسيطة مهاجمين متنكرين طالما أنهم يشغلون أكثر من خدمة واحدة ولديهم اهتمام بإنشاء بروفايل لمستخدم. يمكن أن يتم إجراء هذا المراقبة لأغراض التتبع، الربح المالي، أو لأسباب استخباراتية. حالياً هناك العشرات من المشغلين الرئيسيين الذين يمكنهم تنفيذ هذا الهجوم وجمع بيانات ذات مغزى من خلاله. نحن نثق بهم بشكل عام لعدم القيام بذلك الآن، ولكن يمكن أن يظهر لاعبين لا يهتمون بآرائنا.
هذا مرتبط بشكل مباشر بنوع أساسي من بناء البروفايل على الشبكة المفتوحة حيث يمكن للمنظمات ربط التفاعلات على موقعها بالتفاعلات على الشبكات التي تتحكم فيها. في I2P، نظرًا لأن الوجهة التشفيرية فريدة، يمكن أن تكون هذه التقنية أحيانًا أكثر موثوقية، وإن كانت بدون القوة الإضافية لتحديد الموقع الجغرافي.
الهوية المشتركة ليست مفيدة ضد مستخدم يستخدم I2P فقط لإخفاء تحديد الموقع الجغرافي. كما لا يمكن استخدامها لكسر توجيه I2P. إنها فقط مشكلة إدارة الهوية السياقية.
- من المستحيل استخدام مشكلة الهوية المشتركة لتحديد موقع جغرافي لمستخدم I2P.
- من المستحيل استخدام مشكلة الهوية المشتركة لربط جلسات I2P إذا لم تكن معاصرة.
ولكن من الممكن استخدامه لتدهور عدم الكشف عن هوية مستخدم I2P في ظروف ربما تكون شائعة جدًا. السبب وراء كونها شائعة هو أننا نشجع استخدام Firefox، وهو متصفح ويب يدعم عملية “التبويب”.
- من الممكن دائمًا إنتاج بصمة من مشكلة الهوية المشتركة في أي متصفح ويب يدعم طلبات لموارد طرف ثالث.
- تعطيل JavaScript لا ينجز أي شيء ضد مشكلة الهوية المشتركة.
- إذا كان بالإمكان إنشاء رابط بين الجلسات غير المعاصرة مثل عن طريق بصمات المتصفح “التقليدية”، عندها يمكن تطبيق الهوية المشتركة بشكل متعدي، مما يمكن من استراتيجية الربط غير المعاصر.
- إذا كان بالإمكان إنشاء رابط بين نشاط على الشبكة المكشوفة وهوية I2P، على سبيل المثال، إذا كان الهدف مسجل الدخول إلى موقع مع وجود I2P وضوح الشبكة على كلا الجانبين، يمكن تطبيق الهوية المشتركة بشكل متعدي، مما يمكن من فك التشفير الكامل للهوية.
كيف ترى شدة مشكلة الهوية المشتركة كما تطبق على وكيل HTTP الخاص بـ I2P يعتمد على مكان تعتقد أن “الهوية السياقية” للتطبيق تكمن. هناك عدة احتمالات:
- HTTP هو التطبيق والهوية السياقية – هذا هو الحال الآن. جميع تطبيقات HTTP تشترك في هوية واحدة.
- العملية هي التطبيق والهوية السياقية – هكذا تعمل عندما يستخدم التطبيق API مثل SAMv3 أو I2CP، حيث ينشئ التطبيق هويته ويتحكم في مدة حياتها.
- HTTP هو التطبيق، لكن المضيف هو الهوية السياقية – هذا هو موضوع هذا الاقتراح، الذي يعتبر كل مضيف بمثابة “تطبيق ويب” محتمل ويعامل سطح التهديد على هذا الأساس.
هل هو قابل للحل؟ ^^^^^^^^^^^^^^^
من المحتمل أن يكون من غير الممكن إنشاء وكيل يستجيب بذكاء لكل حالة ممكنة يمكن أن يؤدي فيها تشغيله إلى إضعاف عدم الكشف عن هوية التطبيق. ومع ذلك، فبالإمكان بناء وكيل يستجيب بذكاء لتطبيق معين يتصرف بطريقة متوقعة. على سبيل المثال، في متصفحات الويب الحديثة، من المتوقع أن يكون لدى المستخدمين عدة تبويبات مفتوحة، حيث يتفاعلون مع مواقع ويب متعددة، والتي سيتم تمييزها باسم المضيف.
هذا يسمح لنا بتحسين سلوك وكيل الـ HTTP لهذا النوع من وكلاء المستخدم عن طريق جعل سلوك الوكيل يطابق سلوك وكيل المستخدم عن طريق إعطاء كل مضيف وجهته الخاصة عند استخدامه مع وكيل HTTP. هذا التغيير يجعل من المستحيل استخدام مشكلة الهوية المشتركة لاستخراج بصمة يمكن استخدامها لربط نشاط العميل مع مضيفين، لأن المضيفين لن يشاركا هوية استرجاعية.
وصف: ^^^^^^^^^^^^
سيتم إنشاء وكيل HTTP جديد وإضافته إلى مدير الخدمات المخفية (I2PTunnel). سيعمل وكيل HTTP الجديد كموجه “متعدد” لـ I2PSocketManager. الموجه نفسه لا يملك وجهة. كل I2PSocketManager فردي يصبح جزءًا من التوجيه المتعدد لديه وجهته المحلية الخاصة، وبركة الأنفاق الخاصة به. يتم إنشاء I2PSocketManager عند الطلب بواسطة الموجه المتعدد، حيث “الطلب” هو الزيارة الأولى للمضيف الجديد. من الممكن تحسين إنشاء I2PSocketManager قبل إدخالها في التوجيه المتعدد عن طريق إنشاء واحدة أو أكثر مسبقًا وتخزينها خارج الموجه المتعدد. قد يؤدي ذلك إلى تحسين الأداء.
يتم إعداد I2PSocketManager إضافي، بوجهته الخاصة، كناقل “Outproxy” لأي موقع لا يحتوي على وجهة I2P، مثل أي موقع على الشبكة المكشوفة. هذا يجعل فعليًا استخدام Outproxy كهوية سياقية واحدة، مع التحفظ بأنه عند تكوين عدة Outproxies للنفق سيتم تنفيذ التدوير “اللزج” المعتاد، حيث يحصل كل Outproxy فقط على طلبات لموقع معين. هذا يكاد يكون السلوك المكافئ لعزل الوكلاء HTTP عبر I2P حسب الوجهة على الإنترنت الواضحة.
اعتبارات الموارد: ’’’’’’’’’’’’’’’’’’’’’’''
يتطلب وكيل HTTP الجديد موارد إضافية مقارنةً بالوكيل HTTP الحالي. سيفعل:
- إنشاء المزيد من الأنفاق وI2PSocketManager بشكل محتمل
- بناء الأنفاق بشكل أكثر تكراراً
كل من هذه يتطلب:
- موارد حوسبة محلية
- موارد الشبكة من الأقران
الإعدادات: ’’’’’’’''
لتقليل تأثير الاستخدام المتزايد للموارد، يجب تكوين الوكيل لاستخدام أقل قدر ممكن. يجب تكوين الوكلاء الذين هم جزء من التوجيه المتعدد (ليس الوكيل الرئيسي) ليكونوا:
- I2PSocketManager الموجهة المتعددة تبني نفقًا واحدًا للداخل، ونفقًا واحدًا للخارج في برك الأنفاق الخاصة بهم
- I2PSocketManager الموجهة المتعددة تأخذ 3 خطوات بشكل افتراضي.
- إغلاق المقابس بعد 10 دقائق من عدم النشاط
- I2PSocketManager التي بدأها الموجه المتعدد تشارك فترة حياة الموجه المتعدد. الأنفاق الموجهة المتعددة لا يتم “تدميرها” حتى يتم تدمير الموجه المتعدد الرئيسي.
الرسوم البيانية: ^^^^^^^^^
يمثل الرسم البياني أدناه التشغيل الحالي للوكيل HTTP، والذي يتوافق مع “الإمكانية 1” تحت قسم “هل هي مشكلة”. كما ترون، يتفاعل الوكيل HTTP مع مواقع I2P مباشرة باستخدام وجهة واحدة فقط. في هذا السيناريو، HTTP هو كل من التطبيق والهوية السياقية.
**الوضع الحالي: HTTP هو التطبيق، HTTP هو الهوية السياقية**
__-> Outproxy <-> i2pgit.org
/
Browser <-> HTTP Proxy(one Destination)<->I2PSocketManager <---> idk.i2p
\__-> translate.idk.i2p
\__-> git.idk.i2p
يمثل الرسم البياني أدناه التشغيل لوكيل HTTP المستند إلى المضيف، والذي يتوافق مع “الإمكانية 3” تحت قسم “هل هي مشكلة”. في هذا السيناريو، HTTP هو التطبيق، لكن المضيف يعرف الهوية السياقية، حيث يتفاعل كل موقع I2P مع وكيل HTTP مختلف بوجهة فريدة لكل مضيف. هذا يمنع مشغلي المواقع المتعددة من القدرة على التمييز عندما يكون الشخص نفسه يزور مواقع متعددة يديرونها.
**بعد التغيير: HTTP هو التطبيق، المضيف هو الهوية السياقية**
__-> I2PSocketManager(Destination A - Outproxies Only) <--> i2pgit.org
/
Browser <-> HTTP Proxy Multiplexer(No Destination) <---> I2PSocketManager(Destination B) <--> idk.i2p
\__-> I2PSocketManager(Destination C) <--> translate.idk.i2p
\__-> I2PSocketManager(Destination C) <--> git.idk.i2p
الحالة: ^^^^^^^
تتوفر تنفيذ بلغة Java لوكيل الوعي بالمضيف الذي يلتزم بإصدار قديم من هذا الاقتراح في فرع idk تحت الاسم: i2p.i2p.2.6.0-browser-proxy-post-keepalive الرابط في الاقتباسات. هو تحت مراجعة مكثفة، من أجل تقسيم التغييرات إلى أقسام أصغر.
تم كتابة تنفيذه مع قدرات متفاوتة بلغة Go باستخدام مكتبة SAMv3، قد تكون مفيدة للتضمين في تطبيقات Go الأخرى أو لـ go-i2p ولكنها غير مناسبة لـ Java I2P. بالإضافة إلى ذلك، فإنها تفتقر إلى دعم جيد للعمل بشكل تفاعلي مع مجموعات الإيجار المشفرة.
مُلحق: i2psocks
نهج بسيط موجه نحو التطبيق لعزل أنواع أخرى من العملاء يمكن تحقيقه دون تنفيذ نوع نفق جديد أو تغيير في كود I2P الحالي عن طريق دمج أدوات I2PTunnel الحالية التي تتوفر بالفعل على نطاق واسع وتم اختبارها في مجتمع الخصوصية. ومع ذلك، يقترح هذا النهج فرضية صعبة ليست صحيحة لـ HTTP وليست صحيحة أيضًا للعديد من أنواع عملاء I2P المحتملة الأخرى.
تقريبًا، سيؤدي البرنامج النصي التالي إلى إعداد وكيل SOCKS5 مناسب للتطبيق وإكساء الأمر الأساسي:
#! /bin/sh
command_to_proxy="$@"
java -jar ~/i2p/lib/i2ptunnel.jar -wait -e 'sockstunnel 7695'
torsocks --port 7695 $command_to_proxy
مُلحق: تنفيذ مثال للهجوم
تنفيذ مثال لهجوم الهوية المشتركة على وكلاء المستخدمين HTTP موجود منذ عدة سنوات. مثال إضافي متاح في المجلد الفرعي ``simple-colluder لمستودع prop166 لـ idk تم تصميم هذه الأمثلة عمدًا لإثبات أن الهجوم يعمل وأنها سوف تتطلب تعديلًا (وإن كان طفيفًا) لتحويلها إلى هجوم حقيقي.