 |
| ||||||||
SAP Ariba og SAP Business Network forplikter seg til å beskytte sikkerheten til kundene og deres leverandører. SAP Ariba og SAP Business Network implementerer noen obligatoriske endringer for å sikre bruken av sterkere kryptografiske algoritmer, forbedrede sikkerhetsmekanismer og bedre beskyttelse mot kjente sårbarheter.
-
Det er viktig å fjerne svake TLS 1.2-versjonsnumre for å forbedre SAP Ariba- og SAP Business Network-sikkerheten. Svake chiffer kan utnyttes av angripere for å dekryptere sensitive data, utføre man-in-the-midt-angrep eller kompromittere kommunikasjonens integritet
-
I tillegg eliminerer TLS 1.3 utdaterte og sårbare kryptografiske algoritmer og protokoller, noe som gjør den sikrere mot kjente angrep sammenlignet med tidligere versjoner.
Hva vil endres etter 24. januar 2025?
Fra og med 24. januar 2025 vil det bli en endring av SAP Ariba-applikasjoner og tilkoblinger av SAP Business Network-støttede versjonsnummersuiter. På denne datoen implementeres nye sikkerhetsstandarder for tilkoblinger av versjonsnummersuite for TLS. Støtte for tilkoblinger for svak TLS 1.2 vil utløpe, og støtte for tilkoblinger for TLS 1.3 vil starte.
Distribusjonen av TLS-endringer starter fra 24. januar 2025 på tvers av alle SAP Ariba- og Business Network-datasentre.
Merk: Hvis du planlegger å fjerne TLS 1.2-protokollen, må du avstå fra å gjøre det til 24. januar 2025. Siden dette er en trinnvis tilnærming og fjerning av TLS 1.2 vil føre til feil i integrasjonen.
Hvilke versjonsnummersuiter vil bli foreldet? Hvordan identifisere hvilke chiffer som skal fjernes?
Følgende TLS 1.2-versjonsnummersuiter avvikles:
CBC-baserte chiffer:
Eventuelle chiffer som bruker CBC-krypteringsmodus, støttes ikke. Få eksempler på CBC-baserte 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
RSA-nøkkelutvekslingsbaserte chiffer
Eventuelle chiffer som bruker RSA som nøkkelutvekslingsalgoritme, støttes ikke. Eksempel på RSA-nøkkelbyttebaserte 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 basert chiffer suiter.
Eventuelle chiffer som bruker SHA/SHA-1-hashing, støttes ikke. Eksempler på SHA-1-baserte 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
Hvorfor fjerner Ariba og Business Network svake TLS 1.2-versjonsnummersuiter?
Cipher Block Cheding (CBC)-modus er en populær operasjonsmodus for blokkchiffer. Det er imidlertid utstyrt med mange sårbarheter som IV-gjenbruksangrep, polstring orakelangrep, Bit Flipping Attacks etc.
SHA-1 (Secure Hash Algorithm 1) har flere godt dokumenterte sårbarheter som gjør den mindre sikker for kryptografiske applikasjoner. Få eksempler på SHA- eller SHA-1-hashing-algoritmer inkluderer kollisjonssårbarheter, lengdeforlengelsesangrep etc.
TLS_RSA (Transport Layer Security som bruker RSA for nøkkelutveksling og autentisering) har flere sårbarheter som kan kompromittere sikkerheten til kommunikasjon. Få eksempler, av TLS_RSA inkluderer Mangel på Forward Secrecy, sårbarhet for Key Comlover, Timing Attacks etc.
Det er viktig å fjerne svake TLS 1.2-versjonsnumre for å forbedre SAP Ariba-applikasjoner og sikkerhet for SAP Business Network-applikasjoner. Svake chiffer kan utnyttes av angripere for å dekryptere sensitive data, utføre man-in-the-midt-angrep eller kompromittere kommunikasjonens integritet.
Hvilke TLS 1.2-chiffer skal brukes i stedet for svake chiffer?
Bruk GCM (Galois/Counter Mode) eller CCM (Counter with CBC-MAC) i stedet for CBC-MAC) for autentisert kryptering, som gir både konfidensialitet og integritet
I stedet for SHA-1-chiffer kan du flytte til sikrere alternativer som SHA-256 eller SHA-3 for alle kryptografiske applikasjoner, spesielt de som involverer digitale signaturer, sertifikater og integritetsverifisering.
I stedet for TLS_RSA-chiffer, Bruk moderne nøkkelutvekslingsprotokoller som støtter fremadrettet hemmelighold som ECDHE eller DHE (Diffie-Hellman Ephemeral).
Ariba og Business Network støtter bare følgende TLS 1.2-versjonsnummersuiter som anses som sterke sammenlignet med de som foreldes:
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
I tillegg støtter SAP Ariba og Business Network bare følgende versjonsnummersuiter for TLS 1.3:
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256
Kunder må sørge for at de støtter minst én av de ovennevnte versjonsnummersuitene
Gjelder dette for HTTP eller HTTPS?
Dette gjelder for HTTPS siden HTTPS bruker TLS-protokoll
Hvilke ekstra versjonsnummersuiter må vi støtte?
Sørg for at de støtter følgende sterke versjonsnummersuiter (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
Finnes det noen måte å kontrollere om de kan påvirkes for eksterne partnere/klientsystemer (for eksempel bruk av API/webtjeneste/ITK og osv.)?
Kunder/partnere kan bruke følgende test-URL-er til å teste forbindelsen:
Test-URL for TLS 1.2-protokoll: Bare aktivert med TLS1.2-chiffer.
https://tls12-strong-cipher-check.xglab.ariba.com
Hvis klienten kan opprette en tilkobling til sluttpunktet, vil serveren returnere meldingen "OK". Hvis resultatet er noe annet enn "OK" eller en tilkoblingsfeil, må kunde-/partnersystemet aktivere de sterke TLS 1.2-versjonsnumrene som er nevnt for å tillate vellykket tilkobling
Test-URL for TLS 1.3-protokoll: Bare aktivert med TLS 1.3-chiffer.
https://tls13-strong-cipher-check.xglab.ariba.com/
Hvis klienten kan opprette en tilkobling til sluttpunktet, vil serveren returnere meldingen "OK". Hvis resultatet er noe annet enn "OK" eller en tilkoblingsfeil, må kunde-/partnersystemet aktivere TLS 1.3 for å tillate vellykkede tilkoblinger
MERK: Disse test-URL-ene er bare ment for evaluering av TLS-protokoll og chifferkompatibilitet, og skal ikke brukes til ende-til-ende-testing
Er det mulig for SAP å avskrive CBC-chiffer i testtenanten på forhånd, f.eks. for å tillate konsekvenstesting?
Dette er dessverre ikke mulig fordi denne endringen brukes for hele landskapet, og det finnes ikke noe alternativ for å begrense dette bare på en bestemt tenant.
Organisasjonen min støtter for øyeblikket ikke TLS 1.3. Vil det oppstå problemer?
Nei, så lenge du støtter ovennevnte Strong TLS 1.2-versjonsnumre, bør det ikke være noen problemer. For øyeblikket planlegger ikke Ariba å fjerne støtte for TLS 1.2. Vi anbefaler imidlertid at du tester endringene dine ved hjelp av test-URL-en nedenfor:
Test-URL for TLS 1.2-protokoll: Bare aktivert med TLS1.2-chiffer.
https://tls12-strong-cipher-check.xglab.ariba.com
MERK: Disse test-URL-ene er bare ment for evaluering av TLS-protokoll og chifferkompatibilitet, og skal ikke brukes til ende-til-ende-testing
Organisasjonen min planlegger å fjerne støtte for TLS 1.2 og støtter bare TLS 1.3. Vil det oppstå problemer?
Nei, Ariba vil støtte både TLS 1.3 og TLS 1.2 med sterke versjonsnummersuiter, derfor bør det ikke være noen problemer.
Vi anbefaler imidlertid at du tester endringene dine ved hjelp av test-URL-en nedenfor:
Test-URL for TLS 1.3-protokoll: Bare aktivert med TLS 1.3-chiffer.
https://tls13-strong-cipher-check.xglab.ariba.com/
MERK: Disse test-URL-ene er kun ment for evaluering av TLS-protokoll og chifferkompatibilitet, og skal ikke brukes til ende-til-ende-testing
Hvordan legge til støtte for TLS 1.3-protokollen?
Prosessen/trinnene for oppdatering av TLS-protokollen og chifferene varierer for forskjellige verktøy og biblioteker.
Få eksempler er som følger:
For nettleser: Oppgrader til den nyeste nettleseren eller minimum følgende nettleserversjon som standard støtter TLS 1.3 og sterke TLS 1.2-chiffer:
Google Chrome (88 eller høyere)
Microsoft Edge (88 eller høyere)
Mozilla Firefox (87 eller høyere)
Apple Safari (15 eller høyere)
Mobile Safari på iPad (15 eller høyere)
For JAVA-klient:
TLS 1.3 aktiveres som standard på -klienten for JDK 8. JDK 8 har inkludert en implementering av TLS 1.3-spesifikasjonen (RFC 8446) siden (8u261). TLS 1.3 er imidlertid ikke aktivert som standard på -klienten.
For å teste denne endringen, kan TLS 1.3-protokollen aktiveres på klienten ved hjelp av systemegenskapen jdk.tls.client.protokoller, for eksempel:
java -Djdk.tls.client.protokoller="TLSv1.3,TLSv1.2" ...
eller ved å bruke egenskapen https.protokoll-system hvis applikasjonen bruker API-ene HttpsURLConnection eller URL.openStream(), for eksempel:
java -Dhttps.protokollene="TLSv1.3,TLSv1.2"
Hvis du vil ha mer informasjon, se:
https://www.java.com/en/configure_crypto.html
https://www.java.com/en/jre-jdk-cryptoroadmap.html
Hvordan legge til / fjerne TLS versjonsnummersuiter?
Prosessen/trinnene for oppdatering av TLS-protokollen og chifferene varierer for forskjellige verktøy og biblioteker.
Få eksempler er som følger:
For nettlesere:
Sørg for at du bruker den nyeste versjonen av nettleseren som støtter sterke TLS 1.2-versjonsnumre og TLS 1.3.
For JAVA-klient:
Se Konfigurer Oracle JDK og JRE Cryptographic Algorithms (java.com) om hvordan du forbedrer rekkefølgen på TLS-versjonsnummersuitene.
Hvor lenge leverandører får tilgang til test-URL-ene nedenfor, som er oppgitt i TLS-meldingen. Er det planlagt at disse skal utløpe på et tidspunkt?
Test-URL-ene vil være aktive til Q1 2025 (dvs. Mars 2025)
Test-URL for TLS 1.2-protokoll: Bare aktivert med TLS1.2-chiffer.
https://tls12-strong-cipher-check.xglab.ariba.com
Test-URL for TLS 1.3-protokoll: Bare aktivert med TLS 1.3-chiffer.
https://tls13-strong-cipher-check.xglab.ariba.com/
Test-URL for TLS 1.2-protokoll: Bare aktivert med TLS1.2-chiffer.
https://tls12-strong-cipher-check.xglab.ariba.com
Test-URL for TLS 1.3-protokoll: Bare aktivert med TLS 1.3-chiffer.
https://tls13-strong-cipher-check.xglab.ariba.com/
Kjerneplattform for Procurement > Basis rammeverk