Български - Машинен превод
ЧЗВ KB0902767
Имейл
Извеждане от употреба на слаби шифри TLS 1.2 и внедряване на поддръжката на TLS 1.3
Тази статия от базата със знания е преведена машинно за ваше удобство. SAP не дава гаранции по отношение на точността или пълнотата на машинния превод. Можете да видите оригиналното съдържание, като превключите на английски език от селектора за езици.
Симптом

SAP Ariba и SAP Business Network се ангажират да защитават сигурността на клиентите и техните доставчици. SAP Ariba и SAP Business Network ще внедрят някои задължителни промени, за да гарантират използването на по-силни криптографски алгоритми, подобрени механизми за сигурност и по-добра защита срещу известни уязвимости.


Среда

Решение

Какво ще се промени след 24 януари 2025 г.?

От 24 януари 2025 г. ще има промяна в приложенията на SAP Ariba и поддържаните от SAP Business Network връзки с пакети с шифри. На тази дата ще бъдат внедрени нови стандарти за сигурност на връзките с пакети от шифри TLS; поддръжката на връзките със слаби TLS 1.2 ще приключи и ще започне поддръжката на връзките с TLS 1.3.

Разгръщането на TLS промените ще започне от 24 януари 2025 г. във всички центрове за данни на SAP Ariba и Business Network.

Забележка: Ако планирате да премахнете протокола TLS 1.2, моля не го правете до 24 януари 2025 г. Тъй като това е поетапен подход и премахването на TLS 1.2 би довело до неуспех на интеграцията.

Кои пакети с шифри ще бъдат непрепоръчителни? Как да идентифицираме кои шифри да бъдат премахнати?

Следните пакети с шифри TLS 1.2 ще бъдат непрепоръчителни:

CBC шифри:

Няма да се поддържат шифри, които използват режим на криптиране CBC. Няколко примера за шифри, базирани на 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

RSA шифри, базирани на обмен на ключове

Няма да се поддържа шифър, който използва RSA като алгоритъм за обмен на ключове. Пример за шифри, базирани на обмен на ключове 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

Пакети с шифри, базирани на SHA-1 хеш.

Няма да се поддържат шифри, които използват хеширане SHA/SHA-1. Примери за шифри, базирани на 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

Защо Ariba и Business Network премахват пакетите със слаби шифри TLS 1.2?

Режим Cipher Block Chaining (CBC) е популярен режим на работа за блокови шифри. Въпреки това, той е оборудван с много уязвимости, като атаки за повторно използване и т.н.

SHA-1 (Secure Hash Algorithm 1) има няколко добре документирани уязвимости, които го правят по-малко сигурен за криптографски приложения. Няколко примера за SHA или SHA-1 алгоритъм за хеширане включват уязвимост при сблъсък, атаки за удължаване на дължината и т.н.

TLS_RSA (Transport Layer Security using RSA за обмен на ключове и удостоверяване) има няколко уязвимости, които могат да компрометират сигурността на комуникациите. Няколко примера за TLS_RSA включват липса на тайна напред, уязвимост към ключов компромис, атаки във времето и т.н.

Премахването на слабите шифри TLS 1.2 е от съществено значение за подобряване на сигурността на приложенията на SAP Ariba и на приложенията на SAP Business Network. Слабите шифри могат да бъдат използвани от нападателите, за да декриптират чувствителни данни, да извършват атаки по средата или да компрометират целостта на комуникациите.

Кои шифри TLS 1.2 трябва да се използват вместо слаби шифри?

Вместо шифрите за режим CBC, използвайте GCM (Galois/Counter Mode) или CCM (брояч с CBC-MAC) за удостоверяване на криптирането, което осигурява както поверителност, така и цялост

Вместо SHA-1 шифри, преминете към по-сигурни алтернативи като SHA-256 или SHA-3 за всички криптографски приложения, особено тези, включващи цифрови подписи, сертификати и проверка на целостта.

На мястото на шифрите TLS_RSA използвайте съвременни протоколи за обмен на ключове, които поддържат тайна за препращане, като например ECDHE или DHE (Diffie-Hellman Ephemeral).

Ariba и Business Network ще поддържат само следните пакети с шифри 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

Освен това SAP Ariba и Business Network ще поддържат само следните пакети с шифри TLS 1.3:

TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256

Клиентите трябва да се уверят, че поддържат поне един от гореспоменатите пакети с шифри

Това приложимо ли е за HTTP или HTTPS?

Това е приложимо за HTTPS, тъй като HTTPS използва TLS протокол

Кои допълнителни пакети шифри трябва да поддържаме?

Моля, уверете се, че те поддържат следните пакети със силни шифри (поне):

Шифър TLS 1.3:

TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256

Шифри 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

Има ли начин външните партньори/клиентски системи (например чрез API/Webservice/ITK и т.н.) да проверят дали те могат да бъдат засегнати?

Клиентите/партньорите могат да използват следните тестови URL адреси, за да тестват връзката си:

Тестов URL за протокол TLS 1.2: Активиран само с шифри TLS1.2.
https://tls12-strong-cipher-check.xglab.ariba.com

Ако клиентът може да установи връзка с крайната точка, сървърът ще върне съобщението „OK“. Ако резултатът е различен от „OK“ или неуспешна връзка, тогава клиентската/партньорската система трябва да активира споменатите силни шифри TLS 1.2, за да позволи успешна връзка

