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

	Français (France) - Traduction automatique	
Deutsch - Traduction automatique English Español - Traduction automatique Italiano - Traduction automatique 日本語 - Traduction automatique 한국어 - Traduction automatique Português (Brasil) - Traduction automatique Русский - Traduction automatique 简体中文 - Traduction automatique

Foire aux questions KB0902767

Obsolescence des chiffrements TLS 1.2 faibles et implémentation de la prise en charge de TLS 1.3

Cet article de la base de connaissances a été traduit automatiquement pour vous faciliter la tâche. SAP ne garantit pas l'exactitude ou l'exhaustivité de cette traduction automatique. Vous pouvez trouver le contenu d'origine en passant à l'anglais à l'aide du sélecteur de langue.

Symptôme

SAP Ariba et SAP Business Network s'engagent à protéger la sécurité des clients et de leurs fournisseurs. SAP Ariba et SAP Business Network mettront en œuvre certaines modifications obligatoires pour garantir l'utilisation d'algorithmes cryptographiques plus forts, des mécanismes de sécurité améliorés et une meilleure protection contre les vulnérabilités connues.

Environnement

La suppression des chiffrements TLS 1.2 faibles est essentielle pour améliorer la sécurité de SAP Ariba et SAP Business Network. Les chiffrements faibles peuvent être exploités par les attaquants pour décrypter les données sensibles, effectuer des attaques de l'homme du milieu ou compromettre l'intégrité des communications.
En outre, TLS 1.3 élimine les algorithmes et protocoles cryptographiques obsolètes et vulnérables, ce qui le rend plus sûr contre les attaques connues par rapport aux versions précédentes.

Résolution

Qu’est-ce qui va changer après le 24 janvier 2025 ?

À partir du 24 janvier 2025, une modification sera apportée aux connexions avec suite de chiffrement prises en charge par les applications SAP Ariba et SAP Business Network. À cette date, de nouvelles normes de sécurité de connexion avec suite de chiffrement TLS seront implémentées ; la prise en charge des connexions TLS 1.2 faibles prendra fin et la prise en charge des connexions TLS 1.3 commencera.

Le déploiement des modifications TLS commencera le 24 janvier 2025, dans tous les centres de données SAP Ariba et Business Network.

Remarque : si vous prévoyez de supprimer le protocole TLS 1.2, veuillez vous abstenir de le faire jusqu'au 24 janvier 2025. Étant donné qu'il s'agit d'une approche par phases et que la suppression de TLS 1.2 entraînerait des échecs d'intégration.

Quelles suites de chiffrement vont devenir obsolètes ? Comment identifier les chiffrements à supprimer ?

Les suites de chiffrement TLS 1.2 suivantes seront obsolètes :

Chiffrements basés sur CBC :

Les chiffrements qui utilisent le mode de chiffrement CBC ne seront pas pris en charge. Quelques exemples de chiffrements basés sur 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

Chiffrements basés sur l'échange de clés RSA

Tout chiffrement utilisant RSA comme algorithme d'échange de clés ne sera pas pris en charge. Exemple de chiffrements basés sur l'échange de clés 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

suites de chiffrement basées sur le hachage SHA-1.

Tout chiffrement utilisant le hachage SHA/SHA-1 ne sera pas pris en charge. Exemples de chiffrements basés sur 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

Pourquoi Ariba et Business Network suppriment-ils les suites de chiffrement TLS 1.2 faibles ?

Le mode CBC (Cipher Block Chaining) est un mode de fonctionnement populaire pour les chiffrements par blocs. Cependant, il est équipé de nombreuses vulnérabilités telles que les attaques de réutilisation IV, Padding Oracle Attacks, Bit Flipping Attacks, etc.

SHA-1 (Secure Hash Algorithm 1) a plusieurs vulnérabilités bien documentées qui le rendent moins sécurisé pour les applications cryptographiques. Peu d'exemples d'algorithme de hachage SHA ou SHA-1 incluent les vulnérabilités de collision, les attaques d'extension de longueur, etc.

TLS_RSA (Transport Layer Security utilisant RSA pour l'échange de clés et l'authentification) présente plusieurs vulnérabilités qui peuvent compromettre la sécurité des communications. Parmi les rares exemples de TLS_RSA, citons le manque de secret avancé, la vulnérabilité aux compromis clés, les attaques de chronométrage, etc.

