مصافحة SSH بكلمات بسيطة.

Secure Shell (SSH) هو بروتوكول طبقة نقل يستخدم على نطاق واسع لتأمين الاتصالات بين العملاء والخوادم. هذا هو البروتوكول الأساسي في برنامج النقل الفضائي الخاص بنا للوصول الآمن إلى البنية التحتية. فيما يلي وصف موجز نسبيًا للمصافحة التي تحدث قبل إنشاء قناة آمنة بين العميل والخادم وقبل بدء التشفير الكامل لحركة المرور.

مشاركة الإصدار


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

تبادل المفاتيح


أثناء عملية تبادل المفاتيح (تسمى أحيانًا KEX) ، يتبادل الطرفان المعلومات المتاحة للجمهور ويستنبطان السر المشترك بين العميل والخادم. لا يمكن اكتشاف هذا السر أو الحصول عليه من المعلومات المتاحة للجمهور.

تبادل مفتاح التهيئة


يبدأ تبادل المفاتيح بحقيقة أن كلا الجانبين يرسلان لبعضهما البعض رسالة SSH_MSG_KEX_INIT مع قائمة SSH_MSG_KEX_INIT المشفرة المدعومة وترتيبها المفضل.

يجب أن تحدد أوليات التشفير عناصر البناء التي سيتم استخدامها لتبادل المفاتيح ، ثم تشفير البيانات بالكامل. يسرد الجدول أدناه بدايات التشفير التي يدعمها النقل الفضائي.

تبادل المفاتيح (KEX)تشفير متماثلرمز مصادقة الرسائل (MAC)خادم المضيف خوارزمية الرئيسية
curve25519-sha256@libssh.orgchacha20-poly1305@openssh.comhmac-sha2-256-etm@openssh.comssh-rsa-cert-v01@openssh.com
ecdh-SHA2-nistp256aes128-gcm@openssh.comHMAC-sha2-256سه-آر إس إيه
ecdh-SHA2-nistp384AES256-للحد من الخطر
ecdh-SHA2-nistp521aes192-للحد من الخطر
AES128-للحد من الخطر
النقل الفضائي بدائية تشفير

تهيئة بروتوكول Diffie-Hellman بشأن منحنيات الاهليلجيه


نظرًا لأن كلا الجانبين يستخدمان نفس الخوارزمية لتحديد أوليات التشفير من قائمة تلك المدعومة ، بعد التهيئة ، يمكنك البدء في تبادل المفاتيح على الفور. يدعم Teleport بروتوكول Elliptic Curve Diffie-Hellman (ECDH) فقط ، لذلك يبدأ تبادل المفاتيح مع العميل بإنشاء زوج من المفاتيح المؤقتة (المفتاح العام والمفتاح المقترن) وإرسال الخادم مفتاحه العام في الرسالة SSH_MSG_KEX_ECDH_INIT .

تجدر الإشارة إلى أن زوج المفاتيح هذا سريع الزوال: يتم استخدامه فقط لتبادل المفاتيح ، ثم سيتم حذفه. هذا يجعل من الصعب للغاية إجراء فئة من الهجمات حيث يسجل المهاجم بشكل سلبي حركة المرور المشفرة على أمل سرقة المفتاح الخاص في وقت ما في المستقبل (كما ينص قانون Yarovaya - تقريبًا Trans.). من الصعب جدًا سرقة شيء لم يعد موجودًا. هذه الخاصية تسمى السرية الأمامية.

التين. 1. إنشاء رسالة تهيئة تبادل رئيسية

استجابة ديفي هيلمان على المنحنيات الإهليلجية


ينتظر الخادم رسالة SSH_MSG_KEX_ECDH_INIT ، وعند الاستلام يقوم بإنشاء زوج المفاتيح المؤقت الخاص به. باستخدام المفتاح العمومي للعميل وزوج المفاتيح الخاص به ، يمكن للخادم إنشاء سر مشترك K.

