SSL dan kesalahpahaman man-in-the-middle

91

Saya telah membaca banyak sekali dokumentasi yang terkait dengan masalah ini tetapi saya masih tidak bisa mendapatkan semua bagiannya, jadi saya ingin mengajukan beberapa pertanyaan.

  1. Pertama-tama saya akan menjelaskan secara singkat prosedur otentikasi seperti yang saya mengerti, karena saya mungkin salah dalam hal itu: Klien memulai koneksi, yang ditanggapi server dengan kombinasi kunci publik, beberapa metadata, dan tanda tangan digital dari sebuah otoritas terpercaya. Kemudian klien mengambil keputusan jika dia mempercayai server, mengenkripsi beberapa kunci sesi acak dengan kunci publik dan mengirimkannya kembali. Kunci sesi ini hanya dapat didekripsi dengan kunci pribadi yang disimpan di server. Server melakukan ini dan kemudian sesi HTTPS dimulai.

  2. Jadi, jika saya benar di atas, pertanyaannya adalah bagaimana serangan man-in-the-middle bisa terjadi dalam skenario seperti itu? Maksud saya, bahkan jika seseorang mencegat respons server (mis. Www.server.com) dengan kunci publik dan memiliki beberapa cara untuk membuat saya berpikir bahwa dia adalah www.server.com, dia tetap tidak dapat mendekripsi kunci sesi saya tanpa kunci pribadi.

  3. Berbicara tentang otentikasi bersama, apakah itu semua tentang kepercayaan server tentang identitas klien? Maksud saya, klien sudah dapat yakin bahwa dia berkomunikasi dengan server yang benar, tetapi sekarang server ingin mengetahui siapa kliennya, bukan?

  4. Dan pertanyaan terakhir adalah tentang alternatif otentikasi timbal balik. Jika saya bertindak sebagai klien dalam situasi yang dijelaskan, bagaimana jika saya mengirim login / kata sandi di header HTTP setelah sesi SSL dibuat? Seperti yang saya lihat, informasi ini tidak dapat dicegat karena koneksi sudah diamankan dan server dapat mengandalkannya untuk identifikasi saya. Apakah aku salah? Apa kelemahan dari pendekatan seperti itu dibandingkan dengan otentikasi bersama (hanya masalah keamanan yang penting, bukan kompleksitas implementasi)?

security  ssl  man-in-the-middle 
— Vadim Chekry
sumber

Jawaban:

106

Serangan man-in-the-middle pada SSL benar-benar hanya mungkin jika salah satu prasyarat SSL dilanggar, berikut beberapa contohnya;

  • Kunci server telah dicuri - berarti penyerang dapat terlihat sebagai server, dan tidak ada cara bagi klien untuk mengetahuinya.

  • Klien mempercayai CA yang tidak dapat dipercaya (atau yang kunci root-nya dicuri) - siapa pun yang memegang kunci CA tepercaya dapat menghasilkan sertifikat yang berpura-pura menjadi server dan klien akan mempercayainya. Dengan jumlah CA yang sudah ada di browser saat ini, ini mungkin menjadi masalah nyata. Ini berarti bahwa sertifikat server akan tampak berubah menjadi yang valid lainnya, yang merupakan sesuatu yang akan disembunyikan oleh sebagian besar klien dari Anda.

  • Klien tidak repot-repot memvalidasi sertifikat dengan benar terhadap daftar CA tepercaya - siapa pun dapat membuat CA. Tanpa validasi, "Mobil dan Sertifikat Ben" akan tampak sama validnya dengan Verisign.

  • Klien telah diserang dan CA palsu telah disuntikkan ke otoritas root tepercaya - memungkinkan penyerang untuk menghasilkan sertifikat apa pun yang dia suka, dan klien akan mempercayainya. Malware cenderung melakukan ini, misalnya mengarahkan Anda ke situs perbankan palsu.

Terutama # 2 agak menjijikkan, meskipun Anda membayar untuk sertifikat yang sangat tepercaya, situs Anda tidak akan dikunci dengan cara apa pun ke sertifikat itu, Anda harus mempercayai semua CA di browser klien karena salah satu dari mereka dapat menghasilkan sertifikat palsu untuk situs Anda yang sama validnya. Itu juga tidak memerlukan akses ke server atau klien.

