TLS berjalan di dalam kanal kontrol, bukan di seluruh terowongan

Melihat kata TLS dalam deskripsi VPN dan menyimpulkan bahwa proxy web akan memahami lalu lintasnya adalah jalan pintas yang umum. Di dalam protokol ini para peer bertukar paket mereka sendiri, dan TLS berjalan sebagai bagian dari satu kanal dalam pertukaran itu. Muatan yang dipedulikan pengguna berjalan dalam format pesan yang berbeda, dan itulah sebabnya keduanya tidak pernah cocok dengan sesi HTTPS biasa.

Amplop datang lebih dulu

Setiap paket terowongan dimulai dengan header milik protokol itu sendiri: jenis pesan, pengenal kunci dan, pada transportasi aliran byte, awalan panjang yang menandai di mana paket berakhir. Pembaca yang tidak mengurai amplop itu tidak dapat mengetahui di mana kolom berikutnya dimulai.

outer transport (UDP datagram or TCP stream)
  -> OpenVPN header (opcode, key id, length where needed)
    -> control message (reliability wrapper, TLS exchange)
    -> data message (protected inner packet)

Sketsa itu adalah peta dan bukan tabel byte, karena kolom persisnya bergantung pada jenis pesan, meskipun oktet pertama selalu mengemas opcode dan pengenal kunci bersama-sama. Menebak jenis pesan dari nomor port adalah cara dekoder akhirnya salah menamai apa yang mereka lihat. Urutannya yang penting untuk diagnosis: transportasi, lalu amplop protokol, lalu salah satu dari dua jenis pekerjaan. Baca amplopnya sebelum membentuk pendapat tentang apa yang menyusul. Dekoder yang mulai di tempat yang salah menghasilkan omong kosong yang percaya diri.

Lapisan keandalan milik protokol

Pesan kontrol membutuhkan pengiriman terurut dan terkonfirmasi, dan protokol menyediakannya sendiri dengan konfirmasi dan pengiriman ulang. Konfirmasi dapat datang sebagai pesan tersendiri atau berjalan bersama pesan kontrol lain, yang membuat jejak terlihat tidak teratur bagi siapa pun yang mengharapkan satu pertukaran bersih.

Manfaatnya adalah jabat tangan TLS mendapatkan pembawa yang andal bahkan ketika transportasi luarnya UDP. Biayanya adalah satu datagram mungkin hanya memuat sebagian percakapan itu, sehingga memperlakukannya sebagai rekaman TLS mandiri menghasilkan omong kosong. Penyusunan ulang harus terjadi di lapisan protokol. Itulah sebabnya paket yang ditangkap jarang terlihat seperti langkah jabat tangan yang lengkap.

Mengalihkan transportasi luar ke TCP tidak menghilangkan lapisan ini. Transportasi andal berarti lebih sedikit pengiriman ulang di tingkat protokol, bukan bahwa pembingkaian menghilang atau lalu lintasnya menjadi HTTP.

Paket data memakai format berbeda

Setelah sesi ada, muatan berguna datang sebagai pesan data yang membawa paket IP dalam atau bingkai Ethernet. Mereka dilindungi dengan kunci dan pemrosesan mereka sendiri, dan mereka bukan rekaman aplikasi TLS dalam pengertian apa pun yang akan diterima pustaka TLS.

Pemisahan itu terlihat dalam konfigurasi: kanal kontrol dan kanal data memiliki pengaturan sandi yang terpisah, sehingga baris log yang menyebut satu tidak memberi tahu apa pun tentang yang lain. Membaca sandi kontrol yang kuat sebagai bukti sandi data yang kuat adalah kesalahan pelaporan yang umum.

Jauhkan juga kesalahpahaman terkait dari penjelasan. TLS bukan kanal kunci publik yang duduk di samping kanal data simetris, karena TLS sendiri melindungi rekamannya secara simetris setelah kunci terbentuk. Perbedaan sebenarnya adalah peran dan format paket, bukan jenis kriptografi yang dipakai masing-masing pihak.

Mengapa proxy HTTPS tidak dapat membantu

Proxy yang mengakhiri TLS mengharapkan aliran rekaman TLS lalu protokol aplikasi di dalamnya. Kanal kontrol protokol ini dibawa di dalam pembingkaiannya sendiri dengan lapisan keandalan di sekitarnya, sehingga proxy yang mengakhiri membaca pembingkaian itu sebagai masukan rusak.

Penerus transparan yang melewatkan byte atau datagram tanpa menafsirkannya dapat bekerja, asalkan tidak menulis ulang atau menyusun ulang alirannya. Pertanyaan yang harus diajukan tentang perantara mana pun adalah apakah ia meneruskan transportasi dan pembingkaian yang sebenarnya, bukan apakah ia mendukung TLS di suatu tempat. Tanyakan itu sebelum menghabiskan satu malam untuk aturan proxy. Sebagian besar kegagalan di sini bersifat arsitektural, bukan pengaturan yang hilang.

Membaca jejak dengan benar

Perkirakan pertukaran kontrol lebih dulu, lalu jumlah pesan data yang jauh lebih besar, keduanya berbagi satu transportasi. Jika fase kontrol selesai dan fase data macet, kesalahannya menyangkut kunci, perutean, atau penyaringan jalur data, bukan jabat tangan. Tangkap beberapa pesan data dan periksa apakah mereka benar-benar meninggalkan klien. Pengamatan tunggal itu membelah pencarian menjadi dua.

Deskripsi historis metode kunci dalam dokumentasi protokol tidak menyiratkan bahwa rilis tertentu masih mendukung setiap format lama. Periksa versi yang Anda jalankan sebelum membangun harapan pada paragraf yang menjelaskan bagaimana dulu semuanya bekerja.