سؤال نطاقات SSL متعددة على نفس عنوان IP والمنفذ نفسه؟


هذا ال السؤال الكنسي حول استضافة مواقع ويب SSL متعددة على نفس عنوان IP.

كنت تحت الانطباع بأن كل شهادة SSL تتطلب تركيبة عنوان IP / المنفذ الفريدة الخاصة بها. لكن ال الإجابة على سؤال سابق نشرته على خلاف مع هذا الادعاء.

باستخدام معلومات من هذه المسألة ، تمكنت من الحصول على شهادات SSL متعددة للعمل على نفس عنوان IP وعلى المنفذ 443. إنني في حيرة من أمري بالنسبة إلى سبب نجاح هذا الأمر مع افتراض الافتراض أعلاه وتعزيزه من قبل الآخرين بأن كل موقع من مواقع SSL على الويب نفس الخادم يتطلب IP / Port الخاص به.

أنا مريب بأنني فعلت شيئًا خاطئًا. هل يمكن استخدام عدة شهادات SSL بهذه الطريقة؟


107
2018-02-04 22:36


الأصل


يقول هذا الجسم Q عدة certs والإجابات صحيحة لذلك. لكن العنوان يقول مجالات متعددة وأنت يمكن أن يكون لها نطاقات متعددة مع شهادة واحدة (ولا يوجد SNI) ، انظر serverfault.com/questions/126072/... و serverfault.com/questions/279722/... أيضا عبر على security.SX. - dave_thompson_085


الأجوبة:


للحصول على أحدث المعلومات حول Apache و SNI ، بما في ذلك RFCs إضافية خاصة بـ HTTP ، يرجى الرجوع إلى اباتشي يكي


FYsI: "شهادات SSL متعددة (مختلفة) على IP واحد" يتم جلبها لك عن طريق سحر TLS Upgrading. يعمل مع خوادم Apache الأحدث (2.2.x) ومتصفحات حديثة إلى حد معقول (لا أعرف النسخ من أعلى رأسي).

يحتوي RFC 2817 (الترقية إلى طبقة النقل الآمنة ضمن HTTP / 1.1) على التفاصيل الدامية ، ولكنه في الأساس يعمل لعدد كبير من الأشخاص (إن لم يكن الأغلبية).
يمكنك إعادة إنتاج سلوك جبان القديم مع openssl s_client القيادة (أو أي متصفح "قديمة بما فيه الكفاية") رغم ذلك.

تحرير لإضافة: على ما يبدو curl يمكن أن يظهر لك ما يحدث هنا بشكل أفضل من openssl:


أنظمة SSLv3

mikeg@flexo% curl -v -v -v -3 https://www.yummyskin.com
* About to connect() to www.yummyskin.com port 443 (#0)
*   Trying 69.164.214.79... connected
* Connected to www.yummyskin.com (69.164.214.79) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: /usr/local/share/certs/ca-root-nss.crt
  CApath: none
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using DHE-RSA-AES256-SHA
* Server certificate:
*    subject: serialNumber=wq8O9mhOSp9fY9JcmaJUrFNWWrANURzJ; C=CA; 
              O=staging.bossystem.org; OU=GT07932874;
              OU=See www.rapidssl.com/resources/cps (c)10;
              OU=Domain Control Validated - RapidSSL(R);
              CN=staging.bossystem.org
*    start date: 2010-02-03 18:53:53 GMT
*    expire date: 2011-02-06 13:21:08 GMT
* SSL: certificate subject name 'staging.bossystem.org'
       does not match target host name 'www.yummyskin.com'
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):
curl: (51) SSL: certificate subject name 'staging.bossystem.org'
does not match target host name 'www.yummyskin.com'

TLSv1