Тестов URL за протокол TLS 1.3: Активиран само с шифри TLS 1.3.
https://tls13-strong-cipher-check.xglab.ariba.com/

Ако клиентът може да установи връзка с крайната точка, сървърът ще върне съобщението „OK“. Ако резултатът е различен от „OK“ или неуспешна връзка, тогава клиентската/партньорската система трябва да активира TLS 1.3, за да позволи успешни връзки

ЗАБЕЛЕЖКА: Тези тестови URL адреси са предназначени единствено за оценка на съвместимостта на TLS протокола и шифъра и не трябва да се използват за цялостно тестване

Възможно ли е SAP предварително да амортизира CBC шифрите в тестовия наемател, напр. да разреши тестване на въздействието?

За съжаление това не е възможно, защото тази промяна се прилага за цялата инфраструктура и няма опция за ограничаване само за конкретен наемател.

Моята организация не може да поддържа TLS 1.3 в момента. Ще има ли някакви проблеми?

Не, стига да поддържате гореспоменатите силни шифри TLS 1.2, не трябва да има проблеми. В момента Ariba не планира да премахва поддръжката за TLS 1.2. Въпреки това препоръчваме да тествате промените си чрез следния тестов URL:

Тестов URL за протокол TLS 1.2: Активиран само с шифри TLS1.2.
https://tls12-strong-cipher-check.xglab.ariba.com

ЗАБЕЛЕЖКА: Тези тестови URL адреси са предназначени единствено за оценка на съвместимостта на TLS протокола и шифъра и не трябва да се използват за цялостно тестване

Моята организация планира да премахне поддръжката за TLS 1.2 и да поддържа само TLS 1.3. Ще има ли някакви проблеми?

Не, Ariba ще поддържа и TLS 1.3, и TLS 1.2 пакети със силни шифри, поради което не трябва да има проблеми.

Въпреки това препоръчваме да тествате промените си чрез следния тестов URL:

Тестов URL за протокол TLS 1.3: Активиран само с шифри TLS 1.3.
https://tls13-strong-cipher-check.xglab.ariba.com/
ЗАБЕЛЕЖКА: Тези тестови URL адреси са предназначени единствено за оценка на съвместимостта на TLS протокола и шифъра и не трябва да се използват за тестване от край до край

Как да добавя поддръжка за протокола TLS 1.3?

Процесът/стъпките за актуализиране на протокола и шифрите на TLS варират за различните инструменти и библиотеки.

Няколко примера са следните:

За браузър: Направете ъпгрейд до най-новия браузър или до минимална следната версия на браузъра, която по подразбиране поддържа TLS 1.3 и силни шифри TLS 1.2:

Google Chrome (88 или по-нова версия)
Microsoft Edge (88 или по-нова версия)
Mozilla Firefox (87 или по-нова)
Apple Safari (15 или по-нова версия)
Mobile Safari на iPad (15 или по-нова)

За JAVA клиент:

TLS 1.3 ще бъде активиран по подразбиране за клиента за JDK 8. JDK 8 включва внедряване на спецификацията TLS 1.3 (RFC 8446) от (8u261). TLS 1.3 обаче все още не е активиран по подразбиране в клиента.

За да тествате тази промяна, протоколът TLS 1.3 може да бъде активиран за клиента чрез системното свойство jdk.tls.client.protocols, например:

java -Djdk.tls.client.protocols="TLSv1.3,TLSv1.2" ...
или чрез използване на системното свойство https.protocs, ако приложението използва HttpsURLConnection или URL.openStream() API, например:

java -Dhttps.protocols="TLSv1.3,TLSv1.2"
За повече подробности вижте:

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

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

Как се добавят/премахват пакети с шифри TLS?

Процесът/стъпките за актуализиране на протокола и шифрите на TLS варират за различните инструменти и библиотеки.

Няколко примера са следните:

За браузъри:

Уверете се, че използвате най-новата версия на браузъра, която поддържа силни шифри TLS 1.2 и TLS 1.3.

За JAVA клиент:

Моля, вижте Конфигуриране на JDK и JRE криптографски алгоритми на Oracle (java.com) за това как да „Подобряване на реда на пакетите с шифри TLS“

Колко дълго доставчиците ще имат достъп до тестовите URL адреси, посочени по-долу в известието за TLS. Планира ли се тези срокове да бъдат изтекли в даден момент?

Тестовите URL адреси ще бъдат активни до първото тримесечие на 2025 г. (т.е. март 2025 г.)

Тестов URL за протокол TLS 1.2: Активиран само с шифри TLS1.2.
https://tls12-strong-cipher-check.xglab.ariba.com

Тестов URL за протокол TLS 1.3: Активиран само с шифри TLS 1.3.
https://tls13-strong-cipher-check.xglab.ariba.com/


Вижте също

Тестов URL за протокол TLS 1.2: Активиран само с шифри TLS1.2.
https://tls12-strong-cipher-check.xglab.ariba.com



Тестов URL за протокол TLS 1.3: Активиран само с шифри TLS 1.3.
https://tls13-strong-cipher-check.xglab.ariba.com/



Прилага се за

Основна платформа за снабдяване > Базова рамка

Условия за използване  |  Авторско право  |  Политика за сигурност  |  Поверителност