it-swarm-id.com

Apakah koneksi HTTPS yang mapan berarti saluran benar-benar aman?

Dari pandangan seseorang yang menawarkan aplikasi web, ketika seseorang terhubung dengan TLS (https) ke layanan kami dan mengirimkan data otentikasi yang benar, apakah aman untuk mengirimkan semua data sensitif melalui jalur ini, atau mungkinkah masih ada yang menguping?

Pertanyaan ini adalah Pertanyaan Keamanan IT Minggu Ini.
Baca 29 Jul 2011 entri blog untuk lebih jelasnya atau kirim milik Anda sendiri Pertanyaan dalam Pekan.

112
Peter Smit

Penting untuk memahami apa yang dilakukan dan tidak dilakukan SSL, terutama karena ini merupakan sumber kesalahpahaman yang sangat umum.

  • Ini mengenkripsi saluran
  • Itu berlaku pemeriksaan integritas
  • Ini memberikan otentikasi

Jadi, jawaban cepatnya adalah: "ya, cukup aman untuk mengirimkan data sensitif". Namun, segala sesuatunya tidak sesederhana itu.

  • Versi terbaru SSL - versi 3, atau lebih baik lagi: TLS, bahkan TLS 1.2, jelas lebih baik daripada versi sebelumnya. Misalnya. SSL 2 relatif mudah untuk MITM (Man di tengah). Jadi, pertama tergantung pada versi protokol.
  • Enkripsi saluran dan pemeriksaan integritas dapat dikonfigurasi dalam protokol, mis. Anda dapat memilih algoritma mana yang akan digunakan (cipher suite). Jelas, jika Anda menggunakan RSA1024/SHA512 Anda jauh lebih baik ... Namun, SSL bahkan mendukung mode enkripsi NULL - mis. Tidak ada enkripsi sama sekali, hanya membungkus permintaan hingga terowongan melalui protokol SSL. Yaitu, tidak ada perlindungan. (Ini dapat dikonfigurasi baik pada klien dan server, cipher suite yang dipilih adalah set yang cocok pertama sesuai dengan urutan yang dikonfigurasi).
  • Otentikasi dalam SSL memiliki dua mode: otentikasi server saja, dan otentikasi timbal balik (sertifikat klien). Dalam kedua kasus tersebut, keamanan yang dijamin oleh sertifikat kriptografi jelas cukup kuat, namun validitas otentikasi yang sebenarnya hanya sebagus pemeriksaan validitas Anda: Apakah Anda bahkan repot-repot memeriksa sertifikat? Apakah Anda memastikan validitasnya? Rantai kepercayaan? Siapa yang mengeluarkannya? Dll.
  • Otentikasi ulang poin terakhir ini jauh lebih mudah di web aplikasi, di mana klien dapat dengan mudah melihat sertifikat server, ikon kunci mudah dilihat, dll. Dengan Web Layanan, Anda biasanya perlu lebih eksplisit dalam memeriksa validitasnya (tergantung pada pilihan platform Anda). Perhatikan bahwa titik yang sama ini telah membuat aplikasi seluler begitu banyak - bahkan jika pengembang aplikasi ingat untuk hanya menggunakan TLS antara ponsel dan server, jika aplikasi tidak secara eksplisit memverifikasi sertifikat maka TLS rusak.
  • Meskipun ada beberapa serangan teoretis pada kriptografi SSL, dari PoV saya masih cukup kuat untuk hampir semua tujuan, dan akan berlangsung lama.
  • Apa yang sebenarnya dilakukan dengan data di ujung yang lain? Misalnya. jika data kartu kreditnya sangat sensitif, atau bahkan, Anda tidak ingin itu di cache browser, atau riwayat, dll.
  • Cookie (dan dengan demikian otentikasi) dapat dibagi antara saluran SSL aman, dan HTTP tidak aman - kecuali ditandai secara eksplisit dengan atribut "aman".

Jadi, jawaban yang lebih pendek? Ya, SSL dapat cukup aman, tetapi (seperti pada kebanyakan hal) itu tergantung bagaimana Anda menggunakannya. :)

94
AviD