La suppression des chiffrements TLS 1.2 faibles est essentielle pour améliorer la sécurité des applications SAP Ariba et SAP Business Network. Les chiffrements faibles peuvent être exploités par les attaquants pour décrypter les données sensibles, effectuer des attaques de l'homme du milieu ou compromettre l'intégrité des communications.

Quels chiffrements TLS 1.2 doivent être utilisés à la place des chiffrements faibles ?

À la place des chiffrements en mode CBC, utilisez GCM (Galois/Counter Mode) ou CCM (Counter with CBC-MAC) pour le chiffrement authentifié, ce qui garantit à la fois la confidentialité et l'intégrité.

Au lieu des chiffrements SHA-1, passez à des alternatives plus sécurisées comme SHA-256 ou SHA-3 pour toutes les applications cryptographiques, en particulier celles impliquant des signatures numériques, des certificats et la vérification de l'intégrité.

À la place des chiffrements TLS_RSA, utilisez des protocoles modernes d'échange de clés qui supportent le secret avant comme ECDHE ou DHE (Diffie-Hellman Ephemeral).

Ariba et Business Network ne prendront en charge que les suites de chiffrement TLS 1.2 suivantes, considérées comme fortes par rapport à celles qui sont obsolètes :

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

En outre, SAP Ariba et Business Network ne prendront en charge que les suites de chiffrement TLS 1.3 suivantes :

TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256

Les clients doivent s'assurer qu'ils prennent en charge au moins l'une des suites de chiffrement susmentionnées.

Cela s'applique-t-il à HTTP ou HTTPS ?

Cela s'applique à HTTPS, car HTTPS utilise le protocole TLS.

Quelles sont les suites de chiffrement supplémentaires que nous devons prendre en charge ?

Assurez-vous qu'elles prennent en charge les suites de chiffrement fortes suivantes (au moins) :

Chiffrement TLS 1.3 :

TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256

Chiffrements TLS 1.2 :

Existe-t-il un moyen de vérifier s'ils peuvent être impactés par des systèmes clients/partenaires externes (tels que l'utilisation d'API, de services Web, d'ITK, etc.) ?

Les clients/partenaires peuvent utiliser les URL de test suivants pour tester leur connexion :

Tester l'URL pour le protocole TLS 1.2 : activé uniquement avec les chiffrements TLS1.2.
https://tls12-strong-cipher-check.xglab.ariba.com

Si le client peut établir une connexion au point d'extrémité, le serveur renvoie le message "OK". Si le résultat est différent de "OK" ou d'un échec de connexion, le système client/partenaire doit activer les chiffrements TLS 1.2 forts mentionnés pour permettre une connexion réussie.

Tester l'URL pour le protocole TLS 1.3 : activé uniquement avec les chiffrements TLS 1.3.
https://tls13-strong-cipher-check.xglab.ariba.com/

Si le client peut établir une connexion au point d'extrémité, le serveur renvoie le message "OK". Si le résultat est différent de "OK" ou si la connexion échoue, le système client/partenaire doit activer TLS 1.3 pour que les connexions aboutissent.

REMARQUE : Ces URL de test sont destinées uniquement à évaluer la compatibilité du protocole TLS et du chiffrement et ne doivent pas être utilisées pour les tests de bout en bout.

Est-il possible pour SAP d'amortir les chiffrements CBC dans le système de test à l'avance, par exemple pour permettre les tests d'impact ?

Malheureusement, cela n'est pas possible car cette modification est appliquée à l'ensemble de l'infrastructure et il n'est pas possible de la limiter uniquement à un locataire particulier.

Mon organisation ne peut pas prendre en charge TLS 1.3 pour le moment. Y aura-t-il des problèmes ?

Non, tant que vous prenez en charge les chiffrements TLS 1.2 forts mentionnés ci-dessus, il ne devrait y avoir aucun problème. Actuellement, Ariba ne prévoit pas de supprimer la prise en charge de TLS 1.2. Cependant, SAP vous recommande de tester vos modifications à l'aide de l'URL de test ci-dessous :

