Apache: Validasi rantai kepercayaan SSL untuk mencegah serangan MITM?

11

Saya baru menyadari bahwa serangan SSL man-in-the-middle jauh lebih umum daripada yang saya kira, terutama di lingkungan perusahaan. Saya telah mendengar dan melihat sendiri beberapa perusahaan yang memiliki server proxy SSL transparan. Semua klien dikonfigurasikan untuk mempercayai sertifikat proksi ini. Ini pada dasarnya berarti bahwa majikan secara teoritis dapat mencegat lalu lintas terenkripsi bahkan SSL tanpa peringatan di browser muncul. Seperti disebutkan di atas, klien datang dengan sertifikat yang dipercaya. Ini hanya dapat diungkapkan dengan memvalidasi sertifikat yang sedang digunakan secara manual.

Bagi saya, tampaknya majikan memanfaatkan posisi atasannya untuk memata-matai lalu lintas SSL karyawan. Bagi saya, ini membuat seluruh konsep SSL tidak dapat dipercaya. Saya sendiri telah berhasil menguji pengaturan serupa menggunakan mitmproxy dan dapat membaca komunikasi antara klien dan server perbankan elektronik saya. Ini adalah informasi yang tidak boleh diungkapkan kepada siapa pun.

Jadi, pertanyaan saya agak sederhana: Bagaimana saya bisa memvalidasi rantai kepercayaan di sisi server? Saya ingin memastikan klien menggunakan sertifikat server saya dan hanya satu rantai kepercayaan. Saya ingin tahu apakah ini dapat dicapai dengan konfigurasi SSL Apache? Ini akan nyaman karena dapat diterapkan ke banyak aplikasi dengan mudah. Jika ini tidak memungkinkan, apakah ada yang tahu cara untuk melakukan ini di PHP? Atau Anda punya saran lain?

— Aileron79
sumber

1

Tidak masalah jika majikan melihat lalu lintas karyawan. Anda menggunakan sumber daya perusahaan (komputer, koneksi jaringan, dll.), Ini bukan milik Anda. Dan jika Anda khawatir bahwa emplyer dapat melihat data yang Anda kirimkan ke rekening perbankan Anda - lakukan di rumah, bukan di tempat kerja. Dan upaya untuk melanggar kebijakan keamanan perusahaan dapat menjadi subjek pengadilan terhadap Anda.

— Crypt32

2

Di banyak perusahaan Eropa penggunaan peralatan kantor pribadi diatur dalam kontrak kerja. Di perusahaan tempat saya bekerja saya mungkin berselancar secara pribadi, itu bukan masalah. Ada pengecualian seperti porno, berbagi file dll. Pada saat yang sama ada undang-undang yang melarang perusahaan memata-matai karyawan mereka. Jadi, bagi saya - dan banyak lainnya - TIDAK BAIK ketika majikan mencegat lalu lintas karyawan karena hal ini jelas dilarang sementara berselancar pribadi ditoleransi di banyak perusahaan.

— Aileron79

2

Sebagian besar (menurut pengalaman saya) stasiun kerja milik Pemerintah AS mencakup dua pemberitahuan ini pada setiap login: "Komunikasi yang menggunakan, atau data yang disimpan pada, IS ini bukan pribadi, tunduk pada pemantauan rutin, intersepsi, dan pencarian, dan dapat diungkapkan atau digunakan untuk tujuan resmi USG apa pun. IS ini mencakup tindakan pengamanan (mis. otentikasi dan kontrol akses) untuk melindungi kepentingan USG - bukan untuk keuntungan pribadi atau privasi Anda. " Penggunaan sistem ini sering dicakup oleh perjanjian yang ditandatangani yang menetapkan hal yang sama. Detail kuncinya adalah pemilik sistem melindungi diri terhadap Anda.

— Randall

Itulah salah satu dari banyak perbedaan antara AS dan Eropa. Istilah @Rallall yang dikutip di atas adalah ilegal di sebagian besar negara Eropa.

— Aileron79

Istilah yang saya kutip tidak lengkap, istilah lain daftar kegiatan yang secara eksplisit tidak dapat dimonitor. Saya tidak dapat menemukan referensi yang menyatakan bahwa pengusaha Eropa tidak dapat membuat prasyarat seperti itu sebagai syarat untuk menggunakan komputer mereka (saya bekerja untuk perusahaan yang beroperasi di Eropa, menyiapkan proses pemantauan seperti itu, walaupun saya bekerja untuk sebuah divisi yang tidak melakukan bisnis di Eropa), tetapi dapat menemukan referensi yang menyarankan istilah tersebut tidak ilegal selama mereka eksplisit dan transparan.

— Randall

9