Ada beberapa masalah di sini, yang utama adalah otentikasi. Kedua ujungnya perlu memastikan bahwa mereka sedang berbicara dengan orang atau institusi yang tepat untuk menggagalkan serangan manusia di tengah. Pada akhirnya, sangat penting bagi Anda untuk menggunakan sertifikat SSL yang dipercaya oleh browser pengguna. Dengan melakukan hal itu, browser pengguna dapat yakin bahwa itu benar-benar berbicara ke situs yang benar. Setelah koneksi dibuat, Anda dapat memastikan untuk berbicara dengan pengguna itu sepanjang waktu dan koneksi dienkripsi, yaitu aman terhadap penyadapan.

Otentikasi ke arah lain (mis. Memastikan Anda berbicara dengan pengguna sebenarnya) biasanya ditangani di luar protokol SSL pada tingkat aplikasi dengan, misalnya, nama pengguna/kata sandi, openID atau beberapa bentuk kredensial lainnya.

Sebagai catatan terakhir, harus disebutkan bahwa selama koneksi handshake koneksi SSL klien dan server menyetujui Cipher suite dan klien dapat berpura-pura hanya melakukan "enkripsi nol", yaitu, tidak mengenkripsi data apa pun. . Jika server Anda menyetujui opsi itu, koneksi menggunakan SSL, tetapi data masih belum dienkripsi. Ini bukan masalah dalam praktik karena implementasi server biasanya tidak menawarkan nol sandi sebagai opsi.

23
Tronic

Selain yang tercantum dalam daftar AviD, SSL hanya seaman infrastruktur DNS yang mengarahkan Anda ke server itu, dan semua proksi perusahaan di jalur komunikasi.

Jika infrastruktur DNS diretas (keracunan cache, dll) maka penyerang dapat membuat pengguna Anda mengalami banyak serangan.

Selain itu jika klien akan melalui perangkat lunak seperti Fiddler , atau proksi perusahaan, perangkat lunak itu dapat easvdrop pada percakapan SSL Anda.

Untuk mengurangi ini, lihat "penerbit" sertifikat SSL. Jika koneksi SSL melalui proxy, maka penerbit akan menjadi proxy. Jika Anda melalui koneksi langsung, maka Anda akan melihat CA yang dipercayai publik yang relevan.

[Informasi lebih lanjut]

Proxy HTTPS perusahaan adalah sesuatu yang mengelola koneksi antara browser web dan Proxy (yang alamat IP-nya muncul di log server web Anda). Dalam hal ini konten web (kata sandi HTTPS juga) didekripsi, dan kemudian dienkripsi ulang di proksi perusahaan dan disajikan ke server Anda.

Bergantung pada siapa yang mengelola proxy, dan bagaimana lognya digunakan, ini mungkin dapat diterima atau hal buruk dari perspektif Anda.

Untuk informasi lebih lanjut tentang bagaimana intersepsi SSL dilakukan, lihat ini tautan :

Ketika Proxy SSL memotong koneksi SSL, ia menampilkan sertifikat server yang diemulasi ke browser klien. Browser klien mengeluarkan pop-up keamanan kepada pengguna akhir karena browser tidak mempercayai penerbit yang digunakan oleh ProxySG. Munculan ini tidak terjadi jika sertifikat penerbit yang digunakan oleh SSL Proxy diimpor sebagai root tepercaya di toko sertifikat browser klien.

ProxySG membuat semua sertifikat yang dikonfigurasi tersedia untuk diunduh melalui konsol manajemennya. Anda dapat meminta pengguna akhir untuk mengunduh sertifikat penerbit melalui Internet Explorer atau Firefox dan menginstalnya sebagai CA tepercaya di peramban pilihan mereka. Ini menghilangkan popup sertifikat untuk sertifikat yang ditiru ...

Beberapa perusahaan menyiasati masalah pop-up sertifikat yang disebutkan di atas dengan menyebarkan sertifikat root (dari Proxy) ke setiap workstation via GPO. Meskipun ini hanya akan mempengaruhi perangkat lunak yang menggunakan toko Sertifikat Microsoft. Perangkat lunak seperti Firefox dan Chrome perlu diperbarui secara berbeda.

20

Karena SSL bergantung pada Certificate-Authorities (CA), dan pada dasarnya organisasi mana pun dapat menjadi CA, serangan man-in-the-middle dengan sertifikat palsu namun ditandatangani CA selalu memungkinkan. Jadi, sementara SSL masih merupakan peningkatan besar daripada tidak enkripsi sama sekali, keamanannya dinilai terlalu tinggi karena sistem CA yang rusak. Dalam hal itu, sertifikat yang ditandatangani sendiri akan sama amannya dengan sertifikat yang ditandatangani CA mana pun, namun peramban menandainya sebagai mencurigakan.

