Deprecation of Weak TLS 1.2 Ciphers and Implementation of TLS 1.3 Support

	Русский - Машинный перевод	
Deutsch - Машинный перевод English Español - Машинный перевод Français (France) - Машинный перевод Italiano - Машинный перевод 日本語 - Машинный перевод 한국어 - Машинный перевод Português (Brasil) - Машинный перевод 简体中文 - Машинный перевод

Вопросы и ответы KB0902767

Устаревание слабых шифров TLS 1.2 и внедрение поддержки TLS 1.3

Для Вашего удобства эта статья базы знаний переведена машинными средствами. SAP не предоставляет никаких гарантий правильности или полноты машинного перевода. Исходное содержимое можно увидеть, переключившись на английский язык с помощью селектора языка.

Симптом

SAP Ariba и SAP Business Network стремятся защитить безопасность клиентов и их поставщиков. SAP Ariba и SAP Business Network внесут некоторые обязательные изменения, чтобы обеспечить использование более мощных криптографических алгоритмов, расширенных механизмов безопасности и лучшей защиты от известных уязвимостей.

Среда

Удаление шифров TLS 1.2 со слабым шифрованием важно для повышения безопасности SAP Ariba и SAP Business Network. Слабые шифры могут использоваться злоумышленниками для расшифровки конфиденциальных данных, выполнения атак посредника или компрометации целостности коммуникаций.
Кроме того, TLS 1.3 устраняет устаревшие и уязвимые криптографические алгоритмы и протоколы, что делает его более безопасным против известных атак по сравнению с предыдущими версиями.

Расширение

Что изменится после 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) — популярный режим работы блочных шифров. Тем не менее, он оснащен множеством уязвимостей, таких как атаки повторного использования IV, атаки Oracle Padding, Bit Fliping Attacks и т. д.

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

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

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

Какие шифры TLS 1.2 следует использовать вместо слабых шифров?

Вместо шифров CBC mode используйте GCM (режим Галуа/Counter) или 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:

Существует ли способ для внешних партнеров/клиентских систем (например, использование API/веб-сервиса/ITK и т. д.) для проверки возможности их влияния?

Клиенты/партнеры могут использовать следующие тестовые URL для тестирования соединения:

Тестовый URL для протокола TLS 1.2: включен только с шифрами TLS1.2.
https://tls12-strong-cipher-check.xglab.ariba.com

Если клиент может установить соединение с конечной точкой, сервер вернет сообщение "ОК". Если результат отличается от "ОК" или сбоя соединения, то система клиента/партнера должна активировать упомянутые надежные шифры TLS 1.2, чтобы обеспечить успешное соединение.

Тестовый URL для протокола TLS 1.3: включен только с шифрами TLS 1.3.
https://tls13-strong-cipher-check.xglab.ariba.com/

Если клиент может установить соединение с конечной точкой, сервер вернет сообщение "ОК". Если результат отличается от "ОК" или сбоя соединения, то система клиента/партнера должна активировать 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

Моя организация планирует удалить поддержку 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.protocols, если приложение использует API HttpsURLConnection или URL.openStream(), например:

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:

Сведения о том, как улучшить порядок набора шифров TLS, см. в разделе Настройка криптографических алгоритмов Oracle JDK и JRE (java.com).

Как долго поставщики будут иметь доступ к приведенным ниже тестовым 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/

Применимо к

Базовая платформа закупок > Base Framework