mikeg@flexo% curl -v -v -v -1 https://www.yummyskin.com
* About to connect() to www.yummyskin.com port 443 (#0)
*   Trying 69.164.214.79... connected
* Connected to www.yummyskin.com (69.164.214.79) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: /usr/local/share/certs/ca-root-nss.crt
  CApath: none
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using DHE-RSA-AES256-SHA
* Server certificate:
*    subject: C=CA; O=www.yummyskin.com; OU=GT13670640;
              OU=See www.rapidssl.com/resources/cps (c)09;
              OU=Domain Control Validated - RapidSSL(R);
              CN=www.yummyskin.com
*    start date: 2009-04-24 15:48:15 GMT
*    expire date: 2010-04-25 15:48:15 GMT
*    common name: www.yummyskin.com (matched)
*    issuer: C=US; O=Equifax Secure Inc.; CN=Equifax Secure Global eBusiness CA-1
*    SSL certificate verify ok.

68
2018-02-04 23:46



هذا مفيد جدا - شكرا! أي معلومات حول كيفية تهيئة Apache لـ TLS بدلاً من SSL؟ - Josh
أعتقد أن Apache 2.2 يحتاج فقط إلى تمكين بتات TLS في قائمة cypher الخاصة به. أنا أعترف بأنني لم أرى أبدًا "الترقية من SSL إلى TLS" بت في العمل حتى هذين الموقعين مع ذلك. إن فهمي لمستندات TLS هو أنه موقف مسموح به (ولكنه غير معتاد) للتفاوض على هذا النوع من الترقية ... - voretaq7
هذه هي المرة الأولى التي أراها فيها ولا زلت أحاول سحب فكي من الأرض ... - Josh
موافق جوابي ثلاث مرات فقط في الطول - يبدو أن الضفيرة يمكن أن تفعل كلا من مفاوضات SSLv3 و TLSv1 حتى أتمكن من إظهار الفشل والنجاح. أتمنى لو كان لدي مصحح أخطاء البروتوكول مفيد لإظهار الجزء السحري رغم ذلك. (اختبرت أيضًا وسعدًا بالإبلاغ عن خادم johnlai2004 بشكل صحيح ينفي اتصالات SSLv2 :-) - voretaq7
هذا مفيد للغاية ، وآمل أن johnlai2004 يقبل إجابتك. شكرا جزيلا! - Josh


نعم ، لكن هناك بعض التحذيرات.

ويتم تحقيق ذلك من خلال "اسم الخادم" ، وهو امتداد لأمان طبقة النقل.

ما هو مؤشر اسم الخادم؟

إشارة اسم الخادم (RFC 6066. ملغى RFC 4366، RFC 3546) هو امتداد ل أمن طبقة النقل والذي يسمح للعميل بإخبار الخادم باسم المضيف الذي يحاول الوصول إليه.

يتوافق SNI مع TLS 1.0 وأعلى وفقًا للمواصفات ، ولكن قد تختلف عمليات التنفيذ (انظر أدناه). لا يمكن استخدامه مع SSL ، لذلك يجب على الاتصال التفاوض على TLS (راجع RFC 4346 التذييل E) لاستخدام SNI. هذا يحدث بشكل عام تلقائيا مع البرامج المدعومة.

لماذا تحتاج SNI؟

في المعتاد HTTP اتصال ، يقوم المستعرض بإعلام خادم اسم المضيف للخادم الذي يحاول الوصول إليه باستخدام Host: الرأس. هذا يسمح لخادم الويب على عنوان IP واحد لخدمة المحتوى لأسماء مضيف متعددة ، والذي يعرف عادة باسم استضافة افتراضية قائمة على الاسم.

البديل هو تعيين عناوين IP فريدة لكل اسم مضيف على شبكة الإنترنت ليتم تقديمه. وقد تم ذلك عادة في الأيام الأولى من الويب ، قبل أن يكون معروفًا على نطاق واسع أن عناوين IP ستنفد وأن إجراءات الحفظ قد بدأت ، وما زال يتم بهذه الطريقة للمضيفين الظاهريين لـ SSL (لا يستخدمون SNI).

نظرًا لأن هذه الطريقة في نقل اسم المضيف تتطلب وجود اتصال بالفعل ، فإنه لا يعمل مع اتصالات SSL / TLS. في الوقت الذي يتم فيه إعداد الاتصال الآمن ، يجب أن يعرف خادم الويب بالفعل اسم المضيف الذي سيخدمه للعميل ، لأن خادم الويب نفسه يقوم بإعداد الاتصال الآمن.

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

لماذا لا تستخدم عناوين IP مختلفة؟

HTTP Host: تم تعريف العنوان للسماح بأكثر من مضيف ويب ليتم تقديمه من عنوان IP واحد بسبب نقص عناوين IPv4 ، والتي تم التعرف عليها كمشكلة في منتصف التسعينيات. في بيئات الاستضافة المشتركة ، يمكن تقديم مئات المواقع الفريدة غير المرتبطة باستخدام عنوان IP واحد بهذه الطريقة ، مما يحافظ على مساحة العنوان.

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

مع ظهور IPv6 ، لم تعد تقنيات المحافظة على العناوين ضرورية ، نظرًا لأن مضيف واحد يمكن أن يحتوي على عناوين IPv6 أكثر مما تحتويه شبكة الإنترنت بالكامل اليوم ، ولكن ربما لا تزال التقنيات المستخدمة في المستقبل بعيدة عن خدمة IPv4 القديمة روابط.

المحاذير

لا تدعم بعض تركيبات أنظمة التشغيل / المستعرض SNI (انظر أدناه) ، لذلك فإن استخدام SNI غير مناسب لجميع المواقف. يجب على المواقع التي تستهدف مجموعات النظام / المتصفح أن تتخلى عن SNI وتستمر في استخدام عناوين IP الفريدة لكل مضيف ظاهري.

ملاحظة خاصة ، لا يوجد أي إصدار من Internet Explorer على نظام التشغيل Windows XP يدعم SNI. نظرًا لأن هذه المجموعة لا تزال تمثل نسبة هامة (ولكنها تقل باستمرار ، حوالي 16٪ من حركة مرور الإنترنت في ديسمبر 2012 وفقًا ل NetMarketShare) في عدد زيارات الإنترنت ، فإن SNI ستكون غير مناسبة لموقع يستهدف هؤلاء المستخدمين.

الدعم

تدعم العديد من حزم البرامج الشائعة الاستخدام ، وليس جميعها ، SNI.

(لا يعني الإهمال من هذه القائمة بالضرورة وجود نقص في الدعم ؛ فهذا يعني وجود حد لمقدار ما يمكنني كتابته ، أو لم أتمكن من العثور على المعلومات بسرعة في البحث. إذا لم تكن حزمة برامجك مدرجة ، لاسمها زائد sni يجب أن تكشف عن وجود الدعم وكيفية إعداده.)

دعم المكتبة

تعتمد معظم الحزم على مكتبة خارجية لتقديم دعم SSL / TLS.

  • GNU TLS
  • JSSE (Oracle Java) 7 أو أعلى ، فقط كعميل
  • ليبكورل 7.18.1 أو أعلى
  • NSS 3.1.1 أو أعلى
  • OpenSSL 0.9.8j أو أعلى
    • OpenSSL 0.9.8f أو أعلى ، مع تكوين الأعلام
  • كيو تي 4.8 أو أعلى

دعم الخادم

تدعم معظم الإصدارات الحالية من برنامج الخادم الشهير SNI. تتوفر إرشادات الإعداد لمعظم هذه الإجراءات:

دعم العميل

معظم متصفحات الويب الحالية ووكلاء وكلاء سطر الأوامر يدعمون SNI.

سطح المكتب

  • Chrome 5 أو أعلى
    • Chrome 6 أو أحدث على نظام التشغيل Windows XP
  • فايرفوكس 2 أو أعلى
  • Internet Explorer 7 أو إصدار أحدث ، يعمل على Windows Vista / Server 2008 أو أعلى
    • لا يدعم Internet Explorer على Windows XP SNI بغض النظر عن إصدار IE
  • كونكيورر 4.7 أو أعلى
  • Opera 8 أو أعلى (قد يتطلب تمكين TLS 1.1)
  • Safari 3.0 على Windows Vista / Server 2008 أو أعلى أو Mac OS X 10.5.6 أو أحدث

التليفون المحمول

  • متصفح أندرويد على 3.0 قرص العسل أو أعلى
  • iOS Safari على iOS 4 أو أعلى
  • ويندوز فون 7 أو أعلى

سطر الأوامر

  • cURL 7.18.1 أو أعلى
  • wget 1.14 أو أعلى (قد يكون التوزيعات قد أعدت تصحيح لدعم SNI)

لا دعم

  • متصفح بلاك بيري
  • Internet Explorer (أي إصدار) على نظام التشغيل Windows XP

(ملاحظة: تم الحصول على بعض المعلومات لهذه الإجابة من ويكيبيديا.)


96
2017-08-14 23:05



أفضل بكثير :-) من المأمول أن يحصل هذا في النهاية على درجة أعلى من النسبة المقبولة حاليًا ، والتي ، في الغالب ، بخلاف التعديل الأخير في الجزء العلوي ، تكون غير صحيحة في الغالب للأسف. - Bruno
Bruno أنا بالتأكيد لن أشتكي إذا وجدت بضع مئات من الناس من أجل تقييمها. :) - Michael Hampton♦
يستخدم أحدث إصدار من BlackBerry Browser (10؟) إصدارًا حديثًا من WebKit ، لذا فمن المرجح أنه يدعم SNI الآن. - dave1010


