DPI (inspeksi SSL) bertentangan dengan makna kriptografi, tetapi perusahaan menerapkannya


Rantai kepercayaan CC BY-SA 4.0 Yanpa

Inspeksi lalu lintas SSL (dekripsi SSL / TLS, analisis SSL atau DPI) menjadi topik yang semakin panas di sektor korporasi. Gagasan mendekripsi lalu lintas tampaknya bertentangan dengan konsep kriptografi. Namun, fakta adalah fakta: semakin banyak perusahaan menggunakan teknologi DPI, menjelaskan ini dengan kebutuhan untuk memeriksa konten untuk malware, kebocoran data, dll.

Nah, jika Anda menerima kenyataan bahwa perlu untuk menerapkan teknologi seperti itu, maka Anda setidaknya harus mempertimbangkan cara untuk membuatnya menjadi cara yang paling aman dan dikelola dengan baik. Setidaknya tidak bergantung pada sertifikat itu, misalnya, yang diberikan penyedia sistem DPI kepada Anda.

Ada satu aspek implementasi yang tidak semua orang sadari. Bahkan, banyak yang benar-benar terkejut ketika mendengar tentangnya. Ini adalah otoritas sertifikasi swasta (CA). Ini menghasilkan sertifikat untuk mendekripsi dan mengenkripsi ulang lalu lintas.

Alih-alih mengandalkan sertifikat yang ditandatangani sendiri atau sertifikat dari perangkat DPI, Anda dapat menggunakan CA khusus dari otoritas sertifikasi pihak ketiga seperti GlobalSign. Tapi pertama-tama, mari kita lakukan tinjauan singkat terhadap masalah itu sendiri.

Apa itu inspeksi SSL dan mengapa digunakan?


Semakin banyak situs web publik yang beralih ke HTTPS. Misalnya, menurut statistik Chrome , pada awal September 2019, pangsa lalu lintas terenkripsi di Rusia mencapai 83%.



Sayangnya, penjahat dunia maya semakin menggunakan enkripsi lalu lintas, terutama karena Let's Encrypt secara otomatis mendistribusikan ribuan sertifikat SSL gratis. Dengan demikian, HTTPS digunakan di mana-mana - dan kunci di bilah alamat browser tidak lagi berfungsi sebagai indikator keamanan yang andal.

Dari posisi ini, produsen solusi DPI mempromosikan produk mereka. Mereka disebarkan antara pengguna akhir (mis. Karyawan Anda menjelajahi web) dan Internet, menyaring lalu lintas berbahaya. Ada sejumlah produk seperti itu di pasaran saat ini, tetapi proses dasarnya sama. Lalu lintas HTTPS melewati perangkat pemindaian, tempat ia didekripsi dan dipindai untuk mencari malware.

Setelah verifikasi selesai, perangkat membuat sesi SSL baru dengan klien akhir untuk dekripsi dan enkripsi ulang konten.

Cara proses dekripsi / enkripsi ulang bekerja


Agar perangkat inspeksi SSL mendekripsi dan mengenkripsi ulang paket sebelum mengirimnya ke pengguna akhir, ia harus dapat mengeluarkan sertifikat SSL dengan cepat. Ini berarti bahwa sertifikat CA harus diinstal di dalamnya.

Untuk perusahaan (atau orang lain di tengah), penting bahwa sertifikat SSL ini dipercaya di browser (mis. Jangan menyebabkan pesan peringatan yang menakutkan seperti yang di bawah ini). Oleh karena itu, rantai CA (atau hierarki) harus ada di toko trust browser. Karena sertifikat ini tidak dikeluarkan dari otoritas sertifikat yang dipercayai publik, Anda harus mentransfer hierarki CA secara manual ke semua klien akhir.


Pesan peringatan untuk sertifikat yang ditandatangani sendiri di Chrome. Sumber: BadSSL.com

Pada komputer dengan Windows, Anda dapat menggunakan Active Directory dan kebijakan grup, tetapi untuk perangkat seluler, prosedurnya lebih rumit.

Situasinya bahkan lebih rumit jika Anda perlu mendukung sertifikat root lain di lingkungan perusahaan, misalnya, dari Microsoft, atau berdasarkan OpenSSL. Plus, melindungi dan mengelola kunci pribadi sehingga salah satu kunci tidak kedaluwarsa secara tak terduga.

Opsi terbaik: Pribadi, sertifikat root khusus dari CA pihak ketiga


Jika mengelola beberapa root atau sertifikat yang ditandatangani sendiri tidak menarik, maka ada opsi lain: Anda dapat mengandalkan CA pihak ketiga. Dalam hal ini, sertifikat dikeluarkan dari otoritas sertifikasi swasta , yang terhubung dalam rantai kepercayaan dengan otoritas sertifikasi root swasta yang berdedikasi yang dibuat khusus untuk perusahaan.


Arsitektur sederhana untuk sertifikat root klien khusus

Pengaturan ini menghilangkan beberapa masalah yang disebutkan sebelumnya: setidaknya itu mengurangi jumlah root yang perlu dikelola. Di sini Anda hanya dapat menggunakan satu pusat root swasta untuk semua kebutuhan PKI internal dengan sejumlah otoritas sertifikasi perantara. Misalnya, diagram di atas menunjukkan hierarki multi-level di mana salah satu otoritas sertifikasi menengah digunakan untuk memverifikasi / mendekripsi SSL, dan yang lainnya digunakan untuk komputer internal (laptop, server, komputer desktop, dll.).

Dalam skema ini, Anda tidak perlu menempatkan CA pada semua klien, karena CA tingkat atas di-host oleh GlobalSign, yang menyelesaikan masalah dengan melindungi kunci pribadi dan masa berlaku.

Keuntungan lain dari pendekatan ini adalah kemampuan untuk mencabut otoritas sertifikat SSL dengan alasan apa pun. Sebagai gantinya, itu hanya membuat yang baru yang mengikat ke root pribadi asli Anda, dan Anda dapat menggunakannya segera.

Terlepas dari semua kontradiksi, perusahaan semakin memperkenalkan inspeksi lalu lintas SSL sebagai bagian dari infrastruktur internal atau pribadi PKI. Opsi lain untuk menggunakan PKI pribadi adalah menerbitkan sertifikat untuk perangkat atau pengguna yang mengotentikasi, SSL untuk server internal, dan berbagai konfigurasi yang tidak diizinkan dalam sertifikat tepercaya publik sesuai dengan persyaratan CA / Browser Forum.

Browser menolak


Perlu dicatat bahwa pengembang peramban mencoba untuk melawan tren ini dan melindungi pengguna akhir dari MiTM. Misalnya, beberapa hari yang lalu Mozilla memutuskan untuk memasukkan protokol DoH default (DNS-over-HTTPS) di salah satu versi browser berikut di Firefox. Protokol DoH menyembunyikan permintaan DNS dari sistem DPI, membuat inspeksi SSL sulit.

Rencana serupa diumumkan pada 10 September 2019 oleh Google untuk browser Chrome.




KONDISI KHUSUS untuk solusi PKI untuk perusahaan berlaku hingga 30 November 2019 dengan kode promo AL002HRFR untuk pelanggan baru. Untuk detail, hubungi manajer +7 (499) 678 2210, sales-ru@globalsign.com.

Source: https://habr.com/ru/post/id467259/


All Articles