SSTP dan SSL 3.0: label versus versi yang dinegosiasikan

Dua orang dapat melihat penerapan SSTP yang sama dan sampai pada kesimpulan yang berlawanan. Yang satu membaca dokumentasi produk, melihat huruf SSL, dan menganggap terowongan menjalankan protokol yang dihentikan bertahun-tahun lalu. Yang lain menunjuk jabat tangan modern dan menyimpulkan pertanyaannya sudah selesai. Keduanya berdebat dari label, bukan dari versi yang dinegosiasikan, dan hanya satu dari keduanya yang merupakan bukti. Perbandingan yang layak dilakukan adalah antara apa yang dijanjikan nama dan apa yang benar-benar dipilih layanan.

Dua jawaban untuk pertanyaan yang sama

Argumen label mudah diutarakan: SSTP dijelaskan sebagai protokol terowongan soket yang aman, nama historisnya menyebut SSL, jadi koneksinya harus SSL 3.0. Argumen ini bertahan karena namanya memang berasal dari garis itu dan karena sebagian besar yang mengulangnya tidak pernah melihat jabat tangan. Argumen ini juga bertahan karena kesimpulannya terdengar hati-hati, seolah menganggap yang terburuk adalah pilihan aman. Menganggap yang terburuk dan mengukur versi sebenarnya adalah dua kegiatan berbeda, dan hanya satu yang mengubah sesuatu.

Argumen bukti mengajukan pertanyaan yang lebih sempit. Versi protokol apa yang disepakati klien ini dan server ini, pada titik akhir ini, pada saat ini? Jawabannya datang dari layanan yang mengakhiri TLS, bukan dari halaman pemasaran atau peramban yang mencapai situs dengan nama serupa.

Kedua argumen berbeda dalam hal apa yang dapat mereka buktikan. Label tidak dapat membedakan penerapan lama dari yang sudah ditambal, dan jabat tangan tidak dapat memberi tahu apa yang dilakukan layanan tak terkait pada host yang sama. Gunakan yang kedua dan berhentilah memakai yang pertama.

Baca versi yang benar-benar dipilih layanan

Mulailah dengan menamai komponennya: implementasi klien, implementasi server, titik akhir TLS, dan semua yang di antaranya yang mengakhiri dan membangun ulang TLS. Penyeimbang beban yang mengakhiri TLS dan berbicara HTTP biasa dengan backend mengubah kebijakan perangkat mana yang harus Anda baca.

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 waktunya di samping hasil, karena perubahan kebijakan di kemudian hari membuat pengamatan tanpa tanggal tidak berguna. Ulangi pemeriksaan dari klien pada jalur jaringan yang sama dengan pengguna yang Anda pedulikan, karena perangkat penyadapan dapat mengakhiri TLS dengan pengaturannya sendiri. Jika kedua posisi tidak cocok, Anda menemukan komponen yang penting. Jika cocok, Anda punya bukti, bukan slogan.

Pisahkan bidang catatan dari negosiasi

Nomor versi yang tampak kuno di satu bidang bukan fakta yang sama dengan sesi SSL 3.0. RFC 7568 memperlakukan versi lapisan catatan dan protokol yang dinegosiasikan sebagai masalah terpisah, dan justru dari pembedaan itulah muncul jawaban salah yang penuh percaya diri. Baca protokol yang dinegosiasikan, lalu cipher, dan baru kemudian tarik kesimpulan tentang sesi.

Dokumen yang sama tegas soal protokolnya sendiri: SSL 3.0 tidak boleh digunakan, dan negosiasi atau kemunduran ke sana dilarang. Alasannya adalah konstruksi CBC rusak yang dieksploitasi serangan POODLE, dan itu sifat protokol, bukan konfigurasi satu aplikasi.

Karena itu „beban kerja ini mungkin sulit dieksploitasi” bukan argumen untuk membiarkan SSL 3.0 aktif. Persyaratannya adalah menghapus protokol, bukan memenangkan debat tentang satu demonstrasi.

Hentikan SSL 3.0 dengan kebijakan yang bisa Anda pertahankan

Di Windows, pengaturan protokol Schannel berada di bawah kunci Protocols dan dibaca terpisah untuk peran klien dan server, sehingga perubahan yang memperbaiki satu arah dapat membiarkan arah lain tak tersentuh. Pengaturan saat ini dan persyaratan mulainya ulang didokumentasikan oleh Microsoft, dan pustaka TLS pihak ketiga pada host 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 kebijakan melalui jalur administrasi yang didukung, pastikan layanan pemilik mengambil konfigurasinya lagi, dan pertahankan cara kembali yang disetujui. Menempelkan skrip registri yang luas dari lingkungan lain adalah cara perbaikan satu layanan menjadi gangguan bagi setiap klien TLS di mesin. Cakupan mulai ulang penting di sini: pengaturan yang tampak diterapkan bisa masih tersimpan di memori layanan yang belum memuatnya ulang.

Rekan yang masih menuntut versi usang memerlukan pembaruan atau rencana migrasi. Pengecualian tak terdokumentasi yang diam-diam memulihkan protokol lama bukan strategi kompatibilitas dan tidak akan bertahan pada audit berikutnya.

Terima perubahan dengan koneksi baru

Uji dengan sesi baru setelah perubahan kebijakan, karena koneksi yang dibangun sebelum perubahan tidak membuktikan apa pun tentang konfigurasi yang berlaku sekarang. Pastikan protokol yang diizinkan berhasil dan yang dilarang gagal melalui proses validasi resmi, lalu biarkan identitas sertifikat dan pemeriksaan kepercayaan persis seperti sebelumnya.

Ingat apa yang tidak dicakup jabat tangan. SSTP membawa autentikasi PPP setelah lapisan TLS, jadi versi protokol modern tidak mengatakan apa pun tentang pengguna mana yang diotorisasi atau sumber daya mana yang dapat dijangkau sesi. Itu kontrol terpisah dengan bukti terpisah.

Tuliskan hasilnya sebagai layanan, backend, kebijakan yang diizinkan, dan versi yang diamati. Catatan semacam itu menjawab pertanyaan keamanan dengan tepat, yang tidak pernah dilakukan argumen label maupun argumen ketidaknyamanan.