ثم يُنشئ الخادم شيئًا ما يُطلق عليه "hash has Exchange" ويقوم بالتوقيع عليه ، مما يؤدي إلى إنشاء هاش HS موقّع (المزيد في الشكل 3). يخدم تجزئة التبادل وتوقيعه عدة أغراض:

  • نظرًا لأن تجزئة التبادل تتضمن سرًا مشتركًا ، فإنه يثبت أن الطرف الآخر كان قادرًا على إنشاء سر مشترك.
  • تسمح دورة التجزئة / التحقق الخاصة بتوقيع التجزئة والتبادل للعميل بالتحقق من أن الخادم يملك المفتاح الخاص للمضيف ، وبالتالي يكون العميل متصلاً بالخادم الصحيح (إذا كان العميل قادرًا على الوثوق بالمفتاح العمومي المقابل ، في هذا لاحقًا).
  • بتوقيع التجزئة بدلاً من توقيع بيانات الإدخال ، يتم تقليل حجم البيانات الموقعة بشكل كبير ويؤدي إلى مصافحة أسرع.

يتم إنشاء تجزئة التبادل عن طريق أخذ التجزئة (SHA256 أو SHA384 أو SHA512 ، اعتمادًا على خوارزمية تبادل المفاتيح) للحقول التالية:

  • ماجيك M إصدار العميل ، إصدار الخادم ، رسالة العميل SSH_MSG_KEXINIT ، رسالة الخادم SSH_MSG_KEXINIT .
  • المفتاح العمومي (أو الشهادة) HPub خادم HPub . عادةً ما يتم إنشاء هذه القيمة (والمفتاح الخاص المقابل لـ HPriv) أثناء تهيئة العملية ، وليس لكل مصافحة.
  • المفتاح العمومي للعميل
  • خادم المفتاح العام B
  • مشترك سر K

باستخدام هذه المعلومات ، يمكن للخادم إنشاء رسالة SSH_MSG_KEX_ECDH_REPLY باستخدام المفتاح العام المؤقت للخادم B والمفتاح العام HPub خادم HPub والتوقيع على تجزئة تبادل HS . انظر التين. 4 لمزيد من التفاصيل.


التين. 2. جيل من تبادل التجزئة H

بمجرد أن يتلقى العميل SSH_MSG_KEX_ECDH_REPLY من الخادم ، فإنه يحتوي على كل ما هو ضروري لحساب K السرية وتبادل التجزئة H

في الجزء الأخير من تبادل المفاتيح ، يسترجع العميل المفتاح العام (أو الشهادة) للمضيف من SSH_MSG_KEX_ECDH_REPLY ويتحقق من توقيع تجزئة تبادل HS يؤكد ملكية المفتاح الخاص للمضيف. لمنع هجمات نوع "الرجل في الوسط" (MitM) ، بعد التحقق من التوقيع ، يتم التحقق من المفتاح العمومي للمضيف (أو الشهادة) في قاعدة البيانات المحلية للمضيفين المعروفين ؛ إذا لم يكن هذا المفتاح (أو الشهادة) موثوقًا به ، فسيتم قطع الاتصال.

  لا يمكن إثبات صحة المضيف 10.10.10.10 (10.10.10.10).
 بصمة مفتاح ECDSA هي SHA256: pnPn3SxExHtVGNdzbV0cRzUrtNhqZv + Pwdq / qGQPZO3.
 هل أنت متأكد من أنك تريد متابعة الاتصال (نعم / لا)؟ 
يقدم عميل SSH إضافة مفتاح المضيف إلى قاعدة البيانات المحلية للمضيفين المعروفين. بالنسبة إلى OpenSSH ، يكون هذا عادةً ~/.ssh/known_hosts

تعني هذه الرسالة أن المفتاح المقدم ليس في قاعدة البيانات المحلية للمضيفين المعروفين. من الطرق الجيدة لتجنب مثل هذه الرسائل استخدام شهادات SSH (التي يستخدمها Teleport افتراضيًا) بدلاً من المفاتيح ، والتي تتيح لك ببساطة تخزين شهادة المرجع المصدق في قاعدة بيانات محلية للمضيفين المعروفين ، ثم التحقق من جميع المضيفين الذين وقّعهم هذا المرجع المصدق.


التين. 3. توليد استجابة تبادل مفتاح ECDH

مفاتيح جديدة


قبل البدء في تشفير البيانات الجماعية ، بقي التحذير الأخير. يجب على كلا الطرفين إنشاء ستة مفاتيح: مفتاحان للتشفير ، وجهازي تهيئة (IV) واثنان للتكامل. قد تسأل ، لماذا يوجد الكثير من المفاتيح الإضافية؟ ليس K سرا بما فيه الكفاية؟ لا ، ليس كافيًا.

