Kelemahan HTTPS. Bagian 2

Setiap sistem memiliki kekuatan dan kelemahannya sendiri. Bagian pertama tentang kelemahan HTTPS memicu reaksi ambigu bahwa "ini bukan kelemahan, itu dimaksudkan untuk menjadi begitu". Bagian pertama mengatakan:

1. Tentang ketidakmungkinan memberikan kerahasiaan dan privasi lengkap kepada pengguna (Anda masih dapat melacak dan melarang sumber daya yang dikunjungi seseorang)
2. Fakta bahwa sertifikat ditransmisikan melalui saluran terbuka dan sering mengandung lebih banyak informasi daripada sumber daya saat ini (misalnya, sertifikat bing.com berisi informasi tentang 72 sumber daya tambahan, termasuk virgo, tes, lingkungan beta)

Saya akan terus menyebutnya desain "kelemahan." Pada artikel ini, kita akan berbicara tentang kelemahan lain - sentralisasi .

HTTPS didasarkan pada protokol SSL dan TLS (untuk kesederhanaan kami hanya akan memanggil SSL - meskipun SSL dan TLS bekerja di berbagai tingkat tumpukan OSI). Oleh karena itu, berbicara tentang kelemahan, kami akan mempertimbangkan sentralisasi protokol SSL.

Teori

Mulailah dengan teori protokol enkripsi. Masalah dengan kriptografi modern bukanlah enkripsi itu sendiri, tetapi apa yang harus dilakukan dengan kunci: cara menyimpan, mentransfer, membuat dan menghancurkannya dengan aman.

Dasar SSL adalah enkripsi asimetris , yang ditentukan oleh kehadiran dua kunci - jika seseorang dienkripsi, maka hanya yang kedua yang dapat mendekripsi, dan sebaliknya.

Fungsi utama dari enkripsi asimetris adalah otentikasi , bukan enkripsi sama sekali - ini adalah operasi yang membutuhkan banyak sumber daya dan mahal untuk algoritma ini. Enkripsi cepat dan efisien adalah hak prerogatif algoritma simetris yang menggunakan kunci yang sama untuk enkripsi dan dekripsi.

Salah satu kunci selalu tetap di satu sisi untuk mengkonfirmasi identifikasi, itu disebut pribadi . Kunci publik tersedia untuk semua orang.

Bayangkan ada desa masa depan di mana Boris dan Anya tinggal. Di masa depan, kunci dari ukuran yang berbeda sudah lebih ketat, dan kemampuan otak tidak proporsional dengan yang modern, tetapi pendekatannya, anggaplah, tetap sama.

Boris dan Anya menginginkan privasi korespondensi cinta mereka, jadi hal utama bagi mereka adalah pertukaran informasi yang aman.

Dalam kasus yang paling sederhana, Boris mengirimi Anna pesan: "ayo bicara." Anya menghasilkan dua pasang kunci enkripsi asimetris - Pr1 pribadi dan P1 publik. "Ayo," kata Anya, "Saya Anya, ini kunci publik saya, inilah algoritma enkripsi simetris yang saya tahu." Boris menghasilkan kunci simetris S1, mengenkripsinya dengan kunci publik Ani P1 (S1). Sekarang bahkan Boris sendiri tidak akan dapat mendekripsi S1, karena hanya Anya yang dapat mendekripsi pesan dengan kunci pribadinya. Pada akhirnya, Boris dan Ani memiliki kunci sesi simetris untuk "memastikan" pengiriman surat yang dapat diandalkan satu sama lain dan mencegah orang tua membaca korespondensi mereka.



Saya secara khusus tidak sangat mengurangi pengiriman pesan ini, bahkan kami menggambarkan Handshake SSL dengan otentikasi satu arah [1]. Dengan basis dua arah, Boris menghasilkan pasangan kunci sendiri dan mentransfer kunci publik ke Anya.

Kesimpulan penting yang sudah bisa kita buat. Dari tiga fungsi utama protokol SSL (otentikasi, enkripsi, integritas), yang paling penting adalah otentikasi.

Semuanya baik-baik saja sampai tukang pos muncul, tersinggung oleh kehidupan, yang rakus untuk membaca surat orang lain, dan selain itu juga pintar. Antara Boris dan Anya, muncul pertanyaan tentang bagaimana menjamin sekarang bahwa tukang pos tidak akan dapat membaca pesan mereka. Jawabannya tidak mungkin. Tukang pos dapat menghasilkan pasangan kunci sendiri, mengekspos Boris kuncinya “diduga” dari Ani, mengatur dua saluran terenkripsi dan membaca surat dengan tenang.