Saya pikir pertanyaan ini akan lebih sesuai untuk security.stackexchange.com mana topik MITM dibahas dalam banyak pertanyaan. Tapi bagaimanapun juga:

Validasi sertifikat server hanya dilakukan pada klien dan tidak dapat dipindahkan ke server karena titik validasi sertifikat pada klien adalah, bahwa klien perlu memastikan bahwa itu berbicara ke server yang benar dan tidak dapat mempercayai Server (tidak dipercaya) untuk membuat keputusan ini untuk klien.

Dalam hal intersepsi SSL, klien TLS dari perspektif server adalah firewall intersepsi SSL / AV. Dengan demikian masalah di sisi server adalah mendeteksi apakah ia berbicara dengan klien yang diharapkan (browser) atau tidak (firewall / AV). Cara teraman untuk melakukan ini adalah dengan menggunakan sertifikat klien untuk mengotentikasi klien - dan pada kenyataannya intersepsi SSL tidak akan berfungsi jika otentikasi klien digunakan, yaitu jabat tangan TLS akan gagal karena MITM tidak dapat memberikan sertifikat klien yang diharapkan.

Hanya saja, sertifikat klien jarang digunakan. Selain itu, jabat tangan TLS yang gagal tidak berarti bahwa klien dapat berkomunikasi ke server tanpa intersepsi SSL tetapi klien tidak dapat berkomunikasi dengan server sama sekali. Cara alternatif adalah dengan menggunakan beberapa heuristik untuk mendeteksi jenis klien TLS berdasarkan sidik jari dari jabat tangan TLS, yaitu jenis dan urutan cipher, penggunaan ekstensi spesifik ... Sementara proxy intersepsi SSL secara teori dapat meniru yang asli ClientHello sangat tidak. Lihat juga Deteksi man-in-the-middle di sisi server untuk HTTPS atau bagian III Heuristik Implementasi TLS dalam Dampak Keamanan dari Interception HTTPS .

— Steffen Ullrich
sumber

14

Bagi saya, tampaknya majikan memanfaatkan posisi atasannya untuk memata-matai lalu lintas SSL karyawan. Bagi saya, ini membuat seluruh konsep SSL tidak dapat dipercaya

Masalahnya bukan dalam konsep SSL atau dalam implementasi teknis, melainkan bahwa orang lain memiliki kontrol penuh atas satu titik akhir koneksi, yaitu workstation Anda.
Itu adalah akar dari risiko keamanan aktual ...

Dari perspektif keamanan, workstation Anda yang dikompromikan yang memutuskan rantai kepercayaan bahwa dalam keadaan normal mencegah MITM untuk berhasil.

Bagaimana saya bisa memvalidasi rantai kepercayaan di sisi server?

Kamu tidak bisa Itu dilakukan sisi klien.

Tergantung pada kasus penggunaan Anda, apa yang dapat Anda lakukan adalah RFC 7469 HTTP Public Key Pinning di mana Anda mengirim header tambahan ke klien dengan daftar (hashes) sertifikat SSL aktual Anda atau CA yang Anda gunakan.

— HBruijn
sumber

4

HPKP tidak akan membantu karena akan diabaikan oleh browser jika sertifikat ditandatangani oleh CA yang ditambahkan secara eksplisit. Ini secara khusus dilakukan untuk memungkinkan intersepsi SSL oleh pihak tepercaya, yaitu firewall perusahaan atau AV desktop lokal (banyak yang melakukan intersepsi SSL).

— Steffen Ullrich

2

Anda benar di sana: §2.6 dari RFC: "Dapat diterima untuk memungkinkan Validasi Pin dinonaktifkan untuk beberapa Host sesuai dengan kebijakan lokal. Misalnya, UA dapat menonaktifkan Validasi Pin untuk Host yang Dipinang yang rantai sertifikatnya divalidasi berakhir pada jangkar kepercayaan yang ditentukan pengguna, dan bukan jangkar kepercayaan yang terpasang di UA (atau platform yang mendasarinya). "

— HBruijn

3

Itu cara yang salah. Bukan server yang memeriksa rantai kepercayaan. Itu adalah Klien. Jadi alasan mengapa perusahaan menggunakan cara ini adalah untuk mengamankan perusahaan dan memeriksa apa yang dilakukan karyawan dalam waktu kerjanya.

— beli3ver
sumber

Ya, saya sadar bahwa ini mungkin tidak dapat dicegah di sisi server saja. Namun, beberapa JS sisi klien mungkin juga diakali. BTW, Memata-matai karyawan adalah ilegal di sebagian besar negara Eropa. Sebagai operator situs web saya ingin mencegah klien saya tertipu, jadi saya bertanya-tanya apakah ada cara saya dapat memvalidasi rantai kepercayaan dengan cara yang aman.

— Aileron79

