| |||||||||
SAP Ariba dan SAP Business Network komited untuk melindungi keselamatan pelanggan dan pembekal mereka. SAP Ariba dan SAP Business Network akan melaksanakan beberapa perubahan wajib untuk memastikan penggunaan algoritma kriptografi yang lebih kuat, mekanisme keselamatan dipertingkatkan dan perlindungan yang lebih baik terhadap kerentanan yang diketahui.
Mengeluarkan sifer TLS lemah 1.2 adalah penting untuk meningkatkan keselamatan SAP Ariba dan SAP Business Network. Konsep yang lemah boleh diledakkan dengan penyerang untuk menyahsulit data sensitif, melakukan serangan di tengah atau menjejaskan integriti komunikasi
Di samping itu, TLS 1.3 menyingkirkan algoritma dan protokol kriptografi yang lapuk dan mudah alih, menjadikan ia lebih selamat terhadap serangan yang diketahui berbanding dengan versi sebelumnya.tumpuan
Apakah yang akan berubah selepas 24 Januari 2025?
Bermula 24 Januari 2025, akan terdapat perubahan pada aplikasi SAP Ariba dan sambungan suit SAP Business Network yang disokong. Pada tarikh ini, piawaian keselamatan sambungan suit TLS baharu akan dilaksanakan; sokongan untuk sambungan TLS & TLS lemah akan berakhir dan sokongan sambungan TLS 1.3 akan bermula.
Pengerahan perubahan TLS akan bermula daripada 24 Januari 2025, merentas semua pusat data SAP Ariba dan Business Network.
Nota: Jika anda merancang untuk mengeluarkan protokol TLS 1.2, sila elakkan daripada melakukannya sehingga 24 Januari 2025. Memandangkan ini ialah pendekatan berfasa dan mengeluarkan TLS 1.2 akan menyebabkan kegagalan penyepaduan.
Manakah kesesuaian yang akan dikecam? Bagaimanakah cara mengenal pasti sifer yang akan dikeluarkan?
Suit TLS 1.2 berikut akan dikecam:
Pelayar berasaskan CBC:
Mana-mana sifer yang menggunakan mod penyulitan CBC tidak akan disokong, Beberapa contoh Panduan CBC berdasarkan sifer:
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
Panduan berasaskan tukaran Kod RSA
Mana-mana sifer yang menggunakan RSA sebagai algoritma pertukaran Kod tidak akan disokong. Contoh sifer berdasarkan pertukaran kod 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
Suit playar berasaskan cincangan SHA-1.
Mana-mana sifer yang menggunakan cincangan SHA/SHA-1 tidak akan disokong. Contoh pelanggan berasaskan 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
Mengapakah Ariba dan Business Network mengeluarkan suites TLS lemah 1.2?
Mod Cipher Block Chling (CBC) ialah mod operasi popular untuk sifer blok. Walau bagaimanapun, ia dilengkapi dengan banyak kelemahan seperti serangan guna semula IV, Tambahan Taktik Oracle, Bit Membebankan Serangan dan lain-lain.
SHA-1 (Algoritma Cincangan Selamat 1) mempunyai beberapa kelemahan yang didokumenkan dengan baik yang menjadikannya kurang selamat untuk aplikasi kriptografi. Beberapa contoh algoritma cincangan SHA atau SHA-1 termasuk Kerentanan Perlanggaran, serangan Sambungan Panjang dll.
TLS_RSA (Keselamatan Lapisan Pengangkutan menggunakan RSA untuk pertukaran dan pengesahan kod) mempunyai beberapa kerentanan yang boleh menjejaskan keselamatan komunikasi. Beberapa contoh, TLS_RSA termasuk Lack of Forward Secrecy, Vulnerability ke Key Compromise, Timing Attacks dll.
Pengeluaran siplat TLS lemah adalah penting untuk meningkatkan aplikasi SAP Ariba dan keselamatan aplikasi SAP Business Network. Konsep yang lemah boleh diledakkan oleh penyerang untuk menyahsulit data sensitif, melakukan serangan di tengah atau menjejaskan integriti komunikasi.
Pelayar TLS mana yang perlu digunakan untuk membuat sifer lemah?
Di tempat sifer mod CBC, Gunakan GCM (Galois/CounMode) atau CCM (Pembilang dengan CBC-MAC) untuk penyulitan disahkan yang menyediakan kedua-dua kerahsiaan dan integriti
Selain daripada sifer SHA-1, beralih kepada alternatif yang lebih selamat seperti SHA-256 atau SHA-3 untuk semua aplikasi kriptografi, terutamanya yang melibatkan pengesahan tandatangan, sijil dan integriti digital.
Di tempat sifer TLS_RSA, Gunakan Protokol Pertukaran Kunci Moden yang menyokong rahsia ke hadapan seperti ECDHE atau DHE (Difffie-Hellman Ephemeral).
Ariba dan Business Network hanya akan menyokong sifer TLS 1.2 berikut yang dianggap kukuh berbanding yang dikecam:
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
Selain itu, SAP Ariba and Business Network hanya akan menyokong TLS 1.3 suites berikut:
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256
Pelanggan perlu memastikan bahawa mereka menyokong sekurang-kurangnya satu daripada suites yang dinyatakan di atas
Adakah ini boleh digunakan untuk HTTP atau HTTPS?
Ini boleh digunakan pada HTTPS, kerana HTTPS menggunakan protokol TLS
Manakah jangkaan tambahan yang perlu kami sokong?
Sila pastikan mereka menyokong kesesuaian yang kuat berikut (sekurang-kurangnya):
Kod TLS 1.3:
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256
Pesisir 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
Apakah ada apa-apa cara untuk pekongsi luaran/sistem pelanggan (seperti menggunakan API/Webservice/ITK dan lain-lain) untuk mengesahkan sama ada ia boleh terjejas?
Pelanggan/Pekongsi boleh menggunakan URL ujian berikut untuk menguji sambungan mereka:
URL Ujian untuk protokol TLS 1.2: Didayakan dengan sifer TLS1.2 sahaja.
https://tls12-strong-cipher-check.xglab.ariba.com
Jika pelanggan boleh mewujudkan sambungan ke titik hujung, pelayan akan mengembalikan mesej “OK”. Jika hasil adalah apa-apa yang berbeza dengan "OK" atau kegagalan sambungan, maka sistem pelanggan/pekongsi mesti mendayakan sifer TLS strong 1.2 yang disebut untuk membenarkan sambungan yang berjaya
URL Ujian untuk protokol TLS 1.3: Didayakan dengan fail TLS 1.3 sahaja.
https://tls13-strong-cipher-check.xglab.ariba.com/
Jika pelanggan boleh mewujudkan sambungan ke titik hujung, pelayan akan mengembalikan mesej “OK”. Jika hasil berbeza dengan "OK" atau kegagalan sambungan, maka sistem pelanggan/pekongsi mesti mendayakan TLS 1.3 untuk membenarkan sambungan yang berjaya
NOTA: URL ujian ini bertujuan untuk menilai protokol TLS sepenuhnya dan memulakan keserasian dan tidak boleh digunakan untuk ujian hujung ke hujung
Adakah ia mungkin untuk SAP menghargai sifer CBC dalam penyewa Ujian terlebih dahulu, contohnya untuk membenarkan kesan ujian?
Malangnya, ini tidak boleh dilakukan kerana perubahan ini sedang digunakan untuk keseluruhan landskap dan tiada pilihan untuk menyekatnya hanya pada penyewa tertentu.
Organisasi saya tidak boleh menyokong TLS 1.3 pada masa ini. Ada apa-apa isu?
Tidak, selagi anda menyokong sifer 1.2 Strong TLS yang dinyatakan di atas tidak sepatutnya ada apa-apa isu. Buat masa ini, Ariba tidak merancang untuk mengeluarkan sokongan bagi TLS 1.2. Walau bagaimanapun, kami mencadangkan untuk menguji perubahan anda menggunakan URL ujian di bawah:
URL Ujian untuk protokol TLS 1.2: Didayakan dengan sifer TLS1.2 sahaja.
https://tls12-strong-cipher-check.xglab.ariba.com
NOTA: URL ujian ini bertujuan untuk menilai protokol TLS sepenuhnya dan memulakan keserasian dan tidak boleh digunakan untuk ujian hujung ke hujung
Organisasi saya merancang untuk mengeluarkan sokongan bagi TLS 1.2 dan hanya menyokong TLS 1.3. Ada apa-apa isu?
Tidak, Ariba akan menyokong kedua-dua TLS 1.3 dan TLS 1.2 dengan kesesuaian yang kuat, oleh itu, ia tidak sepatutnya ada apa-apa isu.
Walau bagaimanapun, kami mencadangkan untuk menguji perubahan anda menggunakan URL ujian di bawah:
URL Ujian untuk protokol TLS 1.3: Didayakan dengan fail TLS 1.3 sahaja.
https://tls13-strong-cipher-check.xglab.ariba.com/
NOTA: URL ujian ini bertujuan semata-mata untuk menilai protokol TLS dan memulakan keserasian dan tidak boleh digunakan untuk ujian hujung ke hujung
Bagaimanakah cara menambah sokongan untuk protokol TLS 1.3?
Proses/langkah untuk mengemas kini protokol TLS dan sifer berbeza untuk alat dan pustaka yang berbeza.
Beberapa contoh adalah seperti berikut:
Untuk Pelayar: Naik taraf kepada pelayar terkini atau minimum versi pelayar berikut yang secara lalai menyokong TLS 1.3 dan Pap 1.2 TLS yang kuat:
Google Chrome (88 atau ke atas)
Microsoft Edge (88 atau ke atas)
Mozilla Firefox (87 atau di atas)
Apple Safari (15 atau ke atas)
Safari Mudah Alih pada iPad (15 atau ke atas)
Untuk pelanggan JAVA:
TLS 1.3 akan didayakan secara lalai pada pelanggan untuk JDK 8. JDK 8 telah memasukkan pelaksanaan spesifikasi TLS 1.3 (RFC 8446) sejak (8u261). Walau bagaimanapun, TLS 1.3 belum didayakan secara lalai pada pelanggan.
Untuk menguji perubahan ini, protokol TLS 1.3 boleh didayakan pada pelanggan menggunakan jdk.tls.client.protricsystem, contohnya:
java -Djdk.tls.client.protric="TLSv1.3,TLSv1.2" ...
atau dengan menggunakan sifat sistem protokol sahkan jika aplikasi menggunakan API HttpsURLConnection atau URL.openStream(), contohnya:
java -D10.20ps.protokol="TLSv1.3,TLSv1.2"
Untuk butiran lanjut, sila rujuk:
https://www.java.com/en/configure_crypto.html
https://www.java.com/en/jre-jdk-cryptoroadmap.html
Bagaimana cara menambah/mengeluarkan sikap TLS?
Proses/langkah untuk mengemas kini protokol TLS dan sifer berbeza untuk alat dan pustaka yang berbeza.
Beberapa contoh adalah seperti berikut:
Untuk Pelayar:
Pastikan anda menggunakan versi terkini pelayar yang menyokong penciptaan TLS 1.2 yang kukuh dan TLS 1.3.
Untuk pelanggan JAVA:
Sila rujuk Konfigurasikan Algoritma JDK dan JRE Cryptografi Oracle (java.com) tentang cara "Tambah baik urutan suite TLS"
Tempoh pembekal boleh mencapai url ujian di bawah yang disediakan dalam notis TLS. Adakah ini dirancang untuk tamat tempoh pada sesetengah masa?
URL ujian akan aktif sehingga Q1 2025 (iaitu. Mac 2025)
URL Ujian untuk protokol TLS 1.2: Didayakan dengan sifer TLS1.2 sahaja.
https://tls12-strong-cipher-check.xglab.ariba.com
URL Ujian untuk protokol TLS 1.3: Didayakan dengan fail TLS 1.3 sahaja.
https://tls13-strong-cipher-check.xglab.ariba.com/
URL Ujian untuk protokol TLS 1.2: Didayakan dengan sifer TLS1.2 sahaja.
https://tls12-strong-cipher-check.xglab.ariba.com
URL Ujian untuk protokol TLS 1.3: Didayakan dengan fail TLS 1.3 sahaja.
https://tls13-strong-cipher-check.xglab.ariba.com/
Procurement Core Platform > Base Framework