Polski - Tłumaczenie maszynowe
Często zadawane pytanie KB0902767
E-mail
Wycofanie słabych szyfrów TLS 1.2 i wdrożenie obsługi TLS 1.3
Ten artykuł bazy danych został przetłumaczony maszynowo. SAP nie daje gwarancji poprawności ani kompletności tłumaczenia maszynowego. Możesz znaleźć oryginalną treść, przełączając się na język angielski za pomocą selektora języków.
Symptom

SAP Ariba i SAP Business Network dokładają wszelkich starań, aby chronić bezpieczeństwo klientów i ich dostawców. SAP Ariba i SAP Business Network wdrożą pewne obowiązkowe zmiany w celu zapewnienia użycia silniejszych algorytmów kryptograficznych, ulepszonych mechanizmów bezpieczeństwa i lepszej ochrony przed znanymi lukami w zabezpieczeniach.


Środowisko

Rozwiązanie

Co się zmieni po 24 stycznia 2025 r.?

Od 24 stycznia 2025 r. nastąpi zmiana w aplikacjach SAP Ariba i połączeniach z pakietem szyfrującym obsługiwanych przez SAP Business Network. W tym dniu wdrożone zostaną nowe standardy bezpieczeństwa połączeń pakietu szyfrującego TLS; wsparcie słabych połączeń TLS 1.2 zakończy się i rozpocznie się obsługa połączeń TLS 1.3.

Wdrożenie zmian TLS rozpocznie się 24 stycznia 2025 r. we wszystkich centrach danych SAP Ariba i Business Network.

Uwaga: Jeśli planujesz usunąć protokół TLS 1.2, powstrzymaj się od jego wykonywania do 24 stycznia 2025 r. Ponieważ jest to podejście etapowe i usunięcie TLS 1.2 doprowadziłoby do awarii integracji.

Które pakiety szyfrów zostaną wycofane? Jak zidentyfikować, które szyfry mają zostać usunięte?

Następujące pakiety szyfrujące TLS 1.2 zostaną wycofane:

Szyfry oparte na CBC:

Żaden szyfr korzystający z trybu szyfrowania CBC nie będzie obsługiwany, kilka przykładów szyfrów opartych na 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

Szyfry oparte na wymianie kluczy RSA

Szyfr, który używa RSA jako algorytmu wymiany klucza, nie będzie obsługiwany. Przykład szyfrów opartych na wymianie kluczy 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

Zestawy szyfrujące oparte na haszowaniu SHA-1.

Szyfr, który używa mieszania SHA/SHA-1, nie będzie obsługiwany. Przykłady szyfrów opartych na 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

Dlaczego Ariba i Business Network usuwają słabe pakiety szyfrujące TLS 1.2?

Tryb CBC (Cipher Block Chinking) jest popularnym trybem działania szyfrów blokowych. Jest jednak wyposażony w wiele luk w zabezpieczeniach, takich jak ataki ponownego użycia IV, wypełnienie ataków Oracle, ataki typu Bit Flipping itp.

SHA-1 (Bezpieczny Algorytm Hash 1) ma kilka dobrze udokumentowanych luk, które sprawiają, że jest mniej bezpieczny dla aplikacji kryptograficznych. Kilka przykładów algorytmu mieszania SHA lub SHA-1 obejmuje luki w zabezpieczeniach kolizji, ataki przedłużające długość itp.

TLS_RSA (Transport Layer Security przy użyciu RSA do wymiany kluczy i uwierzytelniania) ma kilka luk w zabezpieczeniach, które mogą zagrozić bezpieczeństwu komunikacji. Kilka przykładów TLS_RSA to brak tajności naprzód, podatność na kluczowe kompromisy, ataki czasowe itp.

Usunięcie słabych szyfrów TLS 1.2 jest niezbędne do zwiększenia bezpieczeństwa aplikacji SAP Ariba i aplikacji SAP Business Network. Słabe szyfry mogą być wykorzystywane przez atakujących do odszyfrowania wrażliwych danych, wykonywania ataków typu man-in-the-center lub naruszania integralności komunikacji.