11
Jörn Zaefferer

SSL sangat aman, meskipun seseorang dapat mencuri cookie sesi seseorang jika Anda menjalankan halaman APA SAJA melalui saluran yang tidak dienkripsi. Jika Anda bisa, saya akan membuat situs semua-SSL. Atau mungkin cookie hanya mengirim untuk koneksi terenkripsi dan memiliki halaman publik tanpa jaminan tidak spesifik untuk pengguna itu.

10
James T

Masih ada kemungkinan serangan man-in-the-middle, yang dalam kasus Anda adalah pengguna yang terhubung ke pihak ketiga yang mengklaim sebagai situs Anda dan kemudian meneruskan permintaan. Tentu saja, pengguna yang cerdas harus memperhatikan kurangnya koneksi SSL atau sertifikat yang salah tetapi sebagian besar pengguna tidak dihidupkan dan ditipu oleh favicon gembok.

Ini sebenarnya bukan masalah dengan SSL itu sendiri, hanya sesuatu yang harus diperhatikan. Anda dapat dengan aman berasumsi bahwa tidak ada yang dapat menguping koneksi SSL antara situs Anda dan sumber koneksi. Namun, Anda tidak dapat memastikan bahwa sumber koneksi tersebut benar-benar pengguna.

9
Magnus

Karena SSL crypts transmisi, tidak ada data yang dapat dikuping (karena sertifikat dipercaya).

Meskipun masalahnya ada di tempat (dan berapa banyak) Anda menggunakan SSL di webapp Anda: katakanlah, misalnya, Anda memerlukan koneksi SSL hanya untuk mengautentikasi pengguna Anda (untuk membiarkan mereka mengirim mereka crypted user/pass pasang ke server Anda) , maka ketika Anda mengirim kembali sebuah cookie Anda harus menyadari bahwa itu bisa dengan mudah dicegat (seperti jika pengguna Anda berada pada koneksi nirkabel yang tidak terlindungi).

Drama FireSheep baru-baru ini adalah semua tentang ini.

9
gbr

Tidak. Analisis lalu lintas masih dapat memberi tahu banyak orang.

Analisis lalu lintas adalah proses mencegat dan memeriksa pesan untuk menyimpulkan informasi dari pola dalam komunikasi. Itu dapat dilakukan bahkan ketika pesan dienkripsi dan tidak dapat didekripsi. Secara umum, semakin besar jumlah pesan yang diamati, atau bahkan dicegat dan disimpan, semakin banyak yang dapat disimpulkan dari lalu lintas.


TLS biasanya dikerahkan untuk menjaga kerahasiaan - penyerang tidak boleh mencapai tingkat kepercayaan yang tinggi tentang isi komunikasi.

Asumsi,

  1. seorang penyerang tahu protokol Anda,
  2. seorang penyerang tahu siapa yang berkomunikasi dengan siapa
  3. penyerang tidak dapat mendekripsi pesan.
  4. anda tidak mengaburkan lalu lintas nyata Anda di banyak lalu lintas omong kosong (chaff)

Seorang penyerang mungkin dapat mengetahui kapan Anda bangun dan kapan Anda tidur terlepas dari protokol, dan mungkin bisa memberi tahu lebih banyak tergantung pada sifat protokol yang Anda gunakan.


Jika protokol Anda sangat sederhana:

  1. Anda mengirim pesan "nyalakan nuklir di ..." saat Anda ingin memecat nuklir
  2. Anda tidak mengirim pesan saat Anda tidak ingin memecat nuklir.

Seorang penyadap yang tidak bisa mendekripsi data Anda dapat menentukan hanya dengan kehadiran pesan yang ingin Anda buatkan nuklir, meskipun mungkin tidak pada siapa.


Jika protokol Anda lebih kompleks:

  1. Anda meminta buku.
  2. Saya mengirim Anda konten.

Penyerang mungkin tidak dapat memberi tahu siapa yang membaca "War and Peace" vs "Atlas Shrugged" tetapi dapat membedakan, berdasarkan murni pada ukuran pesan, apakah mereka membaca salah satu dari yang sebelumnya vs. Kafka's 55 novel halaman "The Metamorphosis".

7
Mike Samuel

SSL melakukan dua tugas dasar: otentikasi dan enkripsi.

