Apakah handshake VPN yang gagal benar-benar serangan downgrade?

Handshake yang berakhir dengan kesalahan terasa seperti serangan sampai Anda melihat pesannya, dan biasanya ini soal aritmetika: tidak ada proposal bersama, sertifikat kedaluwarsa, atau paket yang tidak pernah tiba. Serangan downgrade adalah hal spesifik: penyerang mendorong kedua ujung ke perilaku yang lebih lemah daripada yang akan mereka pilih, dan meninggalkan bukti berbeda. Memperlakukan setiap kegagalan sebagai niat jahat membuat Anda mencari korban yang mungkin tidak ada, sedangkan memperlakukan downgrade sungguhan sebagai bug konfigurasi membiarkan hasil yang lebih lemah tetap ada. Kedua kesalahan itu berbiaya berbeda, dan hanya satu yang murah diperbaiki.

Apa yang sebenarnya diubah serangan downgrade

Tujuannya bukan memecahkan cipher dan bukan menebak kunci. Tujuannya memengaruhi negosiasi agar kedua pihak berhenti pada versi lebih lama atau algoritme lebih lemah yang bisa ditangani penyerang, atau membuat satu pihak percaya pihak lain hanya mendukung itu.

Yang berubah adalah kesepakatan, bukan autentikasi. Jika penyerang bisa mengubah tawaran tanpa terdeteksi, kedua peer masih bisa menyelesaikan handshake dan masih saling mengautentikasi, tetapi dengan parameter yang disukai penyerang. Karena itu pertanyaan menariknya adalah apakah negosiasi itu sendiri tercakup perlindungan integritas.

Mengapa negosiasi itu sendiri harus diautentikasi

TLS 1.3 membuat perlindungan itu eksplisit. Klien yang menawarkan versi lebih baru dapat mendeteksi server yang diam-diam mundur, karena nilai acak server membawa pola tetap saat menegosiasikan 1.2 atau lebih rendah, dan klien wajib membatalkan saat melihatnya. Transkrip lengkap juga tercakup pesan akhir, sehingga perubahan di mana pun dalam negosiasi gagal belakangan alih-alih lewat diam-diam.

Versi protokol lama punya cerita lebih lemah, dan itulah sebabnya aturan fallback penting. Endpoint TLS 1.0 dalam konfigurasi yang sama bukan serangan downgrade; itu hasil yang diizinkan yang Anda pilih untuk izinkan. Pembedanya adalah apakah hasil yang lebih lemah datang dari keputusan yang terlindungi atau dari jalur tak terlindungi yang bisa dipengaruhi perantara. Begitu dirumuskan demikian, sebagian besar insiden menjadi pertanyaan konfigurasi.

IKEv2 berperilaku berbeda tetapi bersandar pada gagasan yang sama. Proposal dibawa dalam pertukaran yang nanti mengautentikasi kedua peer, sehingga middlebox yang menulis ulang algoritme merusak autentikasi alih-alih mengarahkannya. Kanal kontrol OpenVPN melindungi negosiasinya dengan TLS lalu memakai kanal itu untuk menyepakati cipher kanal data, karena itu baris log kanal kontrol yang menarik.

Kompatibilitas yang dikonfigurasi bukan serangan

Administrator dapat dengan sengaja mengizinkan pilihan lama untuk mendukung klien yang terdokumentasi, dan keputusan itu terlihat dalam konfigurasi. Penyerang tidak dapat membuat konfigurasi itu; mereka hanya dapat mengeksploitasi jalur yang memungkinkan mereka memengaruhi tawaran.

Perbaikan berbahaya adalah yang menghapus bukti perbedaan. Mengaktifkan setiap opsi warisan, menonaktifkan verifikasi sertifikat, atau menerima cipher apa pun agar kesalahan hilang memperluas apa yang akan disetujui endpoint, dan menghapus pemeriksaan yang seharusnya melaporkan hasil yang lebih lemah.

Jika harus menyimpan satu opsi lama, sebutkan alasan dan klien di komentar konfigurasi, lalu batasi opsi itu pada profil yang membutuhkannya. Pengecualian kompatibilitas yang dibatasi pada satu listener dapat diaudit; yang diterapkan secara global hanyalah default lebih lemah yang tak seorang pun ingat pernah memilihnya.

Baca kegagalan sebelum menamai penyebab

Simpan string kesalahan yang tepat, versi klien dan server, serta waktu sebelum ada perubahan. Lalu klasifikasikan: apakah para pihak tidak sepakat soal proposal, jalur paket gagal, atau satu pihak menolak parameter yang dulu diterimanya?

Ketidakcocokan proposal biasanya menyebut versi atau algoritme yang bermasalah dan gagal di titik yang sama setiap kali. Masalah routing atau MTU terhenti atau timeout, dan sering bervariasi menurut jaringan. Sertifikat kedaluwarsa menghasilkan kesalahan verifikasi, bukan kesalahan negosiasi.

Tidak satu pun dari itu bukti adanya penyerang. Menetapkan penyebab jahat pada kegagalan pertama adalah kesalahannya, karena menyembunyikan bug deterministik yang akan gagal lagi besok.

Konfirmasikan apa yang benar-benar dipilih

Setelah koreksi apa pun, baca hasil yang dinegosiasikan alih-alih percaya bahwa koneksi sudah naik. Koneksi yang berhasil karena verifikasi dihapus adalah hasil yang ingin Anda hindari. Dua perintah berikut menunjukkan versi dan cipher yang dipilih untuk endpoint dengan TLS di depan, plus baris kanal kontrol dari log server OpenVPN.

openssl s_client -connect 198.51.100.30:443 -servername vpn.example.net -brief </dev/null
grep -iE 'Control Channel|Data Channel' /var/log/openvpn.log | tail -5

Bandingkan hasilnya dengan konfigurasi yang Anda maksud, bukan dengan apa yang sekarang terhubung. Jika versi yang dipilih lebih lama dari minimum yang diizinkan, profil atau daftar fallback adalah tempat mencarinya, dan jawabannya adalah memperbaiki daftar itu, bukan menyatakan serangan dan membangun ulang segalanya.