Mungkin itu tidak diizinkan. Tetapi sebagian besar perusahaan tidak memata-matai karyawan, yang hanya ingin mengamankan jaringan perusahaan di sana, dan sebagian besar webfilters atau pemindai harus memutus koneksi SSL untuk memeriksanya. Jadi ini adalah orang legal dalam serangan tengah

— beli3ver

Saya mengerti maksud Anda. Namun, pertanyaan ini adalah tentang bagaimana saya dapat memastikan koneksi HTTPS terenkripsi dari ujung ke ujung. Pengaturan yang saya jelaskan di atas sangat umum di lingkungan perusahaan, tetapi jenis serangan yang sama mungkin digunakan oleh anak laki-laki yang cemburu untuk memata-matai pacar mereka atau oleh tuan tanah yang mencegat lalu lintas penyewa mereka. Orang-orang ini masih perlu diperdaya untuk memasang sertifikat, tetapi itu bagian yang mudah. Namun, ini ilegal - dan saya masih bertanya-tanya apakah ada cara saya dapat memastikan koneksi HTTPS benar-benar terenkripsi e2e.

— Aileron79

3

Itu tidak mungkin. Ketika sertifikat root telah diubah pada klien, Anda tidak memiliki cara untuk memeriksanya. Server tidak melakukan pemeriksaan, klien melakukan pemeriksaan.

— beli3ver

3

Anda BISA (agak), tetapi pertanyaan sebenarnya adalah apakah Anda HARUS .

Namun berhati-hatilah, ini tidak sesederhana mengubah bendera di apache.conf.

Juga, karena "penyerang" (mis. Majikan) mengendalikan komputer klien, mereka selalu dapat menggagalkan usaha Anda jika mereka cenderung untuk menginvestasikan usaha yang cukup (di sisi baiknya, kecuali jika Anda adalah ikan yang sangat besar, mereka kemungkinan besar tidak cenderung, sehingga Anda akan mencapai tujuan Anda bahwa pengguna Anda tidak akan dapat terhubung dengan Anda kecuali itu aman))

Anda dapat menerapkan kembali TLS dalam javascript , dan melakukan pengecekan di sana jika sertifikat yang terhubung klien adalah sertifikat situs web Anda.
jika Anda beruntung , pengguna mungkin menggunakan peramban tempat Javascript sisi-klien bisa mendapatkan info tentang sertifikat jarak jauh yang digunakan (dan karenanya dengan mudah memverifikasinya terhadap nilai hardcod dari sertifikat server Anda).
Anda dapat menggunakan JavaScript untuk menjalankan enkripsi khusus Anda . Jadi, bahkan ketika perusahaan jahat TLS MiTM berhasil, itu masih tidak akan memberikannya akses ke data Anda. Tentu saja, jika ada yang cukup tertarik (dan karena mereka mengendalikan klien), mereka bisa langsung mengganti javascript aman Anda dengan javascript mereka sendiri yang juga mencatat (atau mengubah) semua informasi dalam perjalanan.

Juga, karena bisnis yang menggunakan proxy TLS MiTM juga biasanya mengendalikan komputer klien sepenuhnya, mereka dapat dengan mudah menginstal layar dan keylogger untuk hanya merekam video dari semua yang dilihat pengguna, dan merekam semua penekanan tombol (dan gerakan mouse) yang diketikkan oleh pengguna. Seperti yang Anda lihat, ketika penyerang adalah klien, tidak ada cara yang benar-benar aman untuk membodohinya. Ini benar-benar hanya sebuah pertanyaan berapa banyak mereka akan repot-repot ... Dan beberapa solusi di atas mungkin cukup baik untuk Anda.

— Matija Nalis
sumber

" Anda bisa menerapkan kembali TLS dalam javascript " Bagaimana? Dimana?

— curiousguy

@curiousguy bahwa teks qouted adalah tautan - klik di atasnya, dan itu akan mengarahkan Anda ke pertanyaan dan jawaban lain, dan akhirnya ke proyek digitalbazaar / Forge

— Matija Nalis

Jadi, kapan itu bisa digunakan? Untuk tujuan apa?

— curiousguy

@curiousguy antara banyak hal lain, terutama untuk keperluan yang ditanyakan dalam pertanyaan Serverfault ini. Ketika Anda memiliki JS TLS Anda sendiri yang berjalan di klien, klien JS itu akan tahu persis ke server TLS mana klien telah terhubung (dan itu kunci publik). Kemudian Anda dapat membandingkan kunci publik tersebut dengan kunci publik server yang berwenang (juga di-hardcode dalam JS Anda), dan jika Anda akan tahu apakah itu sama. Jika tidak sama, koneksi Anda telah dibajak oleh MiTM.

— Matija Nalis