Bekerja pada protokol TLS 1.3 versi baru hampir selesai. Setelah empat tahun berdiskusi pada Maret 2018, IETF menyetujui
versi konsep ke -
28 sebagai standar yang diusulkan, sehingga harus menjadi yang terakhir sebelum spesifikasi final diadopsi.
TLS 1.3 mempercepat proses membangun koneksi yang aman sekitar setengahnya dengan menggabungkan beberapa langkah pada saat ini. Selain itu, ini mengimplementasikan rezim kerahasiaan langsung sempurna melalui kunci sementara (EC) DH. Mode ini menjamin perlindungan kunci sesi bahkan dalam kasus kompromi kunci jangka panjang.
Sejumlah perbaikan lain telah dilaksanakan, termasuk dukungan untuk cipher aliran ChaCha20, algoritma tanda tangan digital Ed25519 dan Ed448, protokol pertukaran kunci x25519 dan x448, dll. Dukungan untuk fungsi hash MD5 dan SHA-224 yang usang, kurva elips yang lemah dan jarang digunakan telah dihapus
Tetapi yang paling menarik adalah ide baru yang sedang
dibahas di IETF . Pakar Google menyarankan secara berkala membuat versi baru protokol TLS secara acak dengan sedikit perubahan. Idenya adalah bahwa pembaruan yang sering akan menjadi penangkal osifikasi berbahaya.
Masalah apa ini
Yang disebut "osifikasi" adalah situasi ketika pengembang protokol tiba-tiba menyadari bahwa sulit untuk memperkenalkan peningkatan apa pun karena penyebaran luas versi lama, yang karena alasan tertentu cocok untuk pengguna. Pada kenyataannya, versi lama tidak lagi memenuhi persyaratan keamanan modern dan spesifikasi baru, tetapi tidak dapat diimplementasikan secara de facto.
Diyakini bahwa apa yang disebut "intermediate nodes", yaitu vendor solusi di bidang "keamanan", menjadi "rem" utama khususnya dengan penerapan TLS 1.3. Mereka menyarankan pelanggan mereka untuk meresepkan
aturan firewall tertentu dengan pemindaian sertifikat ketika berjabat tangan dengan TLS. Dalam versi standar yang baru,
sertifikat SSL dienkripsi, sehingga perantara tidak lagi dapat memindai mereka.
Bagaimana pembaruan terus-menerus akan memecahkan masalah osifikasi protokol?
Pembaruan berkelanjutan setiap enam minggu adalah pola yang umum dari browser Chrome. Dalam situasi ini, "pemain"
dipaksa untuk mematuhi spesifikasi, karena implementasi yang tidak kompatibel tidak akan berfungsi untuk sebagian besar pengguna.
Pada milis IETF, ide ini
disarankan oleh David Benjamin dari proyek Chromium. Dia menulis bahwa TLS 1.3 adalah protokol yang dapat dikembangkan yang kompatibel dengan TLS 1.2. Ini dapat diluncurkan secara bertahap, memperbarui implementasi TLS 1.2 saat ini. Dan di sini ada masalah. Banyak server yang tidak kompatibel tidak akan dapat membangun komunikasi pada tahap TLS 1.3 ClientHello, jadi Anda harus memutar kembali untuk membangun komunikasi menggunakan versi protokol yang didukung.
David Benjamin mengedepankan ide bagaimana menghindari masalah ini di masa depan. Membahas langkah-langkah pencegahan, ia menyebutkan
invarian protokol yang tercantum dalam pasal 9.3 dari spesifikasi. Semua titik akhir dan titik tengah
harus mematuhi invarian yang dijelaskan. Secara khusus, klien baru dan server baru tidak memiliki hak untuk mengurangi tingkat parameter ke versi lama. Dengan cara yang sama, node perantara tidak memiliki hak untuk melakukan ini ketika mentransfer koneksi antara klien yang diperbarui dan server dan tidak dapat mempengaruhi jabat tangan. Namun, mengingat kecepatan pembaruan yang tidak merata, klien dan server yang diperbarui dapat mendukung pembentukan komunikasi menggunakan protokol lama, tetapi hanya dengan cara yang benar yang dijelaskan dalam ayat 9.3.
Tetapi praktik menunjukkan bahwa tidak cukup untuk menggambarkan perilaku yang diperlukan dalam spesifikasi. Bagaimana cara
memaksa simpul perantara untuk memenuhi aturan kunci pemrosesan ClientHello - untuk mengabaikan parameter yang tidak dikenal? Untuk ini, metode
GREASE diusulkan.
GREASE: penangkal terhadap pengerasan
GREASE (Menghasilkan Ekstensi Acak Dan Mempertahankan Extensibility) adalah metode menghasilkan ekstensi
acak ke TLS dan rilis konstan versi baru dari protokol. David Benjamin mengusulkan untuk membangun siklus rilis enam minggu standar, yang akan bertepatan dengan rilis versi baru Chrome.
Pelepasan "sampah" seperti itu dalam jumlah besar akan memaksa server untuk mematuhi aturan utama pemrosesan ClientHello untuk mengabaikan parameter yang tidak dikenal. Ini juga akan menyebar ke node perantara. Agar mereka tidak ikut campur dalam komunikasi antara klien dan server, aturan utama untuk mereka adalah ini: jika Anda tidak mengirim permintaan ClientHello, maka Anda tidak memiliki hak untuk memproses respons. Demikian pula, ekosistem harus dibanjiri dengan sejumlah besar tanggapan seperti itu.
"Singkatnya, kami berencana untuk secara teratur mencap versi baru TLS (dan mungkin parameter sensitif lainnya seperti ekstensi)," kata Benjamin, yang tampaknya mengekspresikan sudut pandang Google. - kira-kira setiap enam minggu, sesuai dengan jadwal rilis Chrome. Kemudian Chrome, server Google dan semua orang yang ingin berpartisipasi akan mendukung dua (atau lebih) versi TLS 1.3: standar stabil 0x0304 dan versi alternatif sementara. Setiap enam minggu, kami secara acak memilih titik kode baru. Dalam semua hal lain, versi ini identik dengan 1.3, dengan kemungkinan pengecualian kecil untuk memisahkan kunci dan membuat perubahan sintaksis yang diizinkan. Tujuannya adalah untuk membuka jalan bagi versi TLS masa depan dengan menirunya (konsep negatif). "
Skema semacam itu memiliki risiko tertentu, termasuk tabrakan poin kode. Selain itu, tindakan pencegahan harus dikembangkan, karena tugasnya adalah mempertahankan dan mempertahankan ekstensibilitas TLS, dan tidak mengganggu pengembangan protokol. Dari tindakan pencegahan:
- Dokumentasi terperinci dari semua poin kode (ketika mengerjakan satu poin dalam satu setengah bulan, mereka akan cukup untuk lebih dari 7000 tahun).
- Penghindaran tabrakan proaktif: menolak angka yang dapat dipilih IETF.
- BoringSSL tidak akan mengaktifkan opsi ini secara default. Ini hanya akan diaktifkan jika dapat dinonaktifkan: di server dan di browser. Pada kenyataannya, kemungkinan besar, pada setiap saat, hanya beberapa poin kode terakhir yang akan digunakan. Karena mereka berubah dengan cepat, ekosistem seharusnya tidak melekat pada ekspansi sementara seperti itu, dan implementasi akan tetap kompatibel satu sama lain.
- Jika karena alasan tertentu metode ini tidak berfungsi, percobaan dapat dihentikan kapan saja.
Idenya menarik, dan jika Google mulai bertindak dengan cara ini, itu benar-benar dapat menyelamatkan ekosistem dari "pengerasan" yang berbahaya karena vendor solusi di bidang "keamanan" dan sistem perusahaan khusus lainnya. Perwakilan dari Cloudflare
mendukung proposal ini. Dalam kasus apa pun, katanya, setidaknya sesuatu harus dilakukan untuk menghindari masalah yang kami temui ketika mencoba menerapkan TLS 1.3. Anggota lain dari kelompok kerja IETF
menyebutnya “ide fantastis” dan menyarankan agar Google membuat halaman wiki yang menjelaskan poin kode yang digunakan atau rencananya akan digunakan di masa depan.