— Joachim Isaksson
sumber
4
Ada juga alat seperti sslstrip , yang akan mencoba menulis ulang tautan https secara transparan menjadi tautan http.
— mpontillo
3
Hal lain tentang verifikasi sertifikat adalah bahwa klien perlu memverifikasi nama host. Tidak cukup baik untuk memeriksa bahwa sertifikat itu asli, itu harus masalah entitas yang ingin Anda ajak bicara (lihat di sini dan di sini ). Adapun sslstrip, pada akhirnya terserah pengguna untuk memeriksa apakah mereka ingin menggunakan SSL / TLS sayangnya (meskipun HSTS dapat membantu).
— Bruno
Dapatkah saya menulis plugin chrome (atau browser lain dalam hal ini) yang memotong data SEBELUM browser mengenkripsinya?
— Rosdi Kasim
Alasan lainnya adalah "Penyalahgunaan kepercayaan", seperti dalam masalah TürkTrust.
— ceremcem
1
@Remover Tidak juga ... # 1 adalah kunci pribadi di server, dipasangkan dengan kunci publik asli. Dalam skenario ini Anda akan berbicara dengan server sebenarnya tetapi orang lain dapat mendekripsi lalu lintas dengan berada di tengah. Mereka tidak dapat mengubah sertifikat. # 2 melibatkan pengiriman sertifikat yang sama sekali berbeda, yang dikeluarkan oleh CA "tepercaya" yang tampaknya sah untuk klien. Penyerang kemudian dapat mem-proxy permintaan atas nama Anda dan melihat pesan seperti itu. Keduanya menghasilkan kompromi tetapi # 1 ada di bawah kendali Anda. # 2, sayangnya, tidak.
— Dasar
17

Pertama-tama saya akan menjelaskan secara singkat prosedur otentikasi yang saya pahami, mungkin saya salah pada langkah itu. Jadi, klien memulai koneksi dan server menanggapinya dengan kombinasi kunci publik, beberapa metadata, dan tanda tangan digital dari otoritas tepercaya.

Server merespons dengan rantai sertifikat X.509 dan tanda tangan digital yang ditandatangani dengan kunci pribadinya sendiri.

Kemudian klien mengambil keputusan jika dia mempercayai server

Benar.

mengenkripsi beberapa kunci sesi acak dengan kunci publik dan mengirimkannya kembali.

Tidak. Klien dan server terlibat dalam proses pembuatan kunci sesi bersama di mana kunci sesi itu sendiri tidak pernah dikirim sama sekali.

Kunci sesi ini hanya dapat didekripsi dengan kunci pribadi yang disimpan di server.

Tidak.

Server melakukan ini

Tidak.

dan kemudian sesi HTTPS dimulai.

The TLS / SSL sesi dimulai, tetapi ada langkah-langkah lebih pertama.

Jadi, jika saya benar di atas, pertanyaannya adalah bagaimana serangan man-in-the-middle bisa terjadi dalam skenario seperti itu?

Dengan menyamar sebagai server dan bertindak sebagai titik akhir SSL. Klien harus mengabaikan langkah otorisasi apa pun. Sayangnya, satu-satunya langkah otorisasi di sebagian besar sesi HTTPS adalah pemeriksaan nama host.

Maksud saya, bahkan jika seseorang mencegat respons server (misalnya www.server.com) dengan kunci publik dan kemudian dengan beberapa cara biarkan saya berpikir bahwa dia adalah www.server.com, dia tetap tidak dapat mendekripsi kunci sesi saya tanpa kunci pribadi.

Lihat di atas. Tidak ada kunci sesi untuk didekripsi. Koneksi SSL itu sendiri aman, yang mungkin tidak aman dengan siapa Anda berbicara .

Berbicara tentang otentikasi bersama, apakah itu semua tentang kepercayaan server tentang identitas klien? Maksud saya, klien sudah bisa yakin bahwa dia berkomunikasi dengan server yang benar, tetapi sekarang server ingin mengetahui siapa kliennya, bukan?

Benar.