أولاً ، لماذا نحتاج إلى مفاتيح منفصلة للتشفير والنزاهة والرابع. يرتبط أحد الأسباب بالتطور التاريخي للبروتوكولات مثل TLS و SSH ، أي التفاوض على بدائل التشفير. في بعض الأولويات المحددة للتشفير ، إعادة استخدام المفتاح ليست مشكلة. ولكن ، كما يشرح Henryk Hellstrom بشكل صحيح ، إذا تم تحديد العناصر الأولية بشكل غير صحيح (على سبيل المثال ، AES-256-CBC للتشفير و AES-256-CBC-MAC للمصادقة) ، فإن العواقب قد تكون كارثية. وتجدر الإشارة إلى أن مطوري البروتوكول يتخلون تدريجياً عن هذه المرونة لجعل البروتوكولات أكثر بساطة وأمانًا.

بعد ذلك ، لماذا يتم استخدام مفاتيح كل نوع.

تضمن مفاتيح التشفير سرية البيانات وتستخدم مع تشفير متماثل لتشفير رسالة وفك تشفيرها.

تستخدم مفاتيح النزاهة بشكل شائع مع رمز مصادقة الرسائل (MAC) لضمان صحة النص المشفر. في حالة عدم وجود اختبارات سلامة ، يمكن للمهاجم تعديل نص التشفير الذي يتم نقله عبر القنوات المفتوحة ، وسوف تقوم بفك تشفير رسالة وهمية. عادة ما يسمى هذا المخطط Encrypt-then-MAC .

تجدر الإشارة إلى أن الأصفار الحديثة لـ AEAD (تشفير مصادق عليه مع البيانات المرفقة ، عندما يتم تشفير جزء من الرسالة ، ويظل الجزء مفتوحًا ، وتتم المصادقة بالكامل على الرسالة) مثل aes128-gcm@openssh.com و aes128-gcm@openssh.com لا تستخدم فعليًا المفتاح المشتق سلامة MAC ، وإجراء المصادقة داخل هيكلها.

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


من اليسار إلى اليمين. (1) نص واضح كصورة. (2) تشفير تم الحصول عليه عن طريق التشفير في وضع البنك المركزي الأوروبي. (3) تشفير تم الحصول عليه عن طريق التشفير في وضع غير ECB. الصورة تسلسل بكسل عشوائي عشوائي

يعد استخدام متجهات IV ( واختراقها) موضوعًا مثيرًا للاهتمام بحد ذاته ، كتبه فيليبو والسورد .

أخيرًا ، لماذا تأتي المفاتيح في أزواج؟ كما لاحظ Thomas Pornin ، إذا تم استخدام مفتاح تكامل واحد فقط ، فيمكن للمهاجم إنتاج السجل المرسل إليه إلى العميل ، وسوف يعتبره صالحًا. مع مفاتيح التكامل المقترنة (على الخادم والعميل) ، سيتحقق العميل من سلامة نص التشفير ولن تعمل هذه الخدعة.

الآن مع إدراك سبب الحاجة إلى هذه المفاتيح ، دعونا نرى كيف يتم إنشاؤها وفقًا لـ RFC :

  • بدء المتجه الرابع من العميل إلى الخادم: HASH(K || H || «A» || session_id)
  • بدء المتجه IV من الخادم إلى العميل: HASH(K || H || «B» || session_id)
  • مفتاح التشفير من العميل إلى الخادم: HASH(K || H || «C» || session_id)
  • مفتاح التشفير من الخادم إلى العميل: HASH(K || H || «D» || session_id)
  • مفتاح التحكم في النزاهة من العميل إلى الخادم: HASH(K || H || «E» || session_id)
  • مفتاح التحكم في النزاهة من الخادم إلى العميل: HASH(K || H || «F» || session_id)

هنا يتم استخدام خوارزمية تجزئة SHA {256 أو 384 أو 512} وفقًا لخوارزمية تبادل المفاتيح والرمز || يعني تسلسل ، أي الجر.

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


التين. 4:. ناقلات الأولية الجيل الرابع. يحدث إنشاء مفاتيح أخرى وفقًا لنفس المخطط ، إذا استبدلنا A و B بـ C و D و E و F على التوالي

استنتاج


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

هذه هي الطريقة التي تنشئ بها مصافحة SSH اتصالًا آمنًا بين العملاء والخوادم.

Source: https://habr.com/ru/post/ar474654/


All Articles