Undangan untuk berdiskusi tentang metodologi kompilasi indeks keamanan HTTPS situs

Kami telah menerbitkan beberapa ulasan tentang dukungan HTTPS di situs web otoritas Rusia dan dihadapkan pada kebutuhan yang tak terelakkan untuk memformalkan kriteria penilaiannya dengan lebih jelas. Jelas bahwa jika server "mengkonfirmasi" keamanan koneksi dengan sertifikat TLS orang lain, maka ini adalah "topi" dan situs terkait tidak akan menempati posisi tinggi di "peringkat".



Namun kemudian muncul pertanyaan yang tidak terlalu ambigu, misalnya: apakah dukungan untuk TLS_RSA_EXPORT_WITH_RC4_40_MD5 merupakan "topi" lengkap atau hanya kelemahan? Dan apakah cipher suite dari tahun 60 - an dan 90 - an ini adalah yang pertama ditawarkan kepada klien untuk persetujuan? Dan jika orang lain tidak jauh lebih baik? Dan apa yang "jauh lebih baik"? Katakanlah TLS_PSK_DHE_WITH_AES_128_CCM_8 lebih baik atau tidak?



Hasilnya, lahirlah metodologi untuk menyusun indeks, yang memungkinkan penilaian secara formal tingkat keandalan sambungan HTTPS sebesar 31 poin, yang dipecah menjadi 5 kelompok, dari "ini sama sekali bukan HTTPS" hingga "pertahankan!"



Yang pasti bukan indeksnya, adalah "tanggapan Rusia" terhadap NIST / HIPAA / PCI DSS, dll. karena dua alasan.



Pertama, indeks hanya mempertimbangkan keandalan koneksi HTTPS. Kinerja server web (NPN / ALPN / sesi dilanjutkan), dll. indeks materi tidak mempertimbangkan, bukan untuk itu diciptakan.



Yang kedua adalah bahwa NIST.SP.800 dan standar industri lainnya dipandu oleh kurva elips NIST, di mana ada sedikit lebih banyak daripada tidak ada kepercayaan, tetapi ada pertanyaan dari sudut pandang ECDLP / ECC (komentar menarik tentang topi foil dapat ditinggalkan di komentar tanpa kecuali ).



Meskipun siapa tahu, mungkin seiring waktu standar yang berdaulat dengan spiritualitas dan kawat gigi "Belalang" dan "Magma" akan tumbuh dari indeks (tetapi tidak sebelum IETF mengakui mereka sebagai bagian dari paket sandi standar untuk TLS).



Ide utama indeks: pada tahun 2020, hanya TLS 1.2 dan yang lebih tinggi dengan kumpulan cipher suite dan kurva elips yang sesuai dapat dianggap "HTTPS nyata". Sudah waktunya untuk suite penyandian lama, bahkan jika mereka tidak memiliki kerentanan yang diketahui, ke tong sampah sejarah. Argumen tentang perlunya mendukung klien lama berpihak pada orang miskin: Windows XP masih populer, tetapi penggunanya saat ini tidak menjelajahi Internet melalui Internet Explorer 8 dengan Schannel prasejarahnya, tetapi gunakan browser berbasis Chromium / Firefox menggunakan NSS untuk tujuan ini ... Hal yang sama berlaku untuk pengguna Android versi lama - mereka memasang browser alternatif yang tidak bergantung pada pustaka sistem kripto, atau mereka tidak dapat menggunakan sebagian besar situs modern bahkan melalui HTTP (tanpa dukungan untuk CSS3 dan kesepakatan whistle-blowing modern lainnya).



Dari posisi ini diusulkan untuk mengkritisi draf metodologi. Apakah Anda sudah memperhitungkan semuanya? Apakah Anda mengencangkan mur terlalu keras? Apakah Anda tidak salah menafsirkan sesuatu? Di bawah ini adalah daftar kriteria, dan tautannya adalah teks yang lebih detail, dengan catatan dan komentar .



1. Kriteria minimal



1.1. Komunikasi HTTP (HTTPS) terenkripsi didukung menggunakan protokol TLS kriptografi. Sambungan HTTPS dibuat dengan pengenal protokol (skema URI) https melalui TCP port 443.



1.2. Enkripsi koneksi divalidasi oleh sertifikat situs TLS X.509 versi 3 yang valid, tidak ditandatangani sendiri, dan tidak kosong yang dikeluarkan oleh otoritas sertifikasi otoritatif (CA).



2. Kriteria tambahan



2.1. Server tidak rentan terhadap kerentanan yang diketahui dalam implementasi dukungan koneksi aman (BEAST, POODLE, GOLDENDOODLE, dll.)



2.2. Kompresi TLS tidak didukung.



2.3. Hanya negosiasi ulang aman yang dimulai server yang didukung; Negosiasi ulang yang dimulai klien tidak didukung.



3. Kriteria yang direkomendasikan



3.1. Koneksi HTTP secara otomatis (dipaksa) untuk beralih ke HTTPS.



3.2. Kunci publik sertifikat TLS situs memiliki panjang ≥2048 bit. Sertifikat ditandatangani secara digital menggunakan algoritma ≥SHA256 dengan enkripsi RSA atau ECDSA.



3.3. Protokol TLS versi 1.2 didukung.



3.4. SSL dan TLS versi ≤1.1 tidak didukung.



3.5. Cipher suite standar yang didasarkan pada algoritme yang kuat didukung.



3.6. Cipher suite yang lemah, tidak sesuai, dan rentan tidak didukung.



3.7. Mendukung kurva elips yang aman untuk ECDLP / ECC.



3.8. Urutan koordinasi rangkaian sandi telah diatur.



3.9. Parameter yang kuat dari algoritma kesepakatan kunci Diffie-Hellman (DH) digunakan.



3.10. Ekstensi TLS penting didukung.



3.11. Server Name Indication (SNI) didukung.



4. Kriteria tambahan



4.1. Rantai sertifikat TLS lengkap dan non-redundan telah diterbitkan dengan urutan rantai yang benar.



4.2. Sertifikat TLS situs mendukung Transparansi Sertifikat.



4.3. Sertifikat TLS situs mendukung Daftar Pencabutan Sertifikat (CRL) dan Protokol Status Sertifikat Online (OCSP).



4.4. Sertifikat TLS dalam rantai alternatif sesuai dengan Kriteria 1.2, 4.1.



4.5. Kurva elips tidak aman ECDLP / ECC tidak didukung.



4.6. Urutan pencocokan kurva elips diatur.



4.7. Header respons server berisi header HTTP Strict Transport Security dengan direktif includeSubDomains.



5. Kriteria bonus



5.1. Sertifikat TLS situs mendukung OCSP Stapling.



5.2. Sertifikat situs TLS diterbitkan menggunakan prosedur Verifikasi Organisasi (OV) atau Validasi Diperpanjang (EV).



5.3. Mendukung protokol TLS versi 1.3.



5.4. Urutan koordinasi rangkaian cipher yang stabil dari yang lebih tahan hingga yang kurang stabil (dengan parameter yang sebanding) diatur.



5.5. Catatan sumber daya DNS untuk nama domain situs menyertakan catatan CAA (Otorisasi Otorisasi Sertifikasi).



5.6. Catatan sumber daya DNS untuk nama domain situs mencakup data DS dan TLSA (DNSSEC dan DANE didukung).



5.7. Indikasi Nama Server Terenkripsi (ESNI) didukung.



5.8. Header respons server (header respons HTTP) berisi header Content-Security-Policy dengan perintah upgrade-insecure-request.