Deprecation of Weak TLS 1.2 Ciphers and Implementation of TLS 1.3 Support

	اللغة العربية - الترجمة الآلية	
Български - الترجمة الآلية Čeština - الترجمة الآلية Dansk - الترجمة الآلية Deutsch - الترجمة الآلية Ελληνικά - الترجمة الآلية English Español - الترجمة الآلية Suomi - الترجمة الآلية Français (France) - الترجمة الآلية עברית - الترجمة الآلية Hrvatski - الترجمة الآلية Magyar - الترجمة الآلية Italiano - الترجمة الآلية 日本語 - الترجمة الآلية Қазақ тілі - الترجمة الآلية 한국어 - الترجمة الآلية Bahasa Malaysia - الترجمة الآلية Nederlands - الترجمة الآلية Norsk - الترجمة الآلية Polski - الترجمة الآلية Português (Brasil) - الترجمة الآلية Română - الترجمة الآلية Русский - الترجمة الآلية Slovenčina - الترجمة الآلية Slovenščina - الترجمة الآلية Srpski - الترجمة الآلية Svenska - الترجمة الآلية ไทย - الترجمة الآلية Türkçe - الترجمة الآلية українська - الترجمة الآلية 简体中文 - الترجمة الآلية 繁體中文 - الترجمة الآلية

سؤال متكرر KB0902767

إهمال TLS 1.2 Ciphers الضعيف وتطبيق دعم TLS 1.3

تمت ترجمة مقال قاعدة المعرفة هذا آليًا تسهيلاً لك. ولا تقدم SAP أي ضمان فيما يتعلق بصحة الترجمة الآلية أو اكتمالها. ويمكنك العثور على المحتوى الأصلي عن طريق التبديل إلى اللغة الإنجليزية باستخدام محدد اللغة.

العرض

تلتزم SAP Ariba وSAP Business Network بحماية أمان العملاء ومورِّديهم. ستقوم SAP Ariba وSAP Business Network بتطبيق بعض التغييرات الإلزامية لضمان استخدام خوارزميات تشفير أقوى وآليات أمان محسَّنة وحماية أفضل من الثغرات الأمنية المعروفة.

البيئة

إزالة TLS 1.2 ciphers الضعيفة ضرورية لتحسين أمان SAP Ariba وSAP Business Network. يمكن للمهاجمين استغلال الشفرات الضعيفة لفك تشفير البيانات الحساسة أو تنفيذ هجمات في الوسط أو المساس بسلامة الاتصالات
بالإضافة إلى ذلك، يقضي TLS 1.3 على خوارزميات وبروتوكولات التشفير القديمة والضعيفة، مما يجعله أكثر أمناً ضد الهجمات المعروفة مقارنة بالإصدارات السابقة.

الحل

ما الذي سيتغير بعد 24 يناير 2025؟

سيكون هناك تغيير في تطبيقات SAP Ariba واتصالات cipher suite المدعومة من SAP Business Network بدءًا من 24 يناير 2025. في هذا التاريخ، سيتم تطبيق معايير أمان اتصال TLS cipher suite الجديدة؛ سينتهي دعم اتصالات TLS 1.2 الضعيفة وسيبدأ دعم اتصالات TLS 1.3.

سيبدأ نشر تغييرات أمان طبقة النقل من 24 يناير 2025، في جميع مراكز بيانات SAP Ariba وBusiness Network.

ملاحظة: إذا كنت تخطط لإزالة بروتوكول TLS 1.2، فيرجى الامتناع عن القيام بذلك حتى 24 يناير 2025. ونظرًا لأن هذا هو نهج مرحلي، فإن إزالة TLS 1.2 قد يؤدي إلى حالات فشل في التكامل.

ما هي مجموعات الشفرات التي سيتم إهمالها؟ كيف يمكن تحديد الشفرات المطلوب إزالتها؟

سيتم إهمال TLS 1.2 cipher suites التالية:

الشفرات المستندة إلى CBC:

لن يتم دعم أي شفرات تستخدم نمط التشفير CBC، بعض الأمثلة على الشفرات المستندة إلى CBC:

TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_DH_RSA_WITH_AES_128_CBC_SHA256
TLS_DH_RSA_WITH_AES_256_CBC_SHA256
TLS_DH_DSS_WITH_AES_128_CBC_SHA256
TLS_DH_DSS_WITH_AES_256_CBC_SHA256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_DH_anon_WITH_AES_128_CBC_SHA256
TLS_DH_anon_WITH_AES_256_CBC_SHA256
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA

الشفرات المستندة إلى التبادل الأساسي RSA

لن يتم دعم أي شفرة تستخدم RSA كخوارزمية تبادل مفاتيح. مثال على الشفرات المستندة إلى تبادل مفتاح RSA:

TLS_RSA_WITH_NULL_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_256_GCM_SHA384

شفرات على أساس SHA-1.

لن يتم دعم أي شفرة تستخدم تجزئة SHA/SHA-1. أمثلة على الشفرات المستندة إلى SHA-1:

TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA

لماذا تقوم Ariba وBusiness Network بإزالة TLS 1.2 cipher suites الضعيفة؟

وضع Cipher Block Chaining (CBC) هو نمط شهير للتشغيل لشفرات الكتل. ومع ذلك، فهي مزودة بالعديد من نقاط الضعف مثل هجمات إعادة الاستخدام الرابعة، وتعبئة هجمات أوراكل، وهجمات بت فليبينغ وما إلى ذلك.

SHA-1 (خوارزمية التجزئة الآمنة 1) لديها العديد من الثغرات الموثقة جيدا التي تجعلها أقل أمنا لتطبيقات التشفير. القليل من الأمثلة على SHA أو SHA-1 hashing الخوارزمية تشمل ضعف التصادم، هجمات تمديد الطول الخ.

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

إزالة TLS 1.2 ciphers الضعيفة ضرورية لتحسين أمان تطبيقات SAP Ariba وSAP Business Network. يمكن للمهاجمين استغلال الشفرات الضعيفة لفك تشفير البيانات الحساسة، أو تنفيذ هجمات في الوسط، أو المساس بسلامة الاتصالات.

ما هي TLS 1.2 ciphers التي يجب استخدامها بدلاً من الشفرات الضعيفة؟

بدلاً من شفرات نمط CBC، استخدم GCM (Galois/Counter Mode) أو CCM (عداد بـ CBC-MAC) للتشفير المصدق عليه، والذي يوفر كل من السرية والتكامل

بدلاً من شفرات SHA-1، انتقل إلى بدائل أكثر أمانًا مثل SHA-256 أو SHA-3 لجميع تطبيقات التشفير، وخاصة تلك التي تتضمن التوقيعات الرقمية والشهادات والتحقق من السلامة.

بدلاً من TLS_RSA ciphers، استخدم بروتوكولات تبادل المفاتيح الحديثة التي تدعم السرية الأمامية مثل ECDHE أو DHE (Diffie-Hellman Ephemeral).

ستدعم Ariba وBusiness Network فقط TLS 1.2 ciphers suites التالية التي تعتبر قوية مقارنة بالمجموعات التي يتم إهمالها:

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

بالإضافة إلى ذلك، لن تدعم SAP Ariba وBusiness Network سوى TLS 1.3 cipher suites التالية:

TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256

يجب على العملاء التأكد من أنهم يدعمون على الأقل أحد مجموعات الشفرات المذكورة أعلاه

هل هذا قابل للتطبيق على HTTP أو HTTPS؟

ينطبق هذا على HTTPS، لأن HTTPS تستخدم بروتوكول أمان طبقة النقل

ما هي أجنحة الشفرات الإضافية التي نحتاج إلى دعمها؟

يرجى التأكد من أنها تدعم اتباع مجموعات الشفرات القوية (على الأقل):

TLS 1.3 cipher:

TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256

TLS 1.2 ciphers:

هل توجد أي طريقة للوصول إلى لأنظمة العملاء/الشركاء الخارجيين (مثل استخدام واجهة برمجة التطبيقات/خدمة الويب/ITK وما إلى ذلك) للتحقق مما إذا كان يمكن تأثرها؟

يمكن للعملاء/الشركاء استخدام روابط الاختبار التالية لاختبار اتصالاتهم:

رابط الاختبار لبروتوكول TLS 1.2: ممكَّن بـ TLS1.2 ciphers فقط.
https://tls12-strong-cipher-check.xglab.ariba.com

إذا كان العميل يمكنه إنشاء اتصال بنقطة النهاية، فسيقوم الخادم بإرجاع الرسالة "OK". إذا كانت النتيجة مختلفة عن "موافق" أو فشل في الاتصال، فيجب على نظام العميل/الشريك تمكين TLS 1.2 ciphers القوية المذكورة للسماح بالاتصال الناجح

رابط الاختبار لبروتوكول TLS 1.3: ممكَّن بـ TLS 1.3 ciphers فقط.
https://tls13-strong-cipher-check.xglab.ariba.com/

إذا كان العميل يمكنه إنشاء اتصال بنقطة النهاية، فسيقوم الخادم بإرجاع الرسالة "OK". إذا كانت النتيجة مختلفة عن "موافق" أو فشل في الاتصال، فيجب على نظام العميل/الشريك تمكين TLS 1.3 للسماح بالاتصالات الناجحة

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

هل يمكن لشركة SAP إهلاك شفرات CBC في الوحدة المستضافة الاختبارية مقدمًا، على سبيل المثال، للسماح باختبار التأثير؟

للأسف، هذا غير ممكن لأنه يتم تطبيق هذا التغيير على البنية الأساسية بأكملها ولا يوجد خيار لتقييد هذا على وحدة مستضافة معينة فقط.

لا يمكن لمؤسستي دعم TLS 1.3 في الوقت الحالي. هل ستكون هناك أي مشكلات؟