Dilema ini hanya dapat diselesaikan dengan kehadiran pihak ketiga tertentu yang dapat menjamin bahwa kunci P1 milik Ana. Bayangkan sebuah dewan desa muncul di desa, yang menyimpan daftar kunci publik untuk penduduk. Anya dapat mengambil paspornya, kunci publik P1-nya, pergi ke sana dan meminta untuk mendaftar. Boris, ketika dia menerima P1 dari Ani, dia bisa pergi ke dewan desa yang sama dan memeriksa register. Jika kuncinya tidak cocok, Anda dapat mulai berbuat dosa pada tukang pos dan menyalahkannya untuk semua serius, meskipun ia dapat pergi ke penolakan. Namun masalahnya masih diselesaikan.



Bukan camilpho, tentu saja, Boris menyeret ke dewan desa setiap waktu. Karena itu, otentikasi yang sama dapat dilakukan dengan dewan desa itu sendiri. Dewan Desa sekarang menyebut dirinya Otoritas Sertifikasi (CA) dan memiliki pasangan kunci sendiri, P10 dan Pr10. Ketika Anya tiba dengan paspor dan kunci publiknya, CA mengeluarkan sesuatu seperti kartu yang menyatakan bahwa ini adalah Anya, ia memiliki kunci publik P1, beberapa informasi lain, hingga nomor paspor, dan menambahkan bidang lain untuknya tanda tangan: mengambil semua informasi dari kartu, menghapus hash dari itu, dan mengenkripsi dengan kunci pribadi, dan menyebutnya tanda tangan digital. Mungkin saja bisa dilakukan tanpa hash, tapi tanda tangannya terlalu besar. Dan CA sekarang menyebut kartu ini sertifikat.

Sekarang, untuk bertukar pesan cinta dengan Anya, Anya memberinya bukan hanya nama dan kunci publiknya, tetapi juga sertifikatnya. Boris hanya perlu pergi ke dewan desa sekali dan meminta kunci publik mereka. Setiap informasi yang dapat didekripsi oleh kunci ini akan menjadi informasi yang dianggap dienkripsi oleh dewan desa. Tukang pos tidak tahu apa yang harus dilakukan sama sekali, ia dilindungi oleh kekosongan eksistensial, ia hanya memiliki satu hal yang tersisa - untuk mencoba mengambil kunci pribadi dewan desa sehingga kehidupan kembali ke titik awal.



Tetapi hidup tidak berhenti. Boris punya pacar lain di desa tetangga, lalu yang lain. Dia harus menambahkan kunci dewan desa lainnya ke yang dipercaya, mulai menyimpan catatannya dengan kunci publik otoritas sertifikasi. Kemudian ia memperoleh skala nasional dan supranasional. Ada begitu banyak organisasi yang menandatangani sertifikat sehingga mereka mulai bergabung ke dalam hierarki. Root Certification Authority muncul, yang tidak menandatangani sertifikat manusia biasa, tetapi menandatangani sertifikat pusat perantara (Otoritas Sertifikasi Menengah) setelah memeriksa mereka. Sudah cukup bagi Boris untuk hanya menyimpan kunci publik dari sertifikat root. Dan dari Ani ia menerima tidak hanya satu dari sertifikatnya, tetapi juga sertifikat dari pusat perantara, untuk selanjutnya memeriksanya ke pusat akar.

Bidang masalah

Sistem menjadi lebih kompleks dan tersentralisasi , dan sejak saat itu tukang pos kembali memiliki peluang.

Di satu sisi, Boris awalnya memiliki daftar kecil otoritas sertifikasi root (Windows menentukan sekitar 50 otoritas sertifikasi root selama instalasi). Di sisi lain, sulit baginya untuk mengikuti setiap kali seluruh rantai pusat sertifikasi. Kemungkinan besar, dia tidak akan lagi memverifikasi bahwa sertifikat Ani dari desanya sendiri karena alasan tertentu menunjukkan pusat sertifikasi negara lain. Ia memercayai daftar pusat-pusat akar di 99,9 persen. Seorang tukang pos dapat mengambil jalan yang paling brutal, dan entah bagaimana (rekayasa sosial, peretasan dengan penetrasi) mendaftarkan otoritas sertifikasi akar palsu di registri Boris.



PS. Metode menambahkan sertifikat pusat root palsu ini secara aktif digunakan oleh pentester (seperti saya) dan penyerang. Untuk melakukan pengujian penetrasi dan menggunakan pendekatan ini, alat favorit saya adalah ZapProxy (gratis dan open source), yang akan menghasilkan sertifikat pusat root (perlu diinstal secara manual), dan kemudian dengan cepat mengganti sertifikat ini dengan yang "mirip". Ini memungkinkan Anda untuk tidak hanya melihat lalu lintas, tetapi juga menghentikannya, mengubahnya, dan mengirimkannya lebih lanjut. Karena itu, jika validasi pada sistem Anda tidak diduplikasi di server, maka Anda pasti memiliki masalah.

