SSTP dan SSL 3.0: label berbanding versi yang dirundingkan

Dua orang boleh melihat penggunaan SSTP yang sama dan sampai kepada kesimpulan yang bertentangan. Seorang membaca dokumentasi produk, melihat huruf SSL dan menganggap terowong menjalankan protokol yang ditarik balik bertahun-tahun lalu. Yang lain menunjuk genggaman tangan moden dan menyimpulkan soalan itu sudah selesai. Kedua-duanya berhujah daripada label dan bukan daripada versi yang dirundingkan, dan hanya satu daripadanya ialah bukti. Perbandingan yang wajar dibuat ialah antara apa yang dijanjikan nama dan apa yang sebenarnya dipilih oleh perkhidmatan.

Dua jawapan kepada soalan yang sama

Hujah label mudah dinyatakan: SSTP diterangkan sebagai protokol terowong soket yang selamat, nama sejarahnya menyebut SSL, jadi sambungan mesti SSL 3.0. Ia bertahan kerana nama itu memang berasal dari keturunan tersebut dan kerana kebanyakan yang mengulanginya tidak pernah melihat genggaman tangan. Ia juga bertahan kerana kesimpulannya kedengaran berhati-hati, seolah-olah menganggap yang terburuk ialah pilihan selamat. Menganggap yang terburuk dan mengukur versi sebenar ialah dua kegiatan berbeza, dan hanya satu daripadanya mengubah sesuatu.

Hujah bukti mengemukakan soalan yang lebih sempit. Versi protokol manakah yang dipersetujui oleh klien ini dan pelayan ini, pada titik akhir ini, pada masa ini? Jawapannya datang daripada perkhidmatan yang menamatkan TLS, bukan daripada halaman pemasaran atau pelayar yang sampai ke tapak dengan nama yang serupa.

Kedua-dua hujah berbeza dari segi apa yang boleh dibuktikan. Label tidak dapat membezakan penggunaan lama daripada yang telah ditampal, dan genggaman tangan tidak dapat memberitahu apa yang dilakukan oleh perkhidmatan tidak berkaitan pada hos yang sama. Gunakan yang kedua dan berhenti menggunakan yang pertama.

Baca versi yang sebenarnya dipilih oleh perkhidmatan

Mulakan dengan menamakan komponen: pelaksanaan klien, pelaksanaan pelayan, titik akhir TLS dan segala-galanya di antaranya yang menamatkan dan membina semula TLS. Pengimbang beban yang menamatkan TLS dan bercakap HTTP biasa dengan bahagian belakang mengubah peranti mana yang perlu anda baca dasarnya.

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null> | grep -E 'Protocol|Cipher'
Get-WinEvent -LogName System -ProviderName Schannel -MaxEvents 20

Catat titik akhir dan masa di sebelah keputusan, kerana perubahan dasar kemudiannya menjadikan pemerhatian tanpa tarikh tidak berguna. Ulangi ujian daripada klien pada laluan rangkaian yang sama dengan pengguna yang anda pedulikan, kerana peranti pemintasan boleh menamatkan TLS dengan tetapannya sendiri. Jika kedua-dua pendirian tidak sepadan, anda telah menemui komponen yang penting. Jika sepadan, anda mempunyai bukti dan bukan slogan.

Pisahkan medan rekod daripada rundingan

Nombor versi yang kelihatan kuno dalam satu medan bukan fakta yang sama dengan sesi SSL 3.0. RFC 7568 menganggap versi lapisan rekod dan protokol yang dirundingkan sebagai perkara berasingan, dan daripada perbezaan itulah datangnya jawapan salah yang yakin. Baca protokol yang dirundingkan, kemudian sifer, dan hanya selepas itu buat kesimpulan tentang sesi.

Dokumen yang sama tidak kabur tentang protokol itu sendiri: SSL 3.0 tidak boleh digunakan, dan rundingan atau kemunduran kepadanya adalah dilarang. Sebabnya ialah binaan CBC rosak yang dieksploitasi oleh serangan POODLE, dan itu sifat protokol, bukan konfigurasi satu aplikasi.

Itulah sebabnya „beban kerja ini mungkin sukar dieksploitasi” bukan hujah untuk membiarkan SSL 3.0 diaktifkan. Keperluannya ialah membuang protokol itu, bukan memenangi perdebatan tentang satu demonstrasi.

Tarik balik SSL 3.0 dengan dasar yang boleh anda pertahankan

Dalam Windows, tetapan protokol Schannel berada di bawah kunci Protocols dan dibaca secara berasingan untuk peranan klien dan pelayan, sebab itulah perubahan yang membaiki satu arah boleh membiarkan arah yang lain tidak tersentuh. Tetapan semasa dan keperluan mula semulanya didokumenkan oleh Microsoft, dan pustaka TLS pihak ketiga pada hos yang sama mengabaikannya sepenuhnya.

Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server'
Get-ChildItem 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols'

Ubah dasar melalui laluan pentadbiran yang disokong, sahkan bahawa perkhidmatan pemilik mendapatkan semula konfigurasinya dan kekalkan cara kembali yang diluluskan. Menampal skrip registri yang luas daripada persekitaran lain ialah cara pembaikan satu perkhidmatan menjadi gangguan kepada setiap klien TLS pada mesin. Skop mula semula penting di sini: tetapan yang kelihatan digunakan mungkin masih dipegang dalam memori oleh perkhidmatan yang belum memuat semulanya.

Rakan yang masih menuntut versi usang memerlukan kemas kini atau pelan migrasi. Pengecualian tidak berdokumen yang senyap memulihkan protokol lama bukan strategi keserasian dan tidak akan bertahan dalam audit seterusnya.

Terima perubahan dengan sambungan baharu

Uji dengan sesi baharu selepas perubahan dasar, kerana sambungan yang dibina sebelum perubahan tidak membuktikan apa-apa tentang konfigurasi yang berkuat kuasa sekarang. Sahkan bahawa protokol yang dibenarkan berjaya dan yang dilarang gagal melalui proses pengesahan yang dibenarkan, kemudian biarkan identiti sijil dan pemeriksaan kepercayaan tetap seperti asalnya.

Ingat apa yang tidak diliputi oleh genggaman tangan. SSTP membawa pengesahan PPP selepas lapisan TLS, jadi versi protokol moden tidak mengatakan apa-apa tentang pengguna mana yang diberi kuasa atau sumber mana yang boleh dicapai oleh sesi. Itu kawalan berasingan dengan bukti berasingan.

Tuliskan hasilnya sebagai perkhidmatan, bahagian belakang, dasar yang dibenarkan dan versi yang diperhatikan. Rekod sedemikian menjawab soalan keselamatan dengan tepat, yang tidak pernah dilakukan oleh hujah label mahupun hujah ketidakselesaan.