مرحباً يا جماعة، لقد حان موعدنا الأسبوعي مجدداً

  • Index
  1. تمت استعادة squid/www/cvs/dev.i2p 2) اختبار SSU 3) تشفير I2CP 4) ???
    1. squid/www/cvs/dev.i2p restored

بعد الكثير من العناء مع عدة خوادم colo (الاستضافة المشتركة في مركز بيانات)، تمت استعادة بعض الخدمات القديمة - squid.i2p (واحد من خادمي الخروج الافتراضيين)، www.i2p (رابط آمن إلى www.i2p.net)، dev.i2p (رابط آمن إلى dev.i2p.net، حيث توجد أرشيفات قوائم البريد، وcvsweb، وبذور netDb الافتراضية)، وcvs.i2p (رابط آمن إلى خادم CVS لدينا - cvs.i2p.net:2401). مدونتي لا تزال مفقودة، لكن محتواها فُقد على أي حال لذا ستكون هناك حاجة إلى بداية جديدة عاجلاً أم آجلاً. الآن بعد أن عادت هذه الخدمات للعمل بشكل موثوق، حان الوقت للانتقال إلى الـ…

    1. SSU testing

كما ذُكر في ذلك المربع الأصفر الصغير على لوحة تحكم الـ router لدى الجميع، لقد بدأنا الجولة التالية من الاختبارات الحيّة على الشبكة لـ SSU. هذه الاختبارات ليست للجميع، ولكن إن كنت تتحلّى بروح المغامرة وتشعر بالارتياح لإجراء بعض التهيئة اليدوية، فاطّلع على التفاصيل المشار إليها على لوحة تحكم الـ router الخاصة بك (http://localhost:7657/index.jsp). قد تكون هناك عدة جولات من الاختبار، لكنني لا أتوقع أي تغييرات كبيرة على SSU قبل إصدار 0.6 (سيضيف 0.6.1 دعماً لأولئك الذين لا يمكنهم إعداد إعادة توجيه منافذهم أو لا يمكنهم بأي طريقة أخرى استقبال اتصالات UDP الواردة).

    1. I2CP crypto

أثناء مراجعتي لوثائق المقدمة الجديدة مرة أخرى، أجد بعض الصعوبة في تبرير طبقة التشفير الإضافية المنفذة داخل I2CP SDK. كان الهدف الأصلي من طبقة التشفير في I2CP هو توفير حماية أساسية طرف-إلى-طرف للرسائل المُرسلة، وكذلك تمكين عملاء I2CP (المعروفين أيضاً باسم I2PTunnel, the SAM bridge, I2Phex, azneti2p, etc) من التواصل عبر routers غير موثوق بها. ومع تقدم التنفيذ، أصبحت حماية طرف-إلى-طرف التي توفرها طبقة I2CP زائدة عن الحاجة، حيث إن جميع رسائل العميل تُشفَّر طرف-إلى-طرف داخل رسائل garlic (تقنية التشفير التجميعي في I2P) بواسطة router، مع تضمين leaseSet الخاص بالمرسِل وأحياناً رسالة حالة التسليم. هذه الطبقة garlic توفر بالفعل تشفيراً طرف-إلى-طرف من router المرسِل إلى router المستلِم - والاختلاف الوحيد هو أنها لا تحمي من كون ذلك router نفسه عدائياً.

عند النظر في حالات الاستخدام المتوقعة، مع ذلك، لا يبدو أنني أستطيع التوصل إلى سيناريو صالح لا يكون فيه الـ router المحلي محل ثقة. على الأقل، فإن تشفير I2CP يخفي فقط محتوى الرسالة المُرسلة من الـ router - إذ لا يزال الـ router بحاجة إلى معرفة الوجهة التي ينبغي إرسالها إليها. وإذا لزم الأمر، يمكننا إضافة مستمع I2CP عبر SSH/SSL للسماح لعميل I2CP والـ router بالعمل على أجهزة منفصلة، أو يمكن لمن يحتاجون إلى مثل هذه الحالات استخدام أدوات tunnelling الموجودة.

وللتأكيد مجدداً على طبقات التشفير المستخدمة حالياً، لدينا: * طبقة التشفير من طرف إلى طرف الخاصة بـ I2CP بتقنية ElGamal/AES+SessionTag، وتقوم بتشفير من وجهة المُرسِل إلى وجهة المُستقبِل. * طبقة garlic encryption من طرف إلى طرف الخاصة بالـ router (ElGamal/AES+SessionTag)، وتقوم بتشفير من router المُرسِل إلى router المُستقبِل. * طبقة تشفير الـ tunnel لكلٍ من الـ tunnels الواردة والصادرة عند القفزات على طول كلٍ منهما (ولكن ليس بين نقطة النهاية الصادرة والبوابة الواردة). * طبقة تشفير النقل بين كل router.

أريد أن أكون متحفظاً إلى حدٍّ معقول بشأن إسقاط إحدى تلك الطبقات، لكنني لا أريد إهدار مواردنا في عمل غير ضروري. ما أقترحه هو إسقاط طبقة التشفير الأولى الخاصة بـ I2CP (مع الإبقاء، بطبيعة الحال, على التوثيق المستخدم أثناء إنشاء جلسة I2CP، وتفويض leaseSet، وتوثيق المُرسِل). هل يستطيع أحد أن يقدم سبباً يدعونا إلى الإبقاء عليها؟

    1. ???

هذا كل ما لدينا في الوقت الحالي، لكن هناك الكثير مما يجري كما هو الحال دائماً. لا اجتماع هذا الأسبوع، ولكن إن كان لدى أحد ما يودّ طرحه، فيُرجى عدم التردد في نشره على القائمة البريدية أو في المنتدى. وأيضاً، رغم أنني أقرأ سجل المحادثة في #i2p، يُفضَّل إرسال الأسئلة أو المخاوف العامة إلى القائمة البريدية بدلاً من ذلك لكي يتمكّن عدد أكبر من الأشخاص من المشاركة في النقاش.

=jr