PPS Masalah kedua yang diangkat dalam kasus ini menyangkut Ani dan indikasi pusat yang tidak dapat dipahami dalam sertifikatnya. Anya membayar uang itu, dan tetap ingin Boris mengenalinya. Masalah ini diselesaikan dengan menggunakan Pinning SSL [3], ketika aplikasi hanya dapat dipercaya dalam sertifikat tertentu dan otoritas sertifikasi tertentu. Ini sangat berguna untuk aplikasi berisiko tinggi. Dengan browser, ini lebih rumit, untuk aplikasi seluler yang bekerja dengan satu atau dua layanan, lebih mudah. Demi percobaan, saya meletakkan sertifikat palsu di Android saya, menunjukkan bahwa lalu lintas harus melalui ZapProxy, yang menonjol di jaringan pada mesin saya, dan melihat berapa banyak aplikasi yang menggunakan mekanisme ini. Hampir tidak ada, saya bisa menonton dan bermain dengan substitusi lalu lintas dengan hampir semua aplikasi populer.

Jadi, kembali ke tukang pos kita. Pemerintah tidak bisa tidak menghargai semangatnya dan memberinya status agen rahasia dengan kekuatan yang lebih tinggi. Meskipun kunci pribadi dari otoritas sertifikasi root disimpan di bawah tujuh kunci, disk yang dapat terbakar sendiri, perlindungan multi-level - bahkan otoritas tukang pos mungkin tidak cukup untuk bernegosiasi dengan mereka untuk memberinya kunci pribadi mereka untuk menghasilkan sertifikat valid palsu dengan cepat (walaupun segala sesuatu mungkin terjadi). Dia menemukan cara yang lebih mudah. Dia pergi ke dewan desanya sendiri, yang berada dalam hierarki pusat sertifikasi di tingkat terendah, dan mendesak atau menyuap dewan desa untuk menandatangani sertifikatnya sebagai sertifikat pusat sertifikasi perantara. Sekarang dia dapat mendengarkan lalu lintas tidak hanya dari Boris, tetapi pada prinsipnya subjek apa pun. Orang yang paling mungkin bahkan tidak akan melihat apa-apa, browser tidak akan mengeluarkan peringatan apa pun.



Ini adalah masalah yang diketahui, dan umat manusia juga berusaha untuk memeranginya. Jika sertifikat palsu seperti itu, pusat perantara dan pusat root yang dikompromikan ditemukan, sertifikat ini harus ditandai sebagai dicabut dan dikompromikan (Sertifikat Dicabut). Ini berarti bahwa selain menyimpan sertifikat root, Boris masih perlu menyinkronkannya dengan daftar online sertifikat yang dicabut - mekanisme ini diimplementasikan melalui CRL (daftar pencabutan sertifikat) dan protokol Online Certificate Status Protocol (OCSP) [4], yang, omong-omong, bekerja sesuai dengan saluran yang tidak dilindungi. Ketika kami mulai aktif bekerja mengendalikan lalu lintas OUTPUT menggunakan Dhound [5], kami melihat permintaan berkala pada port 80. Jika Anda melarang permintaan semacam itu di tingkat firewall, maka beberapa fungsi berhenti berfungsi - misalnya, mengirim email. Masalah dengan sertifikat yang dicabut adalah bahwa sudah ada sejumlah besar dari mereka: pada 2013, ada sekitar 3 juta sertifikat yang dicabut [6], 23.000 dicabut sertifikat Symantec pada tahun 2018 saja [7]. Chrome mematikan fungsi default verifikasi penuh atas sertifikat yang dicabut beberapa tahun yang lalu [8] untuk meningkatkan kecepatan pemuatan halaman. Ternyata jika pembawa surat kami ditemukan, proses pencegahan lebih lanjut akan lama dan tidak selalu berhasil.

Kesimpulan

Sistem SSL modern sebagian tertutup dan terpusat , yang jelas merupakan salah satu kelemahannya. Selama itu terjadi, akan selalu ada godaan bagi "orang-orang kuat di dunia ini" untuk mendapatkan manfaat darinya, tanpa memprioritaskan privasi pribadi. Namun, algoritma enkripsi mereka sendiri akan dibuat di tingkat nasional, dalam upaya untuk mengisolasi negara lain dari warga negara mereka sendiri, dan melakukannya sendiri. Kompromi node kunci dapat menurunkan seluruh sistem secara keseluruhan. Meningkatnya entropi dan kompleksitas sistem akan semakin mengarah pada keadaan tidak stabil dan, pada akhirnya, kematian sistem.

Jalan keluar yang mana? Transisi dari sistem SSL yang tertutup dan terpusat ke sistem SSL yang lebih transparan dan terdistribusi, yang pada dasarnya tidak akan mampu memberikan keuntungan kepada salah satu pihak. Mungkin ini akan menjadi solusi yang agak mirip dengan yang mengimplementasikan blockchain terbuka.

PS. Protokol SSL memiliki nuansa yang lebih kompleks yang tidak disebutkan dalam artikel. Tetapi tingkat informasinya cukup untuk mengungkap salah satu kelemahannya. Apakah ada kelemahan lain? Pada artikel berikut kita akan melihat.


Diposting oleh Denis Koloshko, CISSP