Otentikasi dilakukan melalui otoritas sertifikat (CA). Browser dilengkapi dengan daftar sertifikat SSL untuk kunci penandatanganan CA. CA menandatangani sertifikat yang menjelaskan kunci publik suatu entitas. Misalnya, jika saya memiliki Google.com, saya akan membuktikannya kepada Verisign dan mereka akan menandatangani sertifikat saya untuk beberapa waktu. Masalah muncul dengan CA menandatangani sertifikat yang tidak seharusnya mereka tanda tangani. Ini dapat terjadi ketika seseorang berpura-pura memiliki domain lain, memperoleh sertifikat wildcard yang terlalu luas, atau sekadar XKCDs CA mengeluarkan sesuatu yang jahat (pemerintah, mungkin?). Kami telah melihat contoh dari semua hal di atas terjadi, tetapi sangat jarang.

Jika sertifikat untuk situs ditandatangani dengan benar dan tidak ada sertifikat palsu dalam rantai kepercayaan Anda, maka ketika Anda terhubung ke situs, Anda dapat (untuk tujuan diskusi) yakin bahwa sertifikat tersebut cocok. Dalam keadaan normal, koneksi itu dienkripsi. Itu mencegah siapa pun membaca data Anda.

Sertifikat SSL sangat kompleks, dan ada sejumlah serangan terhadap implementasi SSL. Yang dapat dilakukan SSL secara efektif adalah mencegah saya mengawasi lalu lintas Anda di Starbucks lokal ketika Anda memeriksa email Anda di GMail. Apa yang tidak bisa dilakukan adalah mencegah saya menggunakan serangan MITM tempat saya menyampaikan semuanya kepada Anda tanpa SSL dan klien Anda tidak siap untuk mengganggumu tentang fakta bahwa tidak pernah memulai sesi terenkripsi.

6
Jeff Ferland

Tidak menghitung berbagai jawaban oleh orang lain tentang masalah potensial lainnya, dengan asumsi Anda menggunakan SSL 3.0 dan enkripsi yang kuat, itu harus aman.

Menggunakan protokol ssl yang lebih lama (2.0) atau menggunakan kunci enkripsi yang lemah bisa membuat Anda rentan.

4
Doozer Blake

SSL umumnya meningkatkan keamanan dengan menyediakan:

  1. Otentikasi Server (pengguna tahu mereka berbicara ke situs 'benar')
  2. Integritas data (pengguna dan server tahu bahwa lalu lintas tidak sedang dimodifikasi dalam perjalanan)
  3. (opsional, tetapi biasanya) Privasi data (pengguna dan server tahu bahwa lalu lintas tidak dicegat dalam perjalanan)
  4. (opsional, tetapi jarang) Otentikasi klien, jika klien juga memiliki sertifikat

Pada dasarnya hanya ada dua jenis sertifikat SSL, sertifikat server (yang selalu terlibat) dan sertifikat klien (yang opsional).

Ini hanya sebuah sketsa, dan ada banyak ifs, ands dan buts. Dalam skenario paling umum, SSL berbasis browser, skema ini dapat rusak dalam banyak kasus tanpa melanggar kriptografi atau protokol, tetapi hanya dengan mengandalkan pengguna untuk melakukan hal yang salah (mis. Abaikan peringatan browser dan hubungkan bagaimanapun juga). Serangan phishing juga dapat bekerja dengan mengirimkan pengguna ke situs yang dilindungi SSL palsu, dibuat menyerupai yang asli dalam segala hal selain URL.

Setelah mengatakan bahwa SSL dan TLS sepupunya masih sangat berguna karena mereka setidaknya memungkinkan untuk komunikasi yang aman, meskipun jauh dari mudah.

4
frankodwyer

@Vladimir benar bahwa http://en.wikipedia.org/wiki/Forward_secrecy diinginkan, tetapi rinciannya salah. Server memilih ciphersuite ini di antara mereka yang ditawarkan oleh browser. "dienkripsi dengan RC4_128 dengan SHA1 untuk otentikasi pesan" tidak menggunakan enkripsi RC4 128-bit dan pemeriksaan integritas HMAC-SHA-1. (Nama Ciphersuite dalam SSL/TLS hingga saat ini mengatakan SHA tetapi artinya SHA-1 dan sebenarnya HMAC-SHA-1.) "ECDHE_ECDSA sebagai mekanisme pertukaran kunci" tidak berlaku untuk pesan individual , itu adalah bagian (sebagian besar) dari jabat tangan yang terjadi satu kali pada awal sesi: ECDHE menggunakan varian Kurva Elliptic dari Diffie-Hellman dalam mode Ephemeral (ditambah beberapa langkah tambahan yang tidak penting di sini) untuk membuat sesi kunci digunakan untuk enkripsi dan HMAC, dan pertukaran kunci ECDHE (hanya) ditandatangani oleh varian Kurva Elliptic dari Digital Signature Algorithm. (Anda tidak pernah dapat mengenkripsi apa pun secara langsung dengan DH atau ECDH, mereka hanya melakukan kunci atau perjanjian rahasia kecil lainnya.)

2

Saat Anda tidak menggunakan SSL, semua komunikasi dapat dengan mudah dicegat - satu-satunya hal yang perlu dilakukan adalah meluncurkan sniffer paket (mis. Wireshark).
SSL mencegah hal itu, semua paket dienkripsi sehingga tidak ada cara untuk mengetahui apa yang Anda kirim. Pada dasarnya ini digunakan untuk melindungi kata sandi dan konten pribadi dari intersepsi. Anda jelas tidak ingin orang lain membaca email pribadi Anda, bukan?
Adapun pencarian Google, mereka hanya melakukannya untuk menyembunyikan apa yang diminta orang. Ini karena beberapa pemerintah terlalu ingin tahu tentang hal itu.

Bagaimana SSL meningkatkan keamanan? Itu tidak dengan sendirinya. Apa yang dilakukan adalah kombinasi enkripsi (kunci SSL) dan PKI (Infrastruktur Kunci Publik) - terutama Sertifikat. OK, pertanyaannya adalah bagaimana. Di satu sisi itu mengamankan saluran komunikasi Anda (lihat di atas), di sisi lain memastikan Anda berbicara dengan bisnis yang sah - mengotentikasi server. Jadi salurannya aman dan tepercaya.

Ada beberapa Sertifikat SSL, karena ada beberapa --- Layanan PKI . Pada dasarnya layanan yang berbeda memerlukan jenis Sertifikat SSL yang berbeda. Jadi ada Sertifikat untuk penandatanganan kode, enkripsi dan penandatanganan e-mail, yang mengenai otentikasi server, dan sebagainya.

2
Paweł Dyda

Ketika seseorang terhubung dengan SSL (https) ke layanan kami dan mengirimkan data otentikasi yang benar, apakah aman untuk mengirimkan semua data sensitif melalui baris ini, atau mungkinkah masih ada yang menguping?

Tautan yang lemah dalam rantai ini hampir pasti bukan SSL tetapi pengguna, yang umumnya dapat ditipu untuk terhubung ke situs perantara palsu baik melalui spoofing web/spoofing hyperlink, atau dengan disajikan sertifikat yang tidak valid dan mengabaikan peringatan browser dan melanjutkan ke tetap terhubung.

Namun sistem yang Anda gambarkan adalah praktik terbaik, bagaimanapun, tidak banyak yang dapat Anda lakukan (selain mendidik pengguna Anda untuk menganggap serius peringatan SSL jika Anda bisa).

2
frankodwyer

Jawaban singkatnya adalah tidak. Jawaban yang lebih panjang: kumpulan jawaban di atas plus: Jika kita menyelesaikan otentikasi, maka man-in-the-middle, bahwa dengan koneksi SSL tradisional seseorang yang mendengarkan lalu lintas masih dapat mendekripsi nanti jika mereka memperoleh kunci rahasia server (pikirkan dari NSA dan National Security Letters). Ada opsi dalam protokol TLS untuk menggunakan protokol Diffie-Helman untuk memastikan tautan secara rahasia. Lihat gambar berikut ketika saya mengakses gmail.com menggunakan Chrome. connection security

Lihatlah teks RC4_128 dengan SHA1 untuk otentikasi pesan ECDHE_ECDSA. Ini berbunyi:

  1. Server menawarkan saluran SSL RC4_128b dengan SHA digest
  2. Di dalam terowongan ini setiap pesan dienkripsi dengan kurva Ecliptic di mana kunci diturunkan menggunakan fungsi Diffie-Helman, dan ditandatangani dengan cipher Kurva Ecliptic menggunakan Digital Signature Algorithm

Dengan kata lain, bahkan jika seseorang memiliki kunci pribadi dari server SSL, pesan-pesan tersebut telah dienkripsi dengan kunci sementara yang dibuang dari memori segera setelah digunakan. Semoga beruntung, NSA!

2
Vladimir Jirasek

Apakah aman untuk pengguna, atau aman untuk Anda? Anggaplah serangan pria di tengah. Penyerang berhasil menangkap lalu lintas pengguna, berpura-pura menjadi Anda, dan berpura-pura menjadi pengguna bagi Anda. Serangan semacam itu biasanya akan gagal, karena sertifikat yang diberikan kepada pengguna tidak akan benar. Misalnya, penyerang memberi pengguna sertifikat yang ditandatangani sendiri untuk situs web Anda. Namun, jika pengguna bertindak bodoh, mereka dapat menerima sertifikat yang ditandatangani sendiri itu. Jadi sekarang penyerang dapat membaca dan memodifikasi semua lalu lintas antara pengguna dan Anda, dan sejauh yang saya tahu tidak ada cara bagi Anda untuk mendeteksi ini.

Jadi jika pengintaian dan modifikasi lalu lintas menyakiti pengguna, itu benar-benar kesalahan mereka sendiri dan masalah mereka sendiri. Dan Anda tidak dapat mencegahnya sepenuhnya, karena MITM dapat memotong Anda sepenuhnya dan hanya berbicara dengan pengguna yang berpura-pura menjadi Anda. Tetapi jika pengintaian dan modifikasi lalu lintas menyakiti Anda, maka Anda harus memercayai pengguna untuk tidak bodoh, atau lebih baik mengotentikasi pengguna juga (pengguna akan membutuhkan sertifikat, dan Anda dapat memeriksanya dengan cara yang tidak dapat dilakukan MITM. palsu).

2
gnasher729

Bahkan versi paling modern HTTPS menggunakan TLS dapat dengan mudah dicegat oleh MitM (mis. A perangkat Juniper dikonfigurasi untuk tujuan tersebut) jika klien mempercayai CA. Dalam kasus tertentu, itu tidak aman.

1
user3260912

Saya pikir orang di sini tidak mengerti pertanyaan:

Jika Anda memiliki saluran yang tidak aman, dan Anda berhasil membuat Koneksi SSH/SSL di atas jalur ini, ia sekarang bertanya apakah aman untuk membuat asumsi bahwa saluran tersebut "aman" dan bahwa data yang tidak dienkripsi dapat dilewatkan SELAMA dengan Koneksi terenkripsi ( misalnya, di depan mata, tidak di dalam SSL/SSH Connection terenkripsi).

Saya akan mengatakan tidak. Dalam hal ini, mungkin ada penyadap pasif yang hanya mengabaikan data terenkripsi dan menyimpan data tidak terenkripsi.

TAPI Anda dapat yakin bahwa tidak ada Penyadap aktif (MITM), yang berarti Anda dapat dengan aman membuat Sambungan SSL/SSH yang tidak diautentikasi dengan sumber/tujuan yang sama dengan jalur yang diautentikasi. Ini asalkan tidak ada penyadap selektif bahwa MITM konektor tertentu, TETAPI bagaimanapun, penyadap itu tidak bisa tahu apakah Anda akan mengotentikasi Koneksi atau tidak, jadi dia tidak bisa tahu Koneksi ke MITM mana untuk menghindari deteksi. MITMer akan, jika ia MITM, MITM semua Koneksi dan berharap orang mengklik melalui semua dialog otentikasi sederhana.

Dengan demikian: Jika Anda menyambungkan ke layanan SSL dari misalkan 123.123.123.123 ke 24.24.24.24, Anda juga dapat menghubungkan klien SSH dengan aman dari 123.123.123.123 ke 24.24.24.24 tanpa saling mengautentikasi sidik jari SSH, asalkan Anda dapat mempercayai semuanya di belakang sisi lain NAT router atau firewall.

Tetapi bahkan jika itu aman pada umumnya berarti, ada IS risiko kecil bahwa penyadap mengacak Koneksi MITM secara acak dan berharap tidak terdeteksi, jadi karena Anda sudah memiliki Koneksi terotentikasi ke IP target, mengapa tidak menggunakan Koneksi terotentikasi untuk saling memverifikasi sidik jari SSH? Sederhana saja dengan memposting sidik jari SSH yang benar di situs web yang dilindungi SSL!

1