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 implémenteront certaines modifications obligatoires pour garantir l'utilisation d'algorithmes cryptographiques renforcés, de mécanismes de sécurité améliorés et d'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 des attaquants pour déchiffrer 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écurisé 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é pour les connexions 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. Comme 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 deviendront obsolètes :

Chiffrements basés sur CBC :

Tout chiffrement utilisant le mode de chiffrement CBC ne sera 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 SAP Business Network suppriment-ils les suites de chiffrement TLS 1.2 faibles ?

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

SHA-1 (Secure Hash Algorithm 1) possède plusieurs vulnérabilités bien documentées qui la rendent moins sécurisée pour les applications cryptographiques. Quelques 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 à l'aide de RSA pour l'échange et l'authentification des clés) présente plusieurs vulnérabilités qui peuvent compromettre la sécurité des communications. Les exemples de TLS_RSA sont le manque de confidentialité, la vulnérabilité au compromis clé, les attaques de temporisation, 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 des attaquants pour déchiffrer 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 (mode Galois/Compteur) ou CCM (compteur avec CBC-MAC) pour le chiffrement authentifié, ce qui assure à 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 d'intégrité.

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

Ariba et Business Network prendront uniquement en charge les suites de chiffrement TLS 1.2 suivantes qui sont considérées comme fortes par rapport à celles qui deviennent 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 prendront uniquement en charge 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 suites de chiffrement supplémentaires nous devons prendre en charge ?

Assurez-vous qu'ils prennent en charge les suites de chiffrement fortes (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 pour les systèmes partenaires/clients externes (tels que l'utilisation d'API/Webservice/ITK et autres) de vérifier s'ils peuvent être impactés ?

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

URL de test pour le protocole TLS 1.2 : activée avec les chiffrements TLS1.2 uniquement.
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.

URL de test 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 d'un échec de connexion, le système client/partenaire doit activer TLS 1.3 pour permettre la réussite des connexions.

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 de déprécier 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 s'applique à l'ensemble de l'infrastructure et il n'existe aucune option permettant 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 doit y avoir aucun problème. Actuellement, Ariba ne prévoit pas de supprimer la prise en charge de TLS 1.2. Cependant, nous vous recommandons de tester vos modifications à l'aide de l'URL de test ci-dessous :

URL de test pour le protocole TLS 1.2 : activée avec les chiffrements TLS1.2 uniquement.
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 en charge uniquement 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 fortes. Par conséquent, il ne devrait y avoir aucun problème.

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

URL de test 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 la prise en charge du protocole TLS 1.3 ?

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

Voici quelques exemples :

Pour le navigateur : effectuez une mise à niveau vers le navigateur le plus récent ou la version de navigateur minimum 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 plus)
Apple Safari (15 ou plus)
Safari mobile sur iPad (15 ou version ultérieure)

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 en savoir plus, 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 varient 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 :

Reportez-vous à Configurer les algorithmes cryptographiques JDK et JRE d'Oracle (java.com) pour savoir comment "Améliorer l'ordre de 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 premier trimestre 2025 (i.e. mars 2025)

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

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

Voir aussi

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

URL de test 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