لا، طالما أنك تدعم أعلاه، يجب ألا تكون هناك مشكلات في TLS 1.2 ciphers القوية. لا تخطط Ariba حاليًا لإزالة دعم TLS 1.2. ومع ذلك، نوصي باختبار تغييراتك باستخدام رابط الاختبار أدناه:

رابط الاختبار لبروتوكول TLS 1.2: ممكَّن بـ TLS1.2 ciphers فقط.
https://tls12-strong-cipher-check.xglab.ariba.com

تخطط مؤسستي لإزالة دعم TLS 1.2 ودعم TLS 1.3 فقط. هل ستكون هناك أي مشكلات؟

لا، ستدعم Ariba كلاً من TLS 1.3 وTLS 1.2 بمجموعات الشفرات القوية، وبالتالي لا يجب أن تكون هناك أي مشكلات.

ومع ذلك، نوصي باختبار تغييراتك باستخدام رابط الاختبار أدناه:

رابط الاختبار لبروتوكول TLS 1.3: ممكَّن بـ TLS 1.3 ciphers فقط.
https://tls13-strong-cipher-check.xglab.ariba.com/
ملاحظة: روابط الاختبار هذه مخصصة فقط لتقييم توافق الشفرات وبروتوكول أمان طبقة النقل، ولا يجب استخدامها للاختبار الشامل

كيف يمكن إضافة دعم لبروتوكول TLS 1.3؟

تختلف عملية/خطوات تحديث بروتوكول أمان طبقة النقل والشفرات لمختلف الأدوات والمكتبات.

وفيما يلي أمثلة قليلة على ذلك:

للمستعرض: الترقية إلى أحدث مستعرض أو الحد الأدنى لإصدار المستعرض التالي الذي يدعم بشكل افتراضي TLS 1.3 وTLS 1.2 ciphers القوية:

Google Chrome (88 أو أعلى)
Microsoft Edge (88 أو أعلى)
Mozilla Firefox (87 أو أعلى)
Apple Safari (15 أو أعلى)
Mobile Safari على iPad (15 أو أعلى)

لعميل JAVA:

سيتم تمكين TLS 1.3 بشكل افتراضي في عميل JDK 8. تضمن JDK 8 تطبيق مواصفات TLS 1.3 (RFC 8446) منذ (8u261). ومع ذلك، لم يتم تمكين TLS 1.3 بشكل افتراضي في عميل.

لاختبار هذا التغيير، يمكن تمكين بروتوكول TLS 1.3 على العميل باستخدام خاصية نظام jdk.tls.client.probols ، على سبيل المثال:

java -Djdk.tls.client.probols="TLSv1.3,TLSv1.2" ...
أو باستخدام خاصية نظام https.probols إذا كان التطبيق يستخدم واجهات برمجة تطبيقات HttpsURLConnection أو URL.openStream()، على سبيل المثال:

java -Dhttps.probols="TLSv1.3,TLSv1.2"
لمزيد من التفاصيل، يرجى الرجوع إلى:

https://www.java.com/en/configure_crypto.html

https://www.java.com/en/jre-jdk-cryptoroadmap.html

كيف يمكن إضافة/إزالة TLS cipher suites؟

تختلف عملية/خطوات تحديث بروتوكول أمان طبقة النقل والشفرات لمختلف الأدوات والمكتبات.

وفيما يلي أمثلة قليلة على ذلك:

بالنسبة للمستعرضات:

تأكد من أنك تستخدم أحدث إصدار من المستعرض الذي يدعم TLS 1.2 ciphers وTLS 1.3 القوي.

لعميل JAVA:

يرجى الرجوع إلى تكوين خوارزميات JDK وJRE Cryptographic (java.com) الخاصة بـ Oracle حول كيفية "تحسين ترتيب TLS cipher suite"

المدة التي سيتمكن فيها المورِّدون من الوصول إلى عناوين urls الاختبارية الواردة أدناه في إشعار أمان طبقة النقل (TLS). هل من المخطط أن تنتهي صلاحية هذه في مرحلة ما؟

ستكون روابط الاختبارات نشطة حتى الربع الأول من عام 2025 (أي مارس 2025)

رابط الاختبار لبروتوكول TLS 1.2: ممكَّن بـ TLS1.2 ciphers فقط.
https://tls12-strong-cipher-check.xglab.ariba.com

رابط الاختبار لبروتوكول TLS 1.3: ممكَّن بـ TLS 1.3 ciphers فقط.
https://tls13-strong-cipher-check.xglab.ariba.com/

راجع أيضًا

رابط الاختبار لبروتوكول TLS 1.2: ممكَّن بـ TLS1.2 ciphers فقط.
https://tls12-strong-cipher-check.xglab.ariba.com

رابط الاختبار لبروتوكول TLS 1.3: ممكَّن بـ TLS 1.3 ciphers فقط.
https://tls13-strong-cipher-check.xglab.ariba.com/

تنطبق على

النظام الأساسي المركزي للإعداد للشراء > إطار العمل الأساسي