Które szyfry TLS 1.2 powinny być używane zamiast słabych szyfrów?

W miejsce szyfrów trybu CBC użyj GCM (Galois/Counter Mode) lub CCM (Counter with CBC-MAC) do uwierzytelnionego szyfrowania, co zapewnia zarówno poufność, jak i integralność

Zamiast szyfrów SHA-1 przejdź do bezpieczniejszych alternatyw, takich jak SHA-256 lub SHA-3 dla wszystkich aplikacji kryptograficznych, zwłaszcza tych obejmujących podpisy cyfrowe, certyfikaty i weryfikację integralności.

W miejsce szyfrów TLS_RSA użyj nowoczesnych protokołów wymiany kluczy, które obsługują tajność przekazywania, takie jak ECDHE lub DHE (Diffie-Hellman Ephemeral).

Ariba i Business Network będą obsługiwać tylko następujące pakiety szyfrujące TLS 1.2, które są uważane za silne w porównaniu z tymi, które zostały wycofane:

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

Ponadto SAP Ariba i Business Network będą obsługiwać tylko następujące pakiety szyfrujące TLS 1.3:

TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256

Klienci muszą zapewnić obsługę co najmniej jednego z wyżej wymienionych zestawów szyfrów

Czy dotyczy to HTTP lub HTTPS?

Dotyczy to protokołu HTTPS, ponieważ protokół HTTPS używa protokołu TLS

Jakie dodatkowe pakiety szyfrujące musimy obsługiwać?

Upewnij się, że obsługują one co najmniej następujące silne pakiety szyfrujące:

Szyfr TLS 1.3:

TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256

Szyfry TLS 1.2:

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

Czy jest jakiś sposób, aby zewnętrzni partnerzy/systemy klienckie (np. za pomocą API/Webservice/ITK itp.) sprawdzały, czy może to mieć wpływ?

Klienci/partnerzy mogą używać następujących testowych adresów URL do testowania połączenia:

Testowy adres URL dla protokołu TLS 1.2: włączony tylko z szyframi TLS1.2.
https://tls12-strong-cipher-check.xglab.ariba.com

Jeśli klient może nawiązać połączenie z punktem końcowym, serwer zwróci komunikat „OK”. Jeśli wynik jest inny niż „OK” lub awaria połączenia, wówczas system klienta/partnera musi włączyć wymienione silne szyfry TLS 1.2, aby umożliwić pomyślne połączenie

Testowy adres URL dla protokołu TLS 1.3: włączony tylko z szyframi TLS 1.3.
https://tls13-strong-cipher-check.xglab.ariba.com/

Jeśli klient może nawiązać połączenie z punktem końcowym, serwer zwróci komunikat „OK”. Jeśli wynik jest inny niż "OK" lub błąd połączenia, system klienta/partnera musi włączyć TLS 1.3, aby umożliwić pomyślne połączenia

UWAGA: Te testowe adresy URL są przeznaczone wyłącznie do oceny zgodności protokołu TLS i szyfru i nie powinny być używane do kompleksowego testowania

Czy SAP może wcześniej amortyzować szyfry CBC w tenancie testowym, np. aby umożliwić wykonanie testów wpływu?

Niestety, nie jest to możliwe, ponieważ ta zmiana jest stosowana dla całej struktury i nie ma możliwości ograniczenia tego tylko dla określonego tenanta.

Moja organizacja nie może obecnie obsługiwać TLS 1.3. Będą jakieś problemy?

Nie, o ile wspierasz wyżej wymienione szyfry Strong TLS 1.2, nie powinno być żadnych problemów. Obecnie Ariba nie planuje usunąć wsparcia dla TLS 1.2. Zalecamy jednak przetestowanie zmian za pomocą poniższego testowego adresu URL:

Testowy adres URL dla protokołu TLS 1.2: włączony tylko z szyframi TLS1.2.
https://tls12-strong-cipher-check.xglab.ariba.com

UWAGA: Te testowe adresy URL są przeznaczone wyłącznie do oceny zgodności protokołu TLS i szyfru i nie powinny być używane do kompleksowego testowania

