دعوة لمناقشة منهجية تجميع فهرس لأمن المواقع باستخدام HTTPS

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



ولكن بعد ذلك تظهر أسئلة أقل وضوحًا ، على سبيل المثال: هل دعم TLS_RSA_EXPORT_WITH_RC4_40_MD5 "قبعة" كاملة أم مجرد عيب؟ وإذا كانت مجموعة الشفرات هذه من الستينيات والتسعينيات هي الأولى التي يتم تقديمها للعميل للاتفاق؟ وإذا لم يكن الجميع أفضل بكثير؟ وما هو "أفضل بكثير"؟ لنفترض أن TLS_PSK_DHE_WITH_AES_128_CCM_8 أفضل أم لا؟



ونتيجة لذلك ، وُلدت منهجية لتجميع فهرس ، والتي تسمح رسميًا بتقييم درجة موثوقية اتصال HTTPS بواقع 31 نقطة ، مقسمة إلى 5 مجموعات ، من "هذا ليس HTTPS على الإطلاق" إلى "استمر في ذلك!"



ما لا يمثله المؤشر بالتأكيد ، هو "الرد الروسي" على NIST / HIPAA / PCI DSS ، إلخ. لسببين.



أولاً ، يأخذ الفهرس في الاعتبار موثوقية اتصال HTTPS فقط. أداء خادم الويب (NPN / ALPN / استئناف الجلسة) ، إلخ. لا يعتبر مؤشر المادة ، وليس لذلك تم اختراعه.



والثاني هو أن NIST.SP.800 ومعايير الصناعة الأخرى تسترشد بمنحنيات NIST الإهليلجية ، حيث لا يوجد سوى القليل من عدم الثقة ، ولكن هناك أسئلة من وجهة نظر ECDLP / ECC (يمكن ترك تعليق مرح حول قبعة الرقائق في التعليقات بدون استثناء ).



على الرغم من من يدري ، ربما بمرور الوقت سينمو معيار سيادي مع الروحانية وأقواس "الجندب" و "الصهارة" من الفهرس (ولكن ليس قبل أن يتعرف عليها IETF كجزء من مجموعات التشفير القياسية لـ TLS).



الفكرة الرئيسية للمؤشر: في عام 2020 ، يمكن اعتبار TLS 1.2 وأعلى فقط مع المجموعة المقابلة من مجموعات التشفير والمنحنيات الناقصية "HTTPS حقيقي". حان الوقت لأجنحة التشفير القديمة ، حتى لو لم يكن لديها نقاط ضعف معروفة ، في سلة مهملات التاريخ. الحجج حول الحاجة إلى دعم العملاء القدامى لصالح الفقراء: لا يزال Windows XP شائعًا ، لكن مستخدميها لا يتجولون على الإنترنت اليوم من خلال Internet Explorer 8 مع Schannel ما قبل التاريخ ، ولكن يستخدمون المتصفحات المستندة إلى Chromium / Firefox والتي تستخدم NSS لهذا الغرض ... الأمر نفسه ينطبق على مستخدمي الإصدارات الأقدم من Android - إما قاموا بتثبيت متصفح بديل لا يعتمد على مكتبة تشفير النظام ، أو لا يمكنهم استخدام معظم المواقع الحديثة حتى عبر HTTP (بدون دعم CSS3 وصفقات الإبلاغ عن المخالفات الحديثة الأخرى).



من هذه المواقف يقترح انتقاد مشروع المنهجية. هل أخذت كل شيء بعين الاعتبار؟ هل شددت الصواميل بشدة؟ ألم تحرّف أي شيء؟ يوجد أدناه قائمة بالمعايير ، والرابط نص أكثر تفصيلاً ، مع ملاحظات وتعليقات .



1. المعايير الدنيا



1.1. يتم دعم اتصال HTTP (HTTPS) المشفر باستخدام بروتوكول TLS المشفر. يتم إنشاء اتصال HTTPS مع معرف البروتوكول (مخطط URI) https عبر منفذ TCP 443.



