Bagaimana cara membuat TLS "modern" dan browser "usang" ramah?

Topik ini didorong oleh diskusi posting sebelumnya , di mana suara administrator server web yang peduli terdengar: TLS 1.2 dan AEAD adalah pilihan orang yang sehat, tetapi siapa yang akan menyesali pengguna browser yang "ketinggalan zaman"? Mari kita bahas ini - dugaan ketidakcocokan antara browser TLS "modern" dan "lama".



Hipotesisnya adalah sebagai berikut: jika hanya versi stabil dari protokol keamanan lapisan transport TLS (1.2 dan 1.3) dan cipher suite (AEAD) yang tersisa di server web, pengguna browser "usang" tidak akan dapat mengakses situs.



Mari kita mengambil perjalanan opsional ke dalam sejarah ... Pada tahun 2005 (yaitu 16 tahun yang lalu), Badan Keamanan Nasional AS mengumumkan korpus standar, pedoman, rekomendasi dan dokumen pendukung lainnya tentang penggunaan algoritma kriptografi - Kriptografi NSA Suite B.



Pada tahun 2009 IETF menerbitkan RFC5430Profil Suite B untuk Keamanan Lapisan Transportasi, yang menetapkan protokol dan cipher suite mana yang harus digunakan untuk koneksi HTTPS untuk memenuhi persyaratan NSA. Meskipun demikian, untuk memenuhi persyaratan ini, server web dan browser web harus mendukung TLS versi 1.2 dan rangkaian penyandian TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 dan TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384.



Artinya, setidaknya selama 11 tahun terakhir, pengembang telah mengetahui persyaratan apa yang harus dipenuhi produk mereka agar dapat memenuhi syarat untuk pesanan pemerintah Amerika. Oleh karena itu, Anda mungkin akan melihat fakta berikut tanpa mengherankan: semua browser yang digunakan saat ini mendukung cipher suite yang disebutkan dalam versi dengan kunci sandi 128-bit, dan banyak (tetapi tidak semua) - dan dengan 256-bit.



Ini bisa menjadi akhir artikel, merekomendasikan bahwa semua administrator server web meninggalkan dukungan hanya untuk TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 dan tidak peduli dengan mitos tentang ketidakcocokan TLS 1.2 dengan browser "usang", jika bukan karena nuansa: dalam versi TLS lebih muda dari 1.3, algoritme tanda tangan digital harus dalam sandi yang sama dengan algoritme dalam sertifikat TLS, dan kurang dari 6% server web dengan sertifikat yang ditandatangani menggunakan algoritme ECDSA di zona domain .RU , sisanya digunakan untuk penandatanganan RSA.



Siapa yang harus disalahkan adalah pertanyaan dari studi terpisah; kami tertarik pada apa yang harus dilakukan? Pertama-tama, mari kita ingat bahwa tidak hanya kombinasi ECDHE + ECDSA + AES yang direkomendasikan oleh NSA, tetapi juga beberapa di antara kumpulan sandi yang kuat saat ini:





Sebanyak 19 suite cipher yang kuat, tetapi tidak semuanya cocok untuk digunakan dalam kehidupan nyata di server web publik: algoritme enkripsi CAMELLIA, seperti AES dalam mode CCM, didukung oleh lebih dari siapa pun, dengan CHACHA20 dan perangkat setia lainnya. pendamping POLY1305 hanyalah browser modern yang relatif familiar, dan untuk menggunakan cipher suite berbasis ECDSA, seperti yang telah disebutkan, diperlukan sertifikat TLS yang sesuai. Jadi, kami hanya memiliki 4 cipher suite "tambahan" yang



tersisa : TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256;

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384;

TLS_DHE_RSA_WITH_AES_128_GCM_SHA256;

TLS_DHE_RSA_WITH_AES_256_GCM_SHA384.



Sangat menggoda untuk mengasumsikan bahwa jika browser mendukung kombinasi ECDHE + ECDSA, maka itu pasti akan mengatasi ECDHE + RSA, tetapi ini tidak selalu terjadi - banyak yang hanya dapat melakukan DHE + RSA, dan untuk memenuhi permintaan semua browser lama, di situs dengan sertifikat RSA Anda memerlukan dukungan dua cipher suite:



TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256;

