 |
| ||||||||
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, 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 (режим Галуа/Лічильник) або 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 або новішої версії)
Мобільний 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.protocs, наприклад:
java -Djdk.tls.client.protocords="TLSv1.3,TLSv1.2" ...
або за допомогою властивості системи https.protocs, якщо застосунок використовує API HttpsURLConnection або URL.openStream(), наприклад:
java -Dhttps.protracts="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 Cryptographic Algorithms (java.com) Oracle про те, як покращити порядок наборів шифрів TLS
Як довго постачальники зможуть отримувати доступ до наведених нижче тестових 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/
Основна платформа закупівель > Базовий фреймворк