Svenska - Maskinöversättning
Svar på vanliga frågor KB0902767
E-post
Utfasning av svaga TLS 1.2-chiffer och implementering av TLS 1.3-support
Denna kunskapsdatabasartikel har maskinöversatts. SAP ger ingen garanti för maskinöversättningens riktighet eller fullständighet. Du kan se ursprungsinnehållet genom att växla till engelska via språkväljaren.
Symtom

SAP Ariba och SAP Business Network har åtagit sig att skydda säkerheten för kunderna och deras leverantörer. SAP Ariba och SAP Business Network implementerar obligatoriska ändringar för att säkerställa användning av starkare kryptografiska algoritmer, förbättrade säkerhetsmekanismer och bättre skydd mot kända sårbarheter.


Miljö

Lösning

Vad kommer att ändras efter 24 januari 2025?

Från och med 24 januari 2025 kommer cipher suite-anslutningar som stöds av SAP Business Network och SAP Ariba-applikationerna att ändras. Detta datum kommer nya säkerhetsstandarder för TLS cipher suite-anslutningar att implementeras. Stöd för svaga TLS 1.2-anslutningar upphör och stöd för TLS 1.3-anslutningar kommer att inledas.

Distributionen av TLS-ändringar startar den 24 januari 2025 i alla SAP Ariba- och Business Network-datacenter.

Obs! Om du planerar att ta bort TLS 1.2-protokollet ska du avstå från att göra det till och med 24 januari 2025. Eftersom detta är en stegvis strategi och om TLS 1.2 tas bort skulle det leda till misslyckad integration.

Vilka chiffersviter kommer att fasas ut? Hur identifierar man vilka chiffer som ska tas bort?

Följande TLS 1.2 cipher suites kommer att fasas ut:

CBC-baserade chiffer:

Cipher som använder CBC-krypteringsläge stöds inte. Några exempel på CBC-baserade chiffer:

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

Utbytesbaserade chiffer för RSA-nyckel

Cipher som använder RSA som algoritm för nyckelutbyte stöds inte. Exempel på RSA-nyckelutbytesbaserade chiffer:

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 hash-baserade chiffersviter.

Cipher som använder SHA/SHA-1-hashing stöds inte. Exempel på SHA-1-baserade chiffer:

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

Varför tar Ariba och Business Network bort svaga TLS 1.2 cipher suites?

Cipher Block Chaining-läget (CBC) är ett populärt driftssätt för blockchiffer. Den är dock utrustad med många sårbarheter såsom IV återanvändningsattacker, Padd Oracle Attacks, Bit Flipping Attacks etc.

SHA-1 (Secure Hash Algorithm 1) har flera väldokumenterade sårbarheter som gör det mindre säkert för kryptografiska applikationer. Några exempel på SHA eller SHA-1 hash-algoritm är kollisionssårbarheter, längdförlängningsattacker etc.

TLS_RSA (Transport Layer Security som använder RSA för nyckelutbyte och autentisering) har flera sårbarheter som kan äventyra kommunikationssäkerheten. Några exempel på TLS_RSA är Brist på framåtsekretess, sårbarhet för nyckelkompromisser, tidsattacker etc.

Att ta bort svaga TLS 1.2 ciphers är viktigt för att förbättra säkerheten för SAP Ariba-applikationer och SAP Business Network-applikationer. Svaga chiffer kan utnyttjas av angripare för att dekryptera känsliga data, utföra man-i-mitten-attacker eller äventyra integriteten i kommunikationen.

Vilka TLS 1.2 chiffer ska användas i stället för svaga chiffer?

I stället för CBC-lägeschiffer, använd GCM (Galois/Counter Mode) eller CCM (Counter with CBC-MAC) för autentiserad kryptering, vilket ger både konfidentialitet och integritet

Istället för SHA-1 chiffer, gå över till säkrare alternativ som SHA-256 eller SHA-3 för alla kryptografiska applikationer, särskilt de som involverar digitala signaturer, certifikat och integritetsverifiering.

I stället för TLS_RSA-chiffer, använd moderna Key Exchange-protokoll som stöder framåtsekretess som ECDHE eller DHE (Diffie-Hellman Ephemeral).

Ariba och Business Network har endast stöd för följande TLS 1.2 ciphers suites som anses starka jämfört med de som fasas ut:

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

Dessutom stöder SAP Ariba och Business Network endast följande TLS 1.3 cipher suites:

TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256

Kunder måste se till att de stöder minst en av de ovan nämnda chiffersviterna

Gäller detta HTTP eller HTTPS?

Detta är tillämpligt för HTTPS, eftersom HTTPS använder TLS-protokoll

Vilka ytterligare chiffersviter behöver vi stödja?

Se till att de har stöd för följande starka chiffersviter (minst):

TLS 1.3-chiffer:

TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256

TLS 1.2-chiffer:

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

Finns det något sätt för externa partner/klientsystem (som att använda API/webbtjänst/ITK och så vidare) att verifiera om de kan påverkas?

Kunder/partners kan använda följande test-URL:er för att testa sin anslutning:

Test-URL för TLS 1.2-protokoll: Endast aktiverat med TLS1.2-chiffer.
https://tls12-strong-cipher-check.xglab.ariba.com

Om klienten kan upprätta en anslutning till slutpunkten returnerar servern meddelandet "OK". Om resultatet skiljer sig från "OK" eller ett anslutningsfel måste kunden/partnersystemet aktivera de angivna starka TLS 1.2-chiffrorna för att anslutningen ska lyckas

