حلول Apple و Cloudflare و Fastly و Mozilla لتشفير SNI

الأمان / حلول Apple و Cloudflare و Fastly و Mozilla لتشفير SNI 5 دقائق للقراءة

ظهرت أخبار للتو أن Apple و Cloudflare و Fastly و Mozilla قد تعاونوا في تعزيز تشفير آلية تحديد اسم الخادم لـ HTTPS في IETF 102 Hackathon كما هو موضح في تغريدة من Cloudflare's Nick Sullivan. هنأت التغريدة فريق المزيج من عمالقة التكنولوجيا الأربعة بقولها 'عمل رائع' والمشاركة هناك تحت روابط لخوادم العمل على esni.examp1e.net و cloudflare-esni.com .



إن IETF Hackathon عبارة عن منصة تدعو المطورين الشباب والمتحمسين للتكنولوجيا للانضمام إلى الرؤساء في صياغة الحلول للمشكلات المتعلقة بالتكنولوجيا التي يواجهها المستخدم العادي اليوم. الانضمام إلى الأحداث مجاني ، ومفتوح للجميع ، ويشجعون العمل الجماعي بدلاً من المنافسة. أقيم Hackathon IETF هذا العام في مونتريال في 14العاشرو 15العاشرمن يوليو. يبدو أن الإنجاز الأبرز للخروج منه هو تشفير مؤشر اسم خادم طبقة النقل (TLS) ، وهي المشكلة التي ابتليت بها المطورين على مدار العقد الماضي ، وهي مشكلة واجهها أعضاء Apple و Cloudflare و Fastly ، وقد اقترحت Mozilla الآن حلاً لـ.



حدث هاكاثون IETF. IETF

كان هناك تحول عالمي واضح من Hyper Text Transfer Protocol (HTTP) إلى مؤشر اسم خادم أمان طبقة النقل Hyper Text Transfer Protocol Secure (TLS SNI HTTPS) في العقد ونصف العقد الماضيين. ال مشكلة التي نشأت من تحسين نظام TLS SNI HTTPS كانت قدرة المخترق على استخدام SNI مقابل الغرض منه لمطابقة نقل البيانات لفك التشفير لاحقًا.

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



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

كان الصراع الذي واجهته العديد من الشركات في التحول إلى HTTPS يتمثل في تكييف العديد من الشهادات مع تنسيق SNI مع عناوين IP الفردية لتنفيذ الطلبات لكل شهادة. ما فعله TLS بالنسبة لهم هو تسهيل إنشاء شهادات للاستجابة لمثل هذه الطلبات وما فعلته SNI أكثر من ذلك هو إزالة الحاجة إلى عناوين IP لشهادة مخصصة من خلال طرح نظام تعريف كامل عبر شبكة الإنترنت بأكملها. ما جاء مع ترقية القرن هو حقيقة أنه سمح للقراصنة باستخدام 'أسماء جهات الاتصال' الراسخة لمراقبة نقل البيانات والتظليل واستخراج المعلومات التي يحتاجون إليها لفك تشفيرها في مرحلة لاحقة.

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

بالعودة إلى القمة التي عملت لأول مرة على إنشاء هذه الطريقة ، عاد المشاركون من أربعة عمالقة تقنيين إلى المؤتمر في مونتريال لتطوير تشفير لـ TLS SNI لأنه على الرغم من الكفاءة الأكبر في النظام المجاور متعدد HTTPS ، لا يزال الأمان مصدر قلق فقط بقدر ما فعلت من قبل.

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