Moja organizacja planuje wycofać wsparcie dla TLS 1.2 i obsługiwać tylko TLS 1.3. Będą jakieś problemy?

Nie, Ariba będzie obsługiwać zarówno TLS 1.3, jak i TLS 1.2 silnymi pakietami szyfrującymi, dlatego nie powinno być żadnych problemów.

Zalecamy jednak przetestowanie zmian za pomocą poniższego testowego adresu URL:

Testowy adres URL dla protokołu TLS 1.3: włączony tylko z szyframi TLS 1.3.
https://tls13-strong-cipher-check.xglab.ariba.com/
UWAGA: Te testowe adresy URL są przeznaczone wyłącznie do oceny zgodności protokołu TLS i szyfru i nie powinny być używane do kompleksowego testowania

Jak dodać obsługę protokołu TLS 1.3?

Proces/kroki aktualizacji protokołu i szyfrów TLS różnią się w zależności od narzędzi i bibliotek.

Oto kilka przykładów:

Dla przeglądarki: Uaktualnij do najnowszej przeglądarki lub minimalnej następującej wersji przeglądarki, która domyślnie obsługuje szyfry TLS 1.3 i silne szyfry TLS 1.2:

Google Chrome (88 lub nowszy)
Microsoft Edge (88 lub nowszy)
Mozilla Firefox (87 lub nowsza)
Apple Safari (15 lub późniejsze)
Mobile Safari on iPad (15 lub nowszy)

Dla klienta JAVA:

TLS 1.3 zostanie domyślnie włączony w kliencie dla JDK 8. Od tego czasu JDK 8 obejmuje implementację specyfikacji TLS 1.3 (RFC 8446) (8u261). Jednak TLS 1.3 nie został jeszcze domyślnie włączony w kliencie.

Aby przetestować tę zmianę, protokół TLS 1.3 można włączyć na kliencie, korzystając z właściwości systemowej jdk.tls.client.protokoły, na przykład:

java -Djdk.tls.client.protokoły="TLSv1.3,TLSv1.2" ...
lub za pomocą właściwości systemowej https.protokoły, jeśli aplikacja korzysta z interfejsów API HttpsURLConnection lub URL.openStream(), na przykład:

java -Dhttps.protokoły="TLSv1.3,TLSv1.2"
Więcej informacji można znaleźć na stronie:

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

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

Jak dodać/usunąć pakiety szyfrujące TLS?

Proces/kroki aktualizacji protokołu i szyfrów TLS różnią się w zależności od narzędzi i bibliotek.

Oto kilka przykładów:

W przypadku przeglądarek:

Upewnij się, że używasz najnowszej wersji przeglądarki, która obsługuje silne szyfry TLS 1.2 i TLS 1.3.

Dla klienta JAVA:

Skonfiguruj algorytmy kryptograficzne JDK i JRE Oracle (java.com), aby dowiedzieć się, jak „ulepszyć kolejność pakietów szyfrów TLS”

Jak długo dostawcy będą mogli uzyskać dostęp do poniższych testowych adresów URL podanych w powiadomieniu TLS. Czy mają one w pewnym momencie wygasnąć?

Testowe adresy URL będą aktywne do I. kwartału 2025 r. (tj. Marzec 2025)

Testowy adres URL dla protokołu TLS 1.2: włączony tylko z szyframi TLS1.2.
https://tls12-strong-cipher-check.xglab.ariba.com

Testowy adres URL dla protokołu TLS 1.3: włączony tylko z szyframi TLS 1.3.
https://tls13-strong-cipher-check.xglab.ariba.com/


Zobacz także

Testowy adres URL dla protokołu TLS 1.2: włączony tylko z szyframi TLS1.2.
https://tls12-strong-cipher-check.xglab.ariba.com


Testowy adres URL dla protokołu TLS 1.3: włączony tylko z szyframi TLS 1.3.
https://tls13-strong-cipher-check.xglab.ariba.com/



Zastosowanie

Główna platforma zaopatrzeniowa > Base Framework

Warunki użytkowania  |  Prawa autorskie  |  Ujawnianie informacji o zabezpieczeniach  |  Prywatność