Tester l'URL pour le protocole TLS 1.2 : activé uniquement avec les chiffrements TLS1.2.
https://tls12-strong-cipher-check.xglab.ariba.com

REMARQUE : Ces URL de test sont destinées uniquement à évaluer la compatibilité du protocole TLS et du chiffrement et ne doivent pas être utilisées pour les tests de bout en bout.

Mon organisation prévoit de supprimer la prise en charge de TLS 1.2 et de prendre uniquement en charge TLS 1.3. Y aura-t-il des problèmes ?

Non, Ariba prendra en charge TLS 1.3 et TLS 1.2 avec des suites de chiffrement robustes. Il ne devrait donc pas y avoir de problèmes.

Cependant, SAP vous recommande de tester vos modifications à l'aide de l'URL de test ci-dessous :

Tester l'URL pour le protocole TLS 1.3 : activé uniquement avec les chiffrements TLS 1.3.
https://tls13-strong-cipher-check.xglab.ariba.com/
REMARQUE : Ces URL de test sont destinées uniquement à évaluer la compatibilité du protocole TLS et du chiffrement et ne doivent pas être utilisées pour les tests de bout en bout

Comment ajouter une prise en charge du protocole TLS 1.3 ?

Le processus/les étapes de mise à jour du protocole TLS et des chiffrements varie selon les outils et bibliothèques.

Voici quelques exemples :

Pour le navigateur : effectuez une mise à niveau vers le dernier navigateur ou la version de navigateur minimale suivante qui prend en charge par défaut les chiffrements TLS 1.3 et TLS 1.2 forts :

Google Chrome (88 ou supérieur)
Microsoft Edge (88 ou version supérieure)
Mozilla Firefox (87 ou version supérieure)
Apple Safari (15 ou plus)
Safari mobile sur iPad (15 ou supérieur)

Pour le client JAVA :

TLS 1.3 sera activé par défaut sur le client pour JDK 8. JDK 8 a inclus une implémentation de la spécification TLS 1.3 (RFC 8446) depuis (8u261). Cependant, TLS 1.3 n'a pas encore été activé par défaut sur le client.

Pour tester cette modification, le protocole TLS 1.3 peut être activé sur le client à l'aide de la propriété système jdk.tls.client.protocoles, par exemple :

java -Djdk.tls.client.protocoles="TLSv1.3,TLSv1.2" ...
ou en utilisant la propriété système https.protocoles si l'application utilise les API HttpsURLConnection ou URL.openStream(), par exemple :

java -Dhttps.protocoles="TLSv1.3,TLSv1.2"
Pour plus de détails, voir :

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

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

Comment ajouter/supprimer des suites de chiffrement TLS ?

Le processus/les étapes de mise à jour du protocole TLS et des chiffrements varie selon les outils et bibliothèques.

Voici quelques exemples :

Pour les navigateurs :

Assurez-vous d'utiliser la dernière version du navigateur qui prend en charge les chiffrements TLS 1.2 forts et TLS 1.3.

Pour le client JAVA :

Consultez Configure Oracle's JDK and JRE Cryptographic Algorithms (java.com) pour savoir comment "Améliorer l'ordre de la suite de chiffrement TLS"

Durée pendant laquelle les fournisseurs pourront accéder aux URL de test ci-dessous fournies dans l'avis TLS. Celles-ci doivent-elles expirer à un moment donné ?

Les URL de test seront actives jusqu'au T1 2025 (c'est-à-dire mars 2025)

Tester l'URL pour le protocole TLS 1.2 : activé uniquement avec les chiffrements TLS1.2.
https://tls12-strong-cipher-check.xglab.ariba.com

Tester l'URL pour le protocole TLS 1.3 : activé uniquement avec les chiffrements TLS 1.3.
https://tls13-strong-cipher-check.xglab.ariba.com/

Voir également

Tester l'URL pour le protocole TLS 1.2 : activé uniquement avec les chiffrements TLS1.2.
https://tls12-strong-cipher-check.xglab.ariba.com

Tester l'URL pour le protocole TLS 1.3 : activé uniquement avec les chiffrements TLS 1.3.
https://tls13-strong-cipher-check.xglab.ariba.com/

S'applique à

Core Platform d'approvisionnement > Cadre de base