| |||||||||
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_GM_SHA256
TLS_RSA_WITH_AES_256_GM_SHA384
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_256_GM_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 атаки повторного использования, Padding Oracle Attacks, Bit Flipping 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 используйте GCM (режим Galois/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_GM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GM_SHA256
TLS_DHE_RSA_WITH_AES_128_GM_SHA256
TLS_DHE_RSA_WITH_AES_256_GM_SHA384
Кроме того, SAP Ariba и Business Network будут поддерживать только следующие наборы шифров TLS 1.3:
TLS_AES_256_GM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GM_SHA256
Клиентам необходимо обеспечить поддержку хотя бы одного из перечисленных выше пакетов шифров
Применимо ли оно к HTTP или HTTPS?
Это применимо к HTTPS, поскольку HTTPS использует протокол TLS
Какие дополнительные наборы шифров необходимо поддерживать?
Убедитесь, что они поддерживают следующие надежные наборы шифров (по крайней мере):
Шифр TLS 1.3:
TLS_AES_256_GM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GM_SHA256
Шифры TLS 1.2:
TLS_ECDHE_RSA_WITH_AES_256_GM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GM_SHA256
TLS_DHE_RSA_WITH_AES_128_GM_SHA256
TLS_DHE_RSA_WITH_AES_256_GM_SHA384
Существует ли способ для внешних партнеров/клиентских систем (например, с помощью 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 и шифров и не должны использоваться для комплексного тестирования
Можно ли заранее амортизировать шифры 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.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, см. в разделе Настройка алгоритмов шифрования JDK и JRE Oracle (java.com)
Как долго поставщики смогут получать доступ к приведенным ниже тестовым URL, указанным в уведомлении TLS. Планируется ли на определенном этапе их истечь?
Тестовые URL будут активны до 1 квартала 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