1.2. يتم التحقق من صحة تشفير الاتصال من خلال شهادة موقع TLS الإصدار 3 X.509 صالحة وغير موقعة ذاتيًا وغير فارغة صادرة عن مرجع مصدق معتمد (CA).



2. معايير إضافية



2.1. الخادم ليس عرضة للثغرات الأمنية المعروفة في تنفيذ دعم الاتصال الآمن (BEAST ، POODLE ، GOLDENDOODLE ، إلخ.)



2.2. ضغط TLS غير مدعوم.



2.3 يتم دعم إعادة التفاوض الآمن التي يبدأها الخادم فقط ؛ إعادة التفاوض التي بدأها العميل غير مدعومة.



3. المعايير الموصى بها



3.1. يتحول اتصال HTTP تلقائيًا (إجباريًا) إلى HTTPS.



3.2 يبلغ طول المفتاح العام لشهادات TLS الخاصة بالموقع 2048 بت. يتم توقيع الشهادة رقمياً باستخدام خوارزمية ≥SHA256 مع تشفير RSA أو ECDSA.



3.3 يتم دعم الإصدار 1.2 من بروتوكول TLS.



3.4. إصدار SSL و TLS ≤1.1 غير مدعومين.



3.5 يتم دعم مجموعات التشفير القياسية القائمة على خوارزميات قوية.



3.6 لا يتم دعم مجموعات التشفير الضعيفة وغير المناسبة والضعيفة.



3.7 يتم دعم المنحنيات البيضاوية الآمنة ECDLP / ECC.



3.8 تم تعيين ترتيب تنسيق مجموعات التشفير



3.9 يتم استخدام المعلمات القوية لخوارزميات اتفاقية مفتاح Diffie-Hellman (DH).



3.10. هام ملحقات TLS مدعومة.



3.11. يتم دعم مؤشر اسم الخادم (SNI).



4. المعايير الموسعة



4.1. تم نشر سلسلة شهادات TLS كاملة وغير مكررة بتسلسلها الصحيح.



4.2 تدعم شهادة TLS الخاصة بالموقع شفافية الشهادة.



4.3 تدعم شهادة TLS الخاصة بالموقع قائمة إبطال الشهادات (CRL) وبروتوكول حالة الشهادة عبر الإنترنت (OCSP).



4.4. تتوافق شهادات TLS في سلاسل بديلة مع المعايير 1.2 و 4.1.



4.5 المنحنيات البيضاوية غير الآمنة ECDLP / ECC غير مدعومة.



4.6 يتم تعيين ترتيب مطابقة المنحنيات الناقصية.



4.7 تحتوي رؤوس استجابة الخادم على رأس HTTP Strict Transport Security مع التوجيه includeSubDomains.



5. معايير المكافأة



5.1. تدعم شهادة TLS الخاصة بالموقع تدبيس OCSP.



5.2. يتم إصدار شهادة موقع TLS باستخدام إجراء التحقق من صحة المؤسسة (OV) أو التحقق الممتد (EV).



5.3 يتم دعم الإصدار 1.3 من بروتوكول TLS.



5.4. يتم تحديد ترتيب اتفاق مجموعات التشفير المستقرة من الأكثر مقاومة إلى الأقل استقرارًا (بواسطة معلمات قابلة للمقارنة).



5.5 تتضمن سجلات موارد DNS الخاصة باسم مجال الموقع سجل CAA (تخويل المرجع المصدق).



5.6 تتضمن سجلات موارد DNS الخاصة باسم مجال الموقع سجلات DS و TLSA (يتم دعم DNSSEC و DANE).



5.7 يتم دعم مؤشر اسم الخادم المشفر (ESNI).



5.8 تحتوي رؤوس استجابة HTTP على رأس Content-Security-Policy مع توجيه طلبات الترقية غير الآمنة.