Dan pertanyaan terakhir adalah tentang alternatif otentikasi timbal balik. Jika saya bertindak sebagai klien dalam situasi yang dijelaskan, bagaimana jika saya mengirim login / kata sandi di header HTTP setelah sesi SSL dibuat? Seperti yang saya lihat, informasi ini tidak dapat dicegat karena koneksi sudah diamankan dan server dapat mengandalkannya untuk identifikasi saya. Apakah aku salah?

Tidak.

Apa kelemahan dari pendekatan tersebut dibandingkan dengan otentikasi bersama (hanya masalah keamanan yang penting, bukan kompleksitas implementasi)?

Ini hanya seaman nama pengguna / kata sandi, yang jauh lebih mudah bocor daripada kunci pribadi.

— Marquis dari Lorne
sumber
Terima kasih atas penjelasan Anda. Satu-satunya hal yang saya tidak mengerti adalah mengapa Anda mengatakan klien tidak mengirim kunci sesi ke server? Yah, mungkin saya telah menggunakan terminologi yang salah, di sini potongan data ini disebut "rahasia pra-master", tetapi bagaimanapun, bukankah itu dikirim oleh klien dan didekripsi dengan kunci pribadi server?
— Vadim Chekry
1
@VadimChekry Rahasia pra-master bukanlah kunci sesi. Ini adalah salah satu dari beberapa bagian data yang digunakan untuk membuat kunci sesi, secara independen di kedua ujungnya. Prosesnya dijelaskan dalam RFC 2246.
— Marquis dari Lorne
1
@Chris Anda jauh lebih tidak rentan, namun spoofing alamat IP dimungkinkan. Tidak ada pengganti untuk memeriksa sendiri identitas rekan di sertifikat.
— Marquis dari Lorne
1
+1 Ini adalah jawaban yang cukup bagus, untuk sebagian besar. Namun, beberapa poin kurang penjelasan dengan respons satu kata. Anda dapat membuatnya menjadi jawaban yang pasti jika Anda memperluas dan / atau menguraikan poin-poin tersebut, (misalnya, "tidak". Anda dapat menyebutkan secara singkat apa yang sebenarnya terjadi.) Di bagian utama. Itu akan menjelaskan beberapa hal. Terima kasih.
— suara
1
@ tjt263 Kata 'tidak' pertama memberikan penjelasan tentang apa yang sebenarnya terjadi. Dua 'tidak' berikutnya mengacu pada kesalahpahaman yang sama yang menghasilkan 'tidak' pertama, dan memiliki penjelasan yang sama. Kata 'tidak' berikutnya dan terakhir mengacu pada 'apakah saya salah' dan mengacu pada informasi yang baru saja dikutip dari OP. Oleh karena itu sulit untuk memahami apa yang menurut Anda sebenarnya hilang di sini.
— Marquis dari Lorne
17

Siapapun di jalan antara klien dan server dapat melakukan serangan man in the middle pada https. Jika menurut Anda ini tidak mungkin atau jarang, pertimbangkan bahwa ada produk komersial yang secara sistematis mendekripsi, memindai, dan mengenkripsi ulang semua lalu lintas ssl di gateway internet. Mereka bekerja dengan mengirim klien sebuah sertifikat ssl yang dibuat dengan cepat dengan rincian yang disalin dari sertifikat ssl "asli", tetapi ditandatangani dengan rantai sertifikat yang berbeda. Jika rantai ini diakhiri dengan CA browser mana pun yang tepercaya, MITM ini tidak akan terlihat oleh pengguna. Produk ini terutama dijual ke perusahaan untuk "mengamankan" (polisi) jaringan perusahaan, dan harus digunakan dengan sepengetahuan dan persetujuan pengguna. Namun secara teknis, tidak ada yang menghentikan penggunaannya oleh ISP atau operator jaringan lainnya. (Akan aman untuk mengasumsikan NSA memiliki setidaknya satu kunci penandatanganan CA root tepercaya ).