Test-URL för TLS 1.3-protokoll: Endast aktiverat med TLS 1.3 ciphers.
https://tls13-strong-cipher-check.xglab.ariba.com/

Om klienten kan upprätta en anslutning till slutpunkten returnerar servern meddelandet "OK". Om resultatet skiljer sig från "OK" eller ett anslutningsfel måste kunden/partnersystemet aktivera TLS 1.3 för att anslutningar ska kunna upprättas

OBS! Dessa test-URL:er är endast avsedda för utvärdering av TLS-protokoll och chifferkompatibilitet och ska inte användas för end-to-end-testning

Är det möjligt för SAP att skriva av CBC-chiffer i test-tenanten i förväg, t.ex. för att tillåta påverkanstest?

Tyvärr är detta inte möjligt eftersom ändringen tillämpas för hela landskapet och det inte finns något alternativ för att begränsa detta för en viss tenant.

Min organisation har för närvarande inte stöd för TLS 1.3. Kommer det att bli några frågor?

Nej, så länge du stöder ovan nämnda starka TLS 1.2-chiffer bör det inte vara några problem. Ariba planerar för närvarande inte att ta bort stödet för TLS 1.2. Vi rekommenderar dock att du testar dina ändringar med nedanstående test-URL:

Test-URL för TLS 1.2-protokoll: Endast aktiverat med TLS1.2-chiffer.
https://tls12-strong-cipher-check.xglab.ariba.com

OBS! Dessa test-URL:er är endast avsedda för utvärdering av TLS-protokoll och chifferkompatibilitet och ska inte användas för end-to-end-testning

Min organisation planerar att ta bort stödet för TLS 1.2 och har endast stöd för TLS 1.3. Kommer det att bli några frågor?

Nej, Ariba kommer att ha stöd för både TLS 1.3 och TLS 1.2 med starka chiffersviter och därför bör inga problem uppstå.

Vi rekommenderar dock att du testar dina ändringar med nedanstående test-URL:

Test-URL för TLS 1.3-protokoll: Endast aktiverat med TLS 1.3 ciphers.
https://tls13-strong-cipher-check.xglab.ariba.com/
OBS! Dessa test-URL:er är endast avsedda för utvärdering av TLS-protokoll och chifferkompatibilitet och ska inte användas för end-to-end-testning

Hur lägger jag till stöd för TLS 1.3-protokoll?

Processen/stegen för uppdatering av TLS-protokollet och chiffer varierar för olika verktyg och bibliotek.

Några exempel är följande:

För webbläsare: Uppgradera till den senaste webbläsaren eller minst följande webbläsarversion som som standard har stöd för TLS 1.3 och starka TLS 1.2 chiffer:

Google Chrome (88 eller senare)
Microsoft Edge (88 eller senare)
Mozilla Firefox (87 eller senare)
Apple Safari (15 eller senare)
Mobile Safari på iPad (15 eller senare)

För JAVA-klient:

TLS 1.3 aktiveras som standard i -klienten för JDK 8. JDK 8 har inkluderat en implementering av TLS 1.3-specifikationen (RFC 8446) sedan dess (8u261). TLS 1.3 har dock ännu inte aktiverats som standard i -klienten.

För att testa denna ändring kan TLS 1.3-protokollet aktiveras i -klienten genom att använda systemegenskapen jdk.tls.client.protokolls, till exempel:

java -Djdk.tls.client.protokolls="TLSv1.3.TLSv1.2" ...
eller genom att använda systemegenskapen https.protokolls om applikationen använder API:erna HttpsURLConnection eller URL.openStream(), till exempel:

java -Dhttps.protokollen="TLSv1.3,TLSv1.2"
För mer information, se:

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

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

Hur lägger man till/tar bort TLS cipher suites?

Processen/stegen för uppdatering av TLS-protokollet och chiffer varierar för olika verktyg och bibliotek.

Några exempel är följande:

För webbläsare:

Säkerställ att du använder den senaste versionen av webbläsaren som stöder starka TLS 1.2 ciphers och TLS 1.3.

För JAVA-klient:

Se Konfigurera Oracles JDK och JRE Cryptographic Algorithms (java.com) om hur du "Förbättra ordningen på TLS cipher suite"

Hur länge leverantörer kommer att ha åtkomst till nedanstående test-URL:er som anges i TLS-meddelandet. Planeras dessa att löpa ut någon gång?

Test-URL:erna kommer att vara aktiva till Q1 2025 (dvs. mars 2025)

Test-URL för TLS 1.2-protokoll: Endast aktiverat med TLS1.2-chiffer.
https://tls12-strong-cipher-check.xglab.ariba.com

Test-URL för TLS 1.3-protokoll: Endast aktiverat med TLS 1.3 ciphers.
https://tls13-strong-cipher-check.xglab.ariba.com/


Se även

Test-URL för TLS 1.2-protokoll: Endast aktiverat med TLS1.2-chiffer.
https://tls12-strong-cipher-check.xglab.ariba.com



Test-URL för TLS 1.3-protokoll: Endast aktiverat med TLS 1.3 ciphers.
https://tls13-strong-cipher-check.xglab.ariba.com/



Gäller för

Inköp - kärnplattform > Basramverk

Användningsvillkor  |  Copyright  |  Säkerhetsinformation  |  Sekretess