TLS_DHE_RSA_WITH_AES_128_GCM_SHA256.



Ini akan memberi kami kompatibilitas dengan setidaknya sistem operasi dan browser berikut:



Android 4.4.2 + Browser Android (Chrome);

Windows XP + Chrome 49 / Firefox 49 / Opera 12.18;

Windows 7 + Internet Explorer 11 / Chrome 31 / Firefox 31;

OS X + Firefox 29 / Chrome 37;

iOS 9 + Safari 9;

Java 8b.



Saya tidak akan mengatakan tentang sistem * nix - itu tergantung pada perakitan, tetapi jelas bahwa masalahnya tidak ada seperti itu. Satu-satunya masalah akan muncul dengan Windows Phone 8.1 + IE 10, yang hanya mendukung satu kombinasi stabil - ECDHE + ECDSA.



Tetapi apa yang harus dilakukan oleh pengguna Windows XP + IE 6 atau Android 2.3? - admin yang peduli akan bertanya. Terusduduk tanpa akses ke Internet modern, - saya akan menjawab, - karena bahkan dukungan dari protokol server web SSL 2.0 tidak akan membantu mereka. Faktanya adalah bahwa meskipun Anda menggunakan Windows XP semua pembaruan yang dirilis untuk itu (hingga Mei 2019) dan memperbarui browser standar ke versi 8, ini hanya akan membawa dukungan untuk TLS 1.2, tetapi tidak paket cipher yang stabil. Selain itu, Windows XP tidak tahu atau tidak akan mempelajari apa itu Server Name Indication (SNI), HTML 5 Live HTML, dan CSS 3.



Apakah Anda siap demi "satu setengah penggali" yang keras kepala untuk menyimpan IP khusus untuk situs dan tidak memperbarui tata letaknya? Kemudian tambahkan dukungan, misalnya, TLS_RSA_WITH_AES_256_CBC_SHA256, tetapi Anda harus berasumsi bahwa pengguna Windows XP modern telah lama menggunakan browser alternatif yang bahkan mendukung TLS 1.3. Hal yang sama berlaku untuk Android 2.3, dengan menginstal Firefox 27 di mana kita akan mendapatkan dukungan penuh untuk cipher suite TLS 1.2 dan AEAD, dan tanpa menginstal - kita tidak akan dapat menggunakan sebagian besar situs modern, bahkan melalui HTTP.



Semua hal di atas, tentu saja, bukanlah panggilan untuk meninggalkan dukungan untuk cipher suite yang lebih kuat, yang akan diminta oleh browser modern, dan yang harus diusulkan untuk negosiasi sejak awal.



Agar tidak bangun dua kali, perhatikan secara singkat situasi dengan kurva elips. Kriptografi NSA Suite B hanya mengenali dua di antaranya - NIST P-384 dan NIST P-256, yang dukungannya di server web akan memberikan akses ke situs untuk browser modern dan "lama". Sebenarnya, itu cukup untuk hanya mendukung NIST P-384 untuk "oldies" dan Curve25519 untuk browser modern; baik, kecuali mungkin untuk menambahkan NIST P-521, untuk beberapa "oldies lanjutan".



Untuk meringkas: jika kita ingin situs tetap dapat diakses oleh browser "usang", tetapi pada saat yang sama hanya mendukung versi stabil dari protokol keamanan lapisan transport dan paket penyandian, kami akan melanjutkan sebagai berikut.



Untuk situs dengan sertifikat TLS yang ditandatangani menggunakan algoritme ECDSA, aktifkan dukungan untuk cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256.



Untuk situs dengan sertifikat TLS yang ditandatangani menggunakan algoritme RSA , aktifkan dukungan untuk cipher suite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 dan TLS_DHE_RSA_WITH_AES_128_GCM_SHA256.



Untuk kedua situs, kami akan mengaktifkan dukungan untuk kurva elips NIST P-384 atau NIST P-256 dan mengatur urutan preferensi untuk set cipher dan kurva elips, yang menurutnya set dan kurva di atas ditawarkan ke browser untuk pencocokan setelah lebih banyak yang stabil, misalnya , masing-masing setelah TLS_ECDHE_RSA_WITH_AES_ 256 _GCM_SHA 384 dan Curve25519.