مجموعة DH مشتركة وأسرار جديدة: لماذا تصبح الهجوم أرخص

معاملات المجموعة علنية بحكم التصميم، وهذه العلنية تحديدًا هي ما يجعلها سهلة التجاهل. في Diffie-Hellman على الحقل المنتهي يكون المعامل والمولّد مشتركين، بينما لا تكون الأسس الخاصة ومفاتيح الجلسة الناتجة كذلك. تعتمد المرحلة المكلفة في هجوم غربال حقل الأعداد على المجموعة لا على تبادل واحد، لذا تصبح مجموعة ضعيفة واحدة تُستخدم في كل مكان عبئًا مشتركًا. ووصف المعاملات بأنها علنية دقيق لكنه لا يمسّ جوهر المسألة، لأن التكلفة التي يُعاد استخدامها هي تكلفة مهاجمة تلك المجموعة.

النصف العلني ليس النصف القابل للاستغلال، وهنا يكمن الفخ

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

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

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

ما يمنحه الحساب المسبق للمهاجم فعلًا

لغربال حقل الأعداد مرحلة تعتمد على العدد الأولي وحده، وناتجها قابل لإعادة الاستخدام ضد كل تبادل يستخدم ذلك العدد. هذا هو الميكانيزم الكامل وراء القلق التاريخي: يُدفع الجزء المكلف مرة واحدة، فتنخفض التكلفة الحدية لكل جلسة إضافية. لا تزال الأسس الجديدة تحمي كل تبادل منفرد من مراقب سلبي، ما دامت المجموعة كبيرة بما يكفي لجعل الغربال غير قابل للتنفيذ. العبارتان متوافقتان، ومعظم الجدل في هذا الموضوع ينشأ من اختيار إحداهما وإسقاط الأخرى.

أظهرت ورقة Logjam لعام 2015 تخفيضًا إلى Diffie-Hellman من فئة التصدير بطول 512 بت، وقدّرت كلفة مهاجمة مجموعات أكبر تُعاد استخدامها على نطاق واسع بموارد كبيرة. كان العرض ملموسًا، والتقديرات تقديرات، ولم يكن أي منهما دليلًا على فك تشفير جلسة VPN بعينها.

استشهد بالورقة من أجل الميكانيزم والتخفيض الموضّح، لا كقياس لنشرك. الإحصاءات القديمة عن عدد الخوادم التي شاركت مجموعة افتراضية تصف إنترنت تلك السنة، لا شبكة يمكنك فحصها اليوم. وما يستحق النقل هو السؤال: هل لا تزال أجهزتك تتفاوض على مجموعة صغيرة أو ضعيفة التحقق؟

المعيارية ليست ضعفًا

يُعرّف RFC 7919 مجموعات حقول منتهية مُسمّاة حتى يتفق الطرفان على مجموعة بمعرّف ويطبقا سياسة متسقة. كونها معيارية ميزة، لأنها تزيل غموض التفاوض وتتيح للتطبيق رفض الأحجام غير المدعومة. المجموعة المُسمّاة ضعيفة فقط عندما يقع حجمها تحت السياسة التي تزعم اتباعها، لا لأنها ترد في وثيقة. وينطبق المنطق نفسه على مجموعات المنحنيات الإهليلجية، التي لها بنية مختلفة وأنماط فشل مختلفة.

افصل الإنشاءات عند التفكير فيها. الاستنتاج بشأن Diffie-Hellman على الحقل المنتهي لا يقول شيئًا عن X25519، والاستنتاج بشأن مجموعة MODP بطول 1024 بت لا يقول شيئًا عن مجموعة بطول 3072 بت. سياسة القوة تُحدَّد لكل ميكانيزم ولكل حجم ولكل إصدار بروتوكول، ولهذا فإن عبارة تشفير قوي ليست عبارة قابلة للمراجعة.

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

اقرأ المجموعة المتفاوض عليها على اتصال حقيقي

اقرأ المجموعة المتفاوض عليها من الجهاز لا من قالب التكوين. القوالب تصف النية، والقيمة المثيرة هي التي وافق عليها الطرفان في آخر مصافحة. على نقطة نهاية IPsec يطبع مخرج الحالة عادةً المقترح المختار، بما في ذلك مجموعة MODP.

التقط ذلك السطر قبل تغيير السياسة وبعده، واحفظ الاثنين في سجل التغيير. المقارنة هي الدليل.

ipsec statusall | grep -Ei "proposal|ESP|IKE"
openssl dhparam -in /etc/vpn/dh3072.pem -check -noout

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

افحص المجموعة وهوية الطرف الآخر كلًّا على حدة

افصل ما تحميه المجموعة عمّن هو في الطرف الآخر. سجّل طريقة تبادل المفاتيح وحجم المجموعة وطريقة المصادقة كثلاثة حقول، لأنها تفشل باستقلال. النفق الذي تفاوض على مجموعة بطول 3072 بت لكنه يقبل أي شهادة ليس بالمخاطرة نفسها التي لنفق يثبّت طرفًا ويستخدم مجموعة بطول 2048 بت.

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

ipsec statusall | grep -Ei "peer|auth|cert"
openssl s_client -connect vpn.acme.example:443 -brief -cipher 'DHE-RSA-AES256-GCM-SHA384'

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