Jika Anda menyajikan halaman, Anda dapat menyertakan header HTTP yang menunjukkan kunci publik apa halaman tersebut harus ditandatangani. Ini mungkin membantu untuk mengingatkan pengguna ke MITM tentang koneksi "aman" mereka, tetapi ini adalah teknik kepercayaan-pada-penggunaan pertama. Jika Bob belum memiliki catatan dari pin kunci publik "nyata", Mallory hanya menulis ulang header pkp dalam dokumen. Daftar situs web yang menggunakan teknologi ini (HPKP) sangat pendek. Ini termasuk google dan dropbox, untuk kredit mereka. Biasanya, gateway penyadapan https akan melambai melalui halaman dari beberapa situs terpercaya besar yang menggunakan HPKP. Jika Anda melihat kesalahan HPKP saat Anda tidak menduganya, waspadalah.

Mengenai kata sandi, semua yang ada di koneksi https diamankan dengan https, kecuali nama domain, yang harus jelas agar permintaan dapat dialihkan. Secara umum, disarankan untuk tidak meletakkan kata sandi dalam string kueri, di mana kata sandi dapat berkeliaran di log, bookmark, dll. Tetapi string kueri tidak terlihat kecuali https dikompromikan.

— bbsimonbb
sumber
Tapi ini berarti peralatan MITM ini (yang mendekripsi / memindai dan mengenkripsi ulang lalu lintas) perlu memiliki akses ke salah satu CA tepercaya, bukan? (untuk "memalsukan" sertifikat server). Katakanlah ini terjadi. Kemudian seseorang memecahkan ini, infonya menjadi publik, dan akan ada skandal di pres dan sertifikat CA akan dihapus dari semua browser kan? Maksudku, idealnya ...
— jazzcat
2
Tidak tidak. "Inspeksi SSL" di gateway perlu membuat dan menandatangani sertifikat dengan cepat, tetapi tidak memerlukan sertifikat root untuk melakukannya. Ini memiliki beberapa sertifikat perantara, yang memiliki rantai. Apakah root rantai dipercaya oleh browser Anda atau tidak menentukan apakah Anda akan melihat kesalahan sertifikat. Di tempat kerja, kami diminta untuk memasang sertifikat root fortinet agar browser kami tidak memberikan kesalahan sertifikat. Tetapi jika rantai diakhiri dengan sertifikat yang sudah tepercaya, itu transparan.
— bbsimonbb
Seorang kolega di tempat kerja menggunakan pemahaman yang terbatas tentang mengapa teknik MITM jaringan perusahaan ini adalah ide buruk bagi Google untuk memaksa SSL - Mungkinkah dia benar-benar memiliki sedikit kebenaran?
— EmSixTeen
1
Maaf saya tidak mengerti pertanyaannya!
— bbsimonbb
2
  1. Benar
  2. Tidak begitu benar. Dalam serangan semacam itu, server itermediate mendapatkan permintaan Anda dan mengirimkannya ke tujuan atas nama Anda. dan kemudian menanggapi Anda dengan hasilnya. Sebenarnya itu adalah server man-in-the-middle yang membuat koneksi aman dengan Anda bukan server sebenarnya yang ingin Anda komunikasikan. itulah mengapa Anda HARUS selalu memeriksa apakah sertifikat tersebut valid dan terpercaya.
  3. bisa jadi benar
  4. Jika Anda yakin koneksi aman dipercaya maka apakah aman untuk mengirim nama pengguna / kata sandi.
— Boynux
sumber
Tentang 2 - Saya berasumsi bahwa klien secara menyeluruh memeriksa metadata yang dikirim oleh server selama prosedur pembuatan koneksi dan bahwa klien tidak mempercayai SEMUA sertifikat. Jadi, bukankah skenario seperti itu mungkin terjadi jika - a) klien tidak melakukan apa yang saya katakan di atas, atau b) man-in-the-middle telah mendapatkan sertifikat yang ditandatangani oleh CA tepercaya?
— Vadim Chekry
1
Sangat jarang terjadi bahwa server perantara mengirimkan sertifikat yang valid, tahun lalu terjadi dengan Comodo CA jika saya ingat dengan baik. Tetapi biasanya jika itu adalah koneksi tepercaya maka itu sepenuhnya aman.
— Boynux
1

Semua yang Anda katakan benar kecuali bagian tentang kunci sesi. Inti dari CA adalah untuk mengalahkan serangan man-in-the-middle - yang lainnya dilakukan oleh SSL itu sendiri. Otentikasi klien adalah alternatif dari nama pengguna dan skema kata sandi.

— David Schwartz
sumber
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.