من الصعب تصديق ذلك ولكن مؤشر اسم خادم TLS (SNI) موجود منذ ثلاثة عشر عامًا. في عصرنا الحديث، إنه ديناصور، ولكن الغريب أنه قليل الاستخدام؛ على الرغم من أن هذا يتغير أخيرًا، وفي هذه المدونة نستكشف كيف يمكن لموازنات التحميل المتقدمة edgeNEXUS دعم هذه الميزة. يتعامل SNI مع واحدة من أكبر المشكلات التي يواجهها الكثيرون مع SSL/TLS/HTTPS: الحاجة إلى تخصيص عنوان IP ثمين لكل نطاق أو اسم نطاق فرعي يحتاج إلى تأمين. هذا ضروري لأن SSL / TLS يؤمن الاتصال قبل أن نتمكن من فحص طلب HTTP الأولي للعميل، والذي يحتوي على تفاصيل اسم النطاق الثمينة تلك.
الطريقة الوحيدة للتأكد من أننا نوفر الشهادة الصحيحة هي تقديم شهادة واحدة فقط لكل عنوان IP واستخدام DNS لضمان توجيه الطلبات إلى اسم مجال معين إلى عنوان IP لمضيف يقدم الشهادة الصحيحة لهذا المجال. في مؤسسة خاصة ربما يمكننا استخدام نفس عنوان IP ولكن بمنفذ مختلف، ولكننا ملزمون بعد ذلك بالتأكد من أن الجميع يعرف استخدام المنفذ غير القياسي. هذا ليس خيارًا قابلاً للتطبيق حقًا عند التعامل مع الخدمات العامة التي يمكن الوصول إليها عبر الإنترنت.
يمكننا استخدام شهادات أحرف البدل التي تحمي كل نطاق فرعي ممكن (*.jetnexus.co.uk على سبيل المثال) ولكن لا أحد يحبها، على الأقل من جميع أنواع الأمن. ومهما كان رأيك في رجال ونساء عالم أمن المعلومات ”لا!“، فلديهم على الأرجح وجهة نظر صحيحة. من الصعب أن تثق في شيء يمثل، حسب التصميم، أي شيء أو كل شيء داخل نطاق ما. كم عدد الأجهزة المخزنة وكم عدد الموظفين الذين يمكنهم الوصول إلى الشهادة والمفتاح المستخدم؟
لطالما كانت شهادات الاسم البديل للخادم (SAN) متوفرة أيضًا، ولكنها تتطلب معرفة كل نطاق محدد ليتم حمايته، في الوقت الذي يتم إنشاؤها فيه. أي حاجة لإزالة أو إضافة اسم نطاق يتطلب إعادة إنشاء الشهادة وتحديث جميع المضيفين المعنيين بها.
هذا هو الخيار الصعب المتزايد الصعوبة الذي نواجهه جميعًا مرارًا وتكرارًا (مستخدمينا وعملائنا أيضًا)؛ حرق عنوان IP أو قبول حل وسط (بكل معنى الكلمة). صعب بشكل متزايد لأن عناوين IP هي مورد محدود يتناقص توافره وتزيد قيمته كل يوم. من حسن حظنا أن هذه المشكلة التي طال أمدها كان لها حل منذ سنوات عديدة. فهي تعطينا أفضل ما في العالم كله ومع ذلك لم يكن لها تأثير يذكر حتى وقت قريب.
توفر SNI طريقة للعميل للإشارة إلى الخادم (في حالتنا jetNEXUS) باسم المجال الذي ينشئ اتصالاً به. يتم ذلك عن طريق ملء حقل امتداد في أول حزمة TLS للعميل (مرحبًا) باسم المجال هذا. يتم إرسال هذا ”بشكل واضح“ بحيث يمكن قراءته قبل أن يرسل الخادم شهادة SSL/TLS الخاصة به. من الواضح أن هذا يتيح للخادم القدرة على إرسال الشهادة المتوقعة (بافتراض أنها متوفرة لديه) من بين الشهادات التي تم تزويده بها.
وبالتالي، يمكن تهيئة خدمة افتراضية واحدة (وعنوان IP) مع العديد من شهادات SSL لأكبر عدد من أسماء النطاقات التي ترغب في خدمتها. يمكن أن يكون لكل منها شهادة SSL مخصصة وصالحة يتم توفيرها بشكل صحيح دون خطأ، بناءً على البيانات المقدمة من العميل. خدمة www.jetnexus.com و www.loadbalance.co.uk على نفس عنوان بروتوكول الإنترنت وتوفير شهادات صالحة لكليهما؛ دون أي تنازلات أو ضجة أو إهدار لعنوان بروتوكول الإنترنت.
ليس هذا فحسب، بل يمكنك تغيير قائمة النطاقات التي تدعمها الخدمة الافتراضية وقتما تشاء، ببضع نقرات في واجهة المستخدم الرسومية. إضافة أو إزالة الشهادات لإضافة أو إزالة النطاقات التي تدعمها الخدمة الافتراضية. فقط لا تنسَ تحديث DNS الخاص بك بالترادف. إذا كنت تريد استخدام خوادم حقيقية مختلفة لنطاق أو نطاقين ذوي قيمة عالية، فلا مشكلة، فقاعدة مسار الرحلة السريعة على بعد دقائق قليلة. كذلك الأمر بالنسبة لضغط HTTP أو إعادة كتابة عناوين URL أو أي شيء آخر تحتاجه. خدمة افتراضية واحدة وعنوان IP لنطاقات متعددة مرغوب فيه للغاية ولكنه لا يحتاج إلى تقييد أي معالجة فريدة قد ترغب في تطبيقها على حركة المرور لنطاقات مختلفة.
أسمعك، ”ما هي المشكلة؟“ حسنًا، من المؤكد أنه كان هناك واحدًا وهذا هو السبب في وجود SNI منذ فترة طويلة ولكنه يظهر الآن فقط في موازنة التحميل والمنتجات الأخرى. هذا السبب؟ دعم العميل. لقد منع طول عمر مجموعة Windows XP و IE6 الشائعة بشكل لا يصدق والتي لا تدعم SNI، معظم الناس من استخدامها. لا أحد يريد أن يستبعد 10-20% من جمهوره.
أما اليوم، فقد أصبح الوضع أكثر سعادة؛ فقد تجاوز نظام التشغيل ويندوز XP نهاية الدعم، وأصبح استخدام IE6 أقل من 1% على شبكة الإنترنت العالمية، كما يتم الدفع بالترقية المجانية إلى ويندوز 10 واعتمادها بسرعة. يمكننا أخيرًا أن نكون واثقين من أن تطبيق SNI لن يكون له تأثير على عملائنا وأعمالنا. يدعم IE 7 وما فوق (على نظام التشغيل Vista أو أحدث) وجميع إصدارات كروم وفايرفوكس وسفاري تقريبًا باستثناء الإصدارات القديمة دعم SNI. إذا كنت ترغب في التحقق والتأكد من قاعدة المستخدمين الخاصة بك، فهناك قاعدة مسار الرحلة لذلك أيضًا.
فيما يتعلق بمسألة الأمان، لنكن واضحين؛ يقدم العميل المعلومات بنص عادي. هذه معلومات يمكن التقاطها من السلك. يقوم العميل بإجراء استعلام DNS بنص عادي قبل أن يتصل أيضًا. لا يمكننا التحكم في ذلك، لذلك لا يعتبر الكشف عن هذه المعلومات لمرة ثانية لاحقًا خطرًا. ربما قد ترغب في التحقق من تطابق اسم نطاق SNI مع الاسم الموجود في رأس مضيف HTTP، باستخدام قاعدة مسار الرحلة أو ربما لا تهتم، فالجميع مختلفون. هل يشير ذلك إلى وجود مشكلة أمنية؟ في كلتا الحالتين، العميل متصل والاتصال آمن. ما لم تكن تطبق سياسة الأمان استنادًا إلى اسم المجال (ولا ينبغي أن تكون كذلك) فكل شيء على ما يرام.
إذا كنت تريد حقًا مزيدًا من التفاصيل، ألقِ نظرة على RFC3546الأصلي (القسم 3.1)، و RFC6066اللاحق (القسم 3)، وإذا كنت تعتقد أنه يمكن الوثوق به: إشارة اسم الخادم على ويكيبيدي. إذا كنت بحاجة إلى أمان على مستوى التطبيق، فإن EdgeNEXUS WAF يعتمد على تقنية جدار حماية التطبيقات المحصنة الرائدة في المجال. يتوفر جدار حماية تطبيقات EdgeNEXUS عبر متجر تطبيقات EdgeNEXUS App Store، وباستخدام تقنية الجيل التالي من الحاويات، يوفر جدار حماية التطبيقات EdgeNEXUS حماية أمنية شاملة لتلبية متطلبات الامتثال لـ PCI-DSS و OWASP. كما تمت مناقشته في منشورات المدونة السابقة، فإن flightPATH هو محرك قواعد ديناميكي قائم على الأحداث تم تطويره بواسطة edgeNEXUS لمعالجة وتوجيه حركة مرور بروتوكول الإنترنت وحركة مرور HTTP و HTTPS المتوازنة بذكاء. لفهم المزيد حول إدارة حركة مرور مسار الرحلة يُرجى النقر هنا، ولاكتشاف كيفية الاستفادة الكاملة من القواعد المتاحة، يُرجى الاطلاع على دليل مستخدم EdgeNEXUS.
يمكن تهيئة خدمة افتراضية واحدة (وعنوان IP) مع العديد من شهادات SSL لأكبر عدد من أسماء النطاقات التي ترغب في خدمتها. يمكن أن يكون لكل منها شهادة SSL مخصصة وصالحة ، يتم توفيرها بشكل صحيح دون خطأ ، بناءً على البيانات المقدمة من قبل العميل.
