بعد إعداد مثيل Discourse الخاص بي باستخدام دعم Let’s Encrypt الافتراضي، تلقيت تقارير من بعض المستخدمين مفادها أن متصفحاتهم لا تستطيع إنشاء اتصال آمن مع Discourse. لقد أظهرت لقطة شاشة واحدة حصلت عليها من مستخدم بوضوح وجود خطأ في SSL/TLS. هذا خطأ من جانب المتصفح، ولا يرى المستخدمون أي شيء من Discourse.
بناءً على السياق، يبدو أن هؤلاء المستخدمين يعملون بأنظمة تشغيل أو متصفحات أقدم نوعًا ما. اشتبهت في البداية في أن دعم TLS 1.2 هو المشكلة، لكن المستخدم الذي قمت بفحصه يعمل بنظام Safari 10.1.2 على macOS (إصدار غير معروف)، ووفقًا لـ Can I use... Support tables for HTML5, CSS3, etc يجب أن يدعم Safari TLS 1.2 منذ الإصدار 7.
هل هناك سبب آخر غير TLS 1.2 قد يتسبب في فشل متصفح أو نظام تشغيل في إنشاء اتصال آمن مع تثبيت افتراضي لـ Discourse يستخدم دعم TLS الافتراضي عبر Let’s Encrypt؟ أحاول معرفة الأسئلة التي يجب أن أطرحها على مستخدمِي لتحديد طبيعة مشكلتهم وما إذا كان الحل يجب أن يكون من جانبهم أم من جانبنا.
كحل بديل: حسب فهمي، الإعداد الافتراضي هو إعادة توجيه حركة المرور الموجهة إلى http إلى https. هل توجد طريقة لإجراء فحص مسبق، مثل “فقط إذا كان المتصفح يدعم TLS 1.2” أو “فقط إذا كان المتصفح/نظام التشغيل أحدث من إصدار معين”، وإلا البقاء على http؟
يمكنك اختبار موقعك باستخدام اختبار خادم SSL. تحتوي نتائج الاختبار على قسم يُسمى “محاكاة المصافحة” والذي يجب أن يعرض لك مجموعات المتصفح/نظام التشغيل التي تعمل أو لا تعمل.
لقد قمت بتشغيل اختبار خادم SSL ولم أستطع العثور على أي خطأ في النتيجة:
هي نفس النتائج المذكورة في منشورك، حسب ما أستطيع رؤيته.
كانت الإخفاقات الوحيدة تتعلق بأنظمة التشغيل القديمة مع إصدارات Safari (8 و9) وإصدارات Windows القديمة مع IE 11. هذا الأخير يقلقني بعض الشيء: ألا ينبغي أن يدعم Discourse IE 11، وأن يدعم TLS 1.2 افتراضيًا؟
كما أن الاختبار لا يتضمن اختبارًا لـ Safari 10 على أقدم نظام تشغيل لا يزال مدعومًا، لذا ربما يفشل هذا أيضًا…
شكرًا لك، لقد تلقيت ردًا من المستخدم. إنه يستخدم جهاز iPod Touch قديم جدًا:
قدرات SSL/TLS لمتصفحك وكيل المستخدم: Mozilla/5.0 (iPod; CPU iPhone OS 6_1_6 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Version/6.0 Mobile/10B500 Safari/8536.25
دعم البروتوكول
وكيل المستخدم الخاص بك يتمتع بدعم جيد للبروتوكولات.
يدعم وكيل المستخدم الخاص بك TLS 1.2، وهو إصدار البروتوكول الموصى به حاليًا.
لذا، على الرغم من أنه قديم (وأنا أدرك أنه بعيد جدًا عن الحد الأدنى لنظام التشغيل والمتصفح المدعومين في Discourse)، إلا أنني أود تمكينه من الاتصال بالموقع على الأقل ورؤية كيفية تعامل متصفحه مع HTML وJavaScript الحديثين.
تسمية اسم الخادم (SNI) نعم
إعادة التفاوض الآمنة نعم
ضغط TLS لا
تذاكر الجلسة لا
تثبيت OCSP لا
خوارزميات التوقيع SHA384/RSA، SHA256/RSA، SHA1/RSA، SHA256/ECDSA، SHA1/ECDSA
المجموعات المسماة secp256r1، secp384r1، secp521r1
مفاوضة البروتوكول التالي لا
مفاوضة بروتوكول طبقة التطبيق لا
توافق مصافحة SSL 2 لا
اختبارات المحتوى المختلط
الصور سلبية نعم
CSS نشط نعم
سكريبتات نشطة نعم
XMLHttpRequest نشط نعم
WebSockets نشط نعم
إطارات نشطة نعم
(1) قد تسبب هذه الاختبارات تحذير محتوى مختلط في متصفحك. وهذا متوقع.
(2) إذا رأيت اختبارًا فاشلًا، حاول إعادة تحميل الصفحة. إذا استمر الخطأ، يرجى التواصل معنا.
آسف على التنسيق، فقد قام المستخدم بنسخ ولصق HTML النص الغني بالنسبة لي، وبعضها يفقد عند لصقه في Discourse. سأحاول معرفة كيفية إصلاح التنسيق لاحقًا.
كما قلت، أود تمكينه من إنشاء اتصال آمن على الأقل حتى يرى شيئًا، ويجب أن يكون ذلك ممكنًا لأن المتصفح يدعم TLS 1.2. لكنني أعتقد أنني سأحتاج إلى تمكين بعض إعدادات TLS 1.2 الأقل أمانًا لدعم متصفحه. لا أعرف بما يكفي عن TLS condors لمطابقة مخرج هذا التقرير مع ما يدعمه الخادم وما يجب علي تغييره. هل يمكنك إخباري بما ينقص وما يجب علي تغييره؟
[اقتباس=“supermathie, post:4, topic:127474”]
ربما تحتاج إلى تمكين تشفير CBC:
[/اقتباس]
لدي فكرة تقريبية عما تعنيه، ولكن ليس لدي أي فكرة عن كيفية القيام بذلك. هل يمكنك توجيهي إلى بعض الوثائق التي تشرح كيفية تغيير تكوين TLS لحاوية Discourse Docker لتمكين هذه؟
لا أعتقد أن Safari 6 سيعمل حتى لو تم حل مشاكل TLS بإضافة مجموعات تشفير إضافية.
يمكنك إضافة مجموعات التشفير المفقودة عن طريق تجاوز ملف تكوين nginx. أضف المقطع التالي (غير مختبر، لكنه يجب أن يعمل) إلى قسم hooks في ملف app.yml وقم بتغيير قيمة ssl_ciphers حسب رغبتك.
شكرًا لك يا @gerhard، لقد قمت بالتغيير الذي وصفته في /var/discourse/containers/app.yml (آمل أن يكون ملف app.yml الصحيح)، ثم شغّلت الأمر /var/discourse/launcher rebuild app كما هو موضح في تعليقات app.yml.
أوه، لم أقرأ منشورك بشكل صحيح @gerhard. إذا فهمت الأمر بشكل صحيح، فإن التكوين الذي قدمته سيجعل الشفرات المستخدمة صريحة، لكن القيمة التي استخدمتها هي في الأساس نفس الافتراضية، أليس كذلك؟ إذن لا يزال عليّ توسيعها بشفرات أخرى قد تدعمها المتصفحات الأقدم.
نعم، تمامًا. لم أرغب في نشر حل لإضافة شفرات ضعيفة إلى الإعدادات. ستضطر إلى اكتشاف ذلك بنفسك.
ولكن إذا كنت تقوم بإجراء هذه التغييرات، فراقب طلب السحب الذي أشرت إليه سابقًا. إذا تم دمجه، فسيعمل Internet Explorer 11 دون الحاجة إلى أي إعدادات إضافية.
أفهم ذلك، لا تريد جعل الأمر سهلاً جداً لدرجة أن يصبح الإعداد غير آمن. أحترم ذلك ولن أنشر الكود الكامل أيضاً.
إليك ما توصلت إليه حتى الآن: حددت مجموعات التشفير المفقودة لدعم المتصفحات/أنظمة التشغيل الأقدم من خلال النظر في، على سبيل المثال، Qualys SSL Labs - Projects / User Agent Capabilities: Safari 6 / iOS 6.0.1 (وأيضاً للآخرين). وبما أن مجموعات تشفير العميل مدرجة حسب التفضيل، فقد اخترت دائماً العنصر العلوي وتأكدت من دعمه، مفترضاً أنه إذا كان الخادم يدعم واحداً من القائمة، فذلك يجب أن يكون كافياً. هذه هي مجموعات التشفير التي حددتها:
ECDHE-ECDSA-AES256-CBC-SHA384 لـ Safari 6-8
ECDHE-RSA-AES256-CBC-SHA384 لـ IE 11 على Win 7/8.1/Phone 8.1 Update (وفقاً لـ @supermathie)
ECDHE-RSA-AES128-CBC-SHA256 لـ IE 11 على Win Phone 8.1
أخذت هذه القيم وأضفتها إلى نهاية قائمة ssl_ciphers، مفصولة بعلامات النقطتين، مفترضاً أن “نهاية القائمة” تعني “الأقل تفضيلاً، وسيتم استخدامها فقط إذا لم يدعم العميل أي شيء آخر”. ثم شغّلت /var/discourse/launcher rebuild app لتطبيق الإعداد الجديد وأعدت تشغيل الاختبار على SSL Server Test (Powered by Qualys SSL Labs) بعد مسح ذاكرة التخزين المؤقت. لكن النتائج لم تتغير.
توقعت أن تنجح الآن كل من اختبارات IE 11 الفاشلة وSafari 6-8، لكن المصافحة لا تزال تفشل. إذن يجب أن يكون هناك شيء ما أفتقده.
أيضاً، أحد مستخدمين يستخدم آيفون مع iOS 9/Safari 9، وبالنسبة لهم أيضاً تفشل الاتصال. ولكن وفقاً لنتائج اختبار SSL Labs، يجب أن يعمل هذا الاتصال بالفعل بشكل افتراضي (كما هو ظاهر أيضاً في نتيجة @gerhard أعلاه).
إذن يجب أن أفتقد شيئين:
لماذا لا يزال الاتصال لا يعمل بعد إضافة دعم مجموعات التشفير؟
لماذا يقول SSLLabs إنه يعمل لـ iOS 9 + Safari 9 لكنه لا يعمل فعلياً لمستخدمي؟
بخصوص النقطة 1: ما زلت غير متأكد من أنني طبقت الإعداد بشكل صحيح. بالإضافة إلى اختبار SSL Labs، هل توجد طريقة أخرى للتحقق من مجموعات التشفير التي يدعمها الخادم لمعرفة ما إذا كان تغيير الإعداد قد طُبق بشكل صحيح؟
أعتقد أن أسماء الشفرات التي اخترتها غير صحيحة. يُعد موقع Mapping OpenSSL cipher suite names to IANA names مصدرًا جيدًا لربط الشفرات التي يعرضها اختبار خادم SSL بالأسماء المستخدمة في OpenSSL (nginx).
في اختباراتي، أضفت :ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA، وبعد إعادة البناء، يبدو الاختبار كالتالي:
ربما توجد خلل في الاختبار؟ لا أملك إصدار Safari قديمًا لإجراء الاختبار. نحن ندعم فقط Safari 10 وما بعده. هل أنت متأكد من أن الفشل لا يزال بسبب خطأ في TLS؟
تفحصت ملفات تكوين Discourse قليلًا ووجدت templates/web.ssl.template.yml. ما الفرق بين إجراء هذا التغيير على الشفرات عبر ملف app.yml وبين مجرد تغيير قائمة ssl_ciphers مباشرة في templates/web.ssl.template.yml؟
لا أملك إصدار Safari قديمًا لإجراء الاختبار. نحن ندعم فقط Safari 10 وما بعده. هل أنت متأكد من أن الفشل لا يزال بسبب خطأ في TLS؟