المُقدّمة
الاستضافة الافتراضية هي ممارسة خدمة مواقع متعددة على الإنترنت نفس الخادم. على الرغم من أنه هو المعيار في الوقت الحاضر ، لم يكن ذلك ممكنًا في الأيام الأولى من HTTP (الإصدارات قبل 1.1).
في الأصل ، كان بإمكان الخادم استضافة مواقع ويب متعددة فقط على نفس الجهاز (أي تحت عنوان IP نفسه) شريطة أن يتم تخصيص منفذ مخصص لكل موقع ويب. لم يكن هذا حلاً مثاليًا لأن المتصفحات الافتراضية للمنفذ 80 لـ HTTP ، إلا إذا قام المستخدم بتحديد واحد مختلف. ونتيجة لذلك ، اختار معظم مالكي مواقع الويب خادمًا مخصصًا لتجنب خطر عدم تذكر المستخدمين لرقم المنفذ الصحيح والانتهاء على موقع ويب مختلف.
ومع ذلك ، مع انضمام المزيد من المستخدمين إلى الويب وبدء ظهور المزيد من أجهزة الشبكة عبر الإنترنت ، بدأ عدد عناوين IP المتاحة في الانخفاض بمعدل ينذر بالخطر. هذا النضوب المتوقع والمعروف باسم استنفاد نطاق عناوين IPv4، وقد دفعت الصناعة لتصميم وتنفيذ مختلف التدابير المضادة ، مثل IPv6 (خليفة IPv4) ، والذي يمكنه دعم ملفات عناوين أكثر مما سنحتاج. لسوء الحظ ، على الرغم من أن IPv6 هو حل قابل للتطبيق ، إلا أن اعتماده كان بطيئًا للغاية. بالنسبة الى إحصائيات Google IPv6، حتى كتابة هذه السطور ، تم نشر حوالي 25٪ فقط من أجهزة الإنترنت عبر IPv6.
كما تم تنفيذ الاستضافة الافتراضية كتخفيف مبكر لمشكلة الاستنفاد ، مع إدخال Host header في HTTP 1.1. أصبحت المتصفحات التي تتصل عبر HTTP 1.1 قادرة الآن على الاتصال بمنفذ الخادم 80 وتضمين اسم المجال (مثل www.ssl.com) من موقع الويب الذي يريدون زيارته في Host العنوان. بغض النظر عن عدد المواقع التي يستضيفها الخادم على نفس المنفذ ، يمكنه استخدام هذه المعلومات لتحديد موقع الويب الصحيح وإعادة محتواه.
HTTPS والاستضافة الافتراضية
العديد من التقارير المنشورة حول نقاط الضعف في الشبكة والهجمات ضد مستخدمي الويب ، مع ذلك ، حفزت الصناعة على ابدأ بالابتعاد عن بروتوكول HTTP غير الآمن ، إلى بروتوكول HTTPS البديل الأكثر أمانًا. اعتماد واسع HTTPS حسّن الأمان العام للمستخدم. ومع ذلك ، فقد أدت التحسينات الإضافية إلى زيادة التعقيد العام لاتصالات الويب.
من حيث المبدأ ، يشبه HTTPS إلى حد كبير HTTP ، باستثناء أن اتصالات HTTPS بين المتصفحات والخوادم مشفرة. باختصار ، يتطلب HTTPS من الخوادم تزويد المتصفحات بشهادة SSL صالحة صادرة عن جهة موثوقة بشكل عام سلطة التصديق (كاليفورنيا) ، مثل SSL.com. يمكن للمتصفح بعد ذلك استخدام المفتاح العام الوارد في الشهادة من أجل إنشاء قناة اتصالات مشفرة مع الخادم. علاوة على ذلك ، يتم إصدار شهادة لاسم مجال معين ، والتي يتحقق المتصفح من تطابقها مع المجال الذي يريد المستخدم زيارته. وبالتالي ، بغض النظر عن عدد مواقع الويب التي يستضيفها الخادم ، تتوقع المتصفحات العثور على شهادة SSL صالحة لموقع الويب الذي طلبوه.
قد يشعر القارئ اليقظ بالفعل بالمشكلة: يتطلب المستعرض شهادة موقع الويب الصحيحة من أجل إنشاء القناة المشفرة وإرسال Host في حين أن الخادم يحتاج إلى Host رأس لتحديد موقع شهادة الموقع الصحيح. هذه مشكلة دجاج وبيض كلاسيكية.
من الواضح أن الاستضافة الافتراضية كما تم تصورها لـ HTTP لا تعمل مع HTTPS ، لأن عناصر التحكم في الأمان تمنع المتصفحات من إرسال Host المعلومات إلى الخادم. ومع ذلك ، مع استمرار مشكلة استنفاد IPv4 دون حل ، واعتماد الصناعة المتزايد باستمرار للتقنيات السحابية (التي تتطلب موازنة التحميل وخوادم خلفية متعددة للفشل) ، لا تزال الاستضافة الافتراضية ضرورة.
ماذا عن الشهادات متعددة المجالات؟
الحل المقترح لهذه المشكلة هو استخدام متعدد المجالات أو شهادات SAN. يمكن لشهادة SAN واحدة تأمين مئات من أسماء النطاقات المختلفة ، ولن تشكو المتصفحات إذا عثروا على اسم المجال الذي يحاولون زيارته داخل قائمة مجال شهادة SAN. بعد تكوين القناة المشفرة ، يمكن للمتصفح إرسال ملف Host رأس الخادم والاستمرار كما في أي حالة أخرى. هذه فكرة رائعة تستخدم تقنية موجودة ومتاحة بالفعل ، ولكن نفس الآليات التي تضمن أمان شهادات SAN قد أدخلت أيضًا بعض الآثار الجانبية غير المرغوب فيها:
تعد شهادات SAN أداة جيدة لتأمين نطاقات متعددة مملوكة لنفس الكيان (الشخص أو الشركة أو المؤسسة) ، ولكنها غير عملية إلى حد ما لاستخدامها في الاستضافة المشتركة ؛ عندما يكون النطاق الجديد جاهزًا للإضافة إليه أو إزالته من الشهادة ، يجب أن يصدر المرجع المصدق شهادة جديدة تحتوي على أحدث قائمة بالمجالات ، ويتم إعادة نشرها في جميع المجالات.
علاوة على ذلك ، يمكن إصدار شهادات SAN فقط التحقق من صحة المؤسسة (OV) أو التحقق من الصحة الموسع (EV) if من جميع المجالات تنتمي إلى نفس المنظمة. تشير مستويات التحقق هذه إلى كمية وأنواع معلومات مالك الشهادة المحتملة التي تم التحقق منها من قبل المرجع المصدق قبل إصدار الشهادة لهم. لقد ثبت أنه كلما ارتفع مستوى التحقق ، زاد ثقة المستخدمين في موقع الويب ، ويمكن أن تؤثر ثقة المستخدم على التعرف على العلامة التجارية ومعدلات التحويل.
أخيرًا ، من الشائع جدًا في بيئات استضافة الويب المشتركة أن تشارك الشركة خادمًا مع شركات أو مؤسسات أخرى (حتى مع منافسيها). نظرًا لأن المجالات في شهادات SAN مدرجة بشكل عام ، فقد يتردد أصحاب الأعمال في مشاركة نفس الشهادة مع شركات خارجية.
على الرغم من أن شهادات SAN هي أدوات قوية ومتعددة الاستخدامات مع عدد لا يحصى من التطبيقات ، فقد حفزت هذه المشكلات IETF - الهيئة الحاكمة لمعايير الإنترنت - للبحث عن مناهج مناسبة بشكل أفضل للمشكلة المحددة لمواقع HTTPS المستضافة فعليًا.
إشارة اسم الخادم إلى الإنقاذ
تم تنفيذ الحل في شكل اسم خادم إشارة (SNI) تمديد TLS بروتوكول (جزء HTTPS الذي يتعامل مع التشفير).
يمكّن SNI المتصفحات من تحديد اسم النطاق الذي تريد الاتصال به أثناء TLS مصافحة (تفاوض الشهادة الأولية مع الخادم). نتيجة لذلك ، يمكن لمواقع الويب استخدام شهادات SSL الخاصة بها أثناء استضافتها على عنوان IP مشترك ومنفذ ، لأن خوادم HTTPS يمكنها استخدام معلومات SNI لتحديد سلسلة الشهادات المناسبة المطلوبة لإنشاء الاتصال.
بعد ذلك ، عندما يتم تكوين قناة الاتصالات المشفرة ، يمكن للمتصفح المتابعة لتضمين اسم المجال لموقع الويب في Host رأس والمتابعة كما هو معتاد. بشكل أساسي ، تؤدي SNI نفس وظيفة HTTP Host رأس أثناء إنشاء الاتصال المشفر.
سمحت هذه الحيلة البسيطة للخوادم أخيرًا باستضافة مواقع HTTPS متعددة على نفس المنفذ. ومع ذلك ، كما هو الحال مع معظم تقنيات الإنترنت ، فإن SNI لديها بعض القيود.
مخاوف دعم SNI
على الرغم من نضج SNI منذ أن تمت صياغته لأول مرة في عام 1999 ، لا يزال هناك عدد قليل من المتصفحات القديمة (IE على Windows XP) وأنظمة التشغيل (إصدارات Android <= 2.3) التي لا تدعمها. للحصول على قائمة شاملة بالمتصفحات وأنظمة التشغيل التي تدعم SNI ، يرجى إلقاء نظرة على هذه الطاولة.
على الرغم من أن حصص السوق من المتصفحات التي لا تدعم SNI (وبالتالي حدوث هذا يحدث) ضئيلة عند مقارنتها بالمتصفحات الحديثة ، إذا لم يتعرف المتصفح على SNI ، فسوف يعود إلى شهادة SSL الافتراضية ، ومن المحتمل أن ينتج خطأ عدم تطابق الاسم الشائع.
تقوم العديد من الشركات ، مثل Google ، بتطبيق SNI للعملاء الذين يدعمونها ، وتعود إلى شهادات SAN للحالات النادرة التي لا تدعمها. وبطبيعة الحال ، من المتوقع أن تتضاءل هذه المشكلة نظرًا لأن المزيد والمزيد من المستخدمين وأصحاب الأعمال يقومون بترقية أنظمتهم إلى التقنيات الحديثة.
مخاوف خصوصية SNI
الإصدار المستقر الحالي من TLS (الإصدار 1.2) ينقل الجزء الأول من المصافحة ، ومن ثم معلومات SNI ، غير مشفرة. وبالتالي ، يمكن لمهاجم الشبكة اكتشاف سجل الويب الخاص بالمستخدم ، على الرغم من أن اتصالات الويب نفسها مشفرة بالكامل.
سمح العديد من موفري الخدمات السحابية ، مثل Amazon أو Google ، بحل (قذر) يعرف باسم واجهة المجال. يمكن أن تمنع واجهة المجال الكشف عن سجل الويب لأنها تخفي معلومات SNI باستخدام اسم مضيف موفر السحابة في TLS التفاوض والموقع المستهدف في رأس HTTP. ومع ذلك ، فإن هذه الطريقة لم تعد قابلة للتطبيق بعد الآن ، لأن Google و Amazon قد صرحا بذلك علنًا تعطيل دعم واجهة المجال في خدماتهم اعتبارًا من أبريل 2018.
لحسن الحظ ، تم اقتراح حل أكثر منهجية على أنه مشروع تجريبي تفاصيل مشفر SNI (إسني) التمديد للأحدث TLS الإصدار 1.3. يقوم ESNI بتشفير معلومات SNI ، وبالتالي التخفيف من جميع مخاوف الخصوصية. للأسف، TLS 1.3 لم يتم اعتماده على نطاق واسع من قبل الصناعة حتى الآن ، على الرغم من ذلك TLS 1.3 أصبح ببطء بروتوكول أمان الشبكة بحكم الواقع. ترقب منا المقالات المستقبلية حول حالة ESNI وخصوصية HTTPS و TLS.
وفي الختام
باختصار ، باستخدام SNI ، يمكنك استضافة ملايين مواقع HTTPS على خادم واحد. ومع ذلك ، اعتمادًا على حالتك الفردية ، قد تعمل شهادة SAN بشكل أفضل بالنسبة لك. لا تزال مخاوف الخصوصية حول SNI موجودة ، على الرغم من وجود حل محتمل أيضًا مع ESNI. على أي حال ، باستخدام طريقة أو مزيج من هاتين الطريقتين ، يمكنك بسهولة تنفيذ الاستضافة الافتراضية لجميع مواقع الويب الخاصة بك بأقل جهد.
إذا كان لديك المزيد من الأسئلة حول SNI أو كنت لا تعرف كيفية الاختيار بين SANs و SNI ، يسعدنا دائمًا الإجابة على جميع أسئلة عملائنا حول PKI يحتاج. فقط أرسل لنا رسالة بريد إلكتروني على support@ssl.com وسوف يساعدك خبير.