المشكلة:

عندما يتحدث عميل ويب وخادم الويب مع بعضهما البعض عبر HTTPS ، فإن الأول حتما الشيء الذي يجب أن يحدث هو المصافحة آمنة.

هنا مثال مبسط لمثل هذه المصافحة:

tls handshake

إذا كان هذا HTTP وليس HTTPS ، فإن أول شيء قد أرسله العميل كان شيئًا كالتالي:

GET /index.html HTTP/1.1
Host: example.com

هذا جعل مضيفين افتراضيين متعددين على عنوان IP واحد ممكن ، لأن الخادم يعرف بالضبط النطاق الذي يريد العميل الوصول إليه ، وهو example.com.

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

لا يزال بإمكانك إعداد مضيفات ظاهرية على خادم الويب الخاص بك ، ولكن سيرسل الخادم دائمًا نفس الشهادة لكل عميل. إذا حاولت استضافة موقعي الويب example.com و example.org على خادمك ، فسيقوم الخادم دائمًا بإرسال الشهادة لـ example.com عندما يطلب العميل اتصال HTTPS. لذلك عندما يطلب العميل example.org عبر اتصال HTTPS تم إنشاؤه ، يحدث ذلك:

enter image description here

تحد هذه المشكلة بشكل فعال من عدد المجالات التي يمكنك تخديمها عبر HTTPS إلى عنوان واحد لكل عنوان IP.

الحل:

الطريقة الأسهل لحل هذه المشكلة هي أن يقوم العميل بإخبار الخادم بالمجال الذي يريد الوصول إليه خلال المصافحة. بهذه الطريقة يمكن للخادم تقديم الشهادة الصحيحة.

هذا هو بالضبط ما SNI، أو إشارة اسم الخادم يفعل.

باستخدام SNI ، يرسل العميل اسم الخادم الذي يريد الوصول إليه كجزء من الرسالة الأولى ، وهي الخطوة "Client Hello" في مخطط تبادل الإشارات أعلاه.

لا تدعم بعض متصفحات الويب القديمة SNI. على سبيل المثال ، على نظام التشغيل Windows XP هناك ليس إصدارًا واحدًا من Internet Explorer لديها دعم SNI. عند الوصول إلى مورد عبر HTTPS على خادم يستفيد من مضيفات SNI الظاهرية ، سيتم تقديمك مع شهادة عامة ، والتي قد تتسبب في عرض المتصفح لخطأ أو تحذير.

enter image description here

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


37
2017-08-14 19:13





http://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI

يجب أن يدعم مستعرض العميل أيضًا SNI. فيما يلي بعض المتصفحات التي تقوم بما يلي:

* Mozilla Firefox 2.0 or later
* Opera 8.0 or later (with TLS 1.1 enabled)
* Internet Explorer 7.0 or later (on Vista, not XP)
* Google Chrome
* Safari 3.2.1 on Mac OS X 10.5.6 

16
2018-02-05 00:46





مطلوب إضافة TLS لملقم اسم الخادم (RFC6066) لأسطوانة المستندة إلى الاسم للعمل عبر HTTPS.

تم تنفيذ الامتداد على نطاق واسع ولم أواجه أي مشاكل مع البرنامج الحالي ، ولكن هناك فرصة أن يتم توجيه بعض العملاء (الذين لا يدعمونه) إلى موقعك الافتراضي إذا كنت تعتمد على SNI.


6
2017-08-14 19:10



بالإضافة إلى الإجابة Falcon IIS يتطلب أيضاً بعض التغييرات الخاصة في الحصول على عدة مواقع IIS للعمل عبر نفس IP. يجب عليك يدوياً تحرير ملف التكوين للملقم أو استخدام أداة CLI لإجراء تغييرات الربط ، لا يمكن لأداة واجهة المستخدم الرسومية القيام بذلك. في معهد الدراسات الإسماعيلية ، يتم الإشارة إليه على أنه تعيين سلات SSL لاستضافة الرؤوس. لم يكن Apache المشكلة منذ فترة. - Brent Pabst
آه حسنا ، هذا يزيل بعض. كيف يمكنك معرفة ما إذا كان العميل (المستعرض) يدعم هذا؟ على سبيل المثال ، إذا أردت التحقق من MSIE6 ، كيف يمكنني اختبار ذلك دون الحاجة إلى تثبيت جهاز XP ظاهري أو ما إلى ذلك؟ - Luc
Luc en.wikipedia.org/wiki/Server_Name_Indication#Support - cjc
لا يعملFalcon SNI مع IE على XP ؛ التي لا تزال تمثل ما يقرب من ربع مستخدمي الإنترنت في سطح المكتب. لن أسميها "تنفذ على نطاق واسع" عندما لا يعمل ربع الزوار المحتملين. - Chris S
يستخدمMichaelHampton IE مكدس التشفير الأصلي لـ Windows لـ SSL. لا يدعم XP SNI ، لذلك لا يتوفر أي إصدار من IE لتشغيل XP. IE فقط دعم SNI في Vista وأنظمة تشغيل أحدث. - Chris S