it-swarm-tr.com

Kurulu bir HTTPS bağlantısı bir hattın gerçekten güvenli olduğu anlamına mı geliyor?

Bir web uygulaması sunan birinin bakış açısından, bir kişi hizmetimize TLS (https) ile bağlandığında ve doğru kimlik doğrulama verilerini gönderdiğinde, tüm hassas verileri bu hat üzerinden iletmek güvenli midir yoksa hala dinleniyor olabilir mi?

Bu soru Haftanın BT Güvenlik Sorus idi.
Daha fazla bilgi için 29 Tem 2011 blog girişi bölümünü okuyun veya kendinizinkini gönderin Haftanın Sorusu.

112
Peter Smit

SSL'nin ne yaptığını ve yapmadığını anlamak önemlidir, özellikle de bu çok yaygın bir yanlış anlama kaynağıdır.

  • Kanalı şifreler
  • Bütünlük denetimi uygular
  • Kimlik doğrulama sağlar

Bu nedenle, hızlı cevap şöyle olmalıdır: "evet, hassas verileri iletecek kadar güvenli". Ancak, işler o kadar basit değil.

  • SSL'nin en yeni sürümleri - sürüm 3 veya daha iyisi: TLS, hatta TLS 1.2 bile, önceki sürümlerden kesinlikle daha iyi. Örneğin. SSL 2, MITM (ortadaki adam) için nispeten kolaydı. Yani, önce protokol sürümüne bağlıdır.
  • Hem kanal şifreleme hem de bütünlük kontrolü protokolde yapılandırılabilir, yani hangi algoritmaları kullanacağınızı seçebilirsiniz (şifre takımı). Açıkçası, RSA1024/SHA512 kullanıyorsanız çok daha iyi durumdasınız ... Ancak, SSL bile NULL şifreleme modunu destekliyor - yani şifreleme yok, sadece SSL protokolü üzerinden tünele kadar istekleri tamamlıyor. Yani, koruma yok. (Bu hem istemcide hem de sunucuda yapılandırılabilir, seçilen şifre paketi yapılandırılan sıraya göre ilk eşleşen kümedir).
  • SSL'deki kimlik doğrulamasının iki modu vardır: yalnızca sunucu kimlik doğrulaması ve karşılıklı kimlik doğrulama (istemci sertifikaları). Her iki durumda da, kriptografik sertifikaların sağladığı güvenlik kesinlikle yeterince güçlüdür, ancak asıl kimlik doğrulamasının geçerliliği yalnızca geçerlilik kontrolleriniz kadar iyidir: Sertifikayı kontrol etmeyi bile zahmete sokuyor musunuz? Geçerliliğini sağlıyor musunuz? Güven zinciri? Kim yayınladı? Vb.
  • Bu son nokta yeniden kimlik doğrulaması web'de çok daha kolaydır ygulamalar, burada istemci kolayca sunucu sertifikasını görüntüleyebilir, kilit simgesi kolayca görüntülenebilir, vb. Web Hizmetler, geçerliliğini kontrol ederken genellikle daha açık olmanız gerekir (platform seçiminize bağlı olarak). Aynı noktanın çok sayıda mobil uygulamayı tetiklediğini unutmayın - uygulama geliştiricisi telefon ve sunucu arasında yalnızca TLS kullanmayı hatırlasa bile, uygulama sertifikaları açıkça doğrulamazsa TLS bozulur.
  • SSL'nin kriptografisine çoğunlukla teorik saldırılar olsa da, PoV'umdan neredeyse tüm amaçlar için yeterince güçlü ve uzun sürecek.
  • Diğer uçtaki verilerle gerçekte ne yapılır? Örneğin. süper hassas veya hatta kredi kartı verileri varsa, tarayıcı önbelleğinde veya geçmişinde vb.
  • Çerezler (ve dolayısıyla kimlik doğrulaması), açıkça "güvenli" özelliğiyle işaretlenmedikçe güvenli, SSL kanalı ve güvenli olmayan bir HTTP kanalı arasında paylaşılabilir.

Peki, daha kısa cevap? Evet, SSL can yeterince güvenli olun, ancak (çoğu şeyde olduğu gibi) nasıl kullandığınıza bağlıdır. :)

94
AviD

Burada birkaç sorun var, en önemlisi kimlik doğrulama. Her iki ucun da ortadaki adam saldırılarını engellemek için doğru kişi veya kurumla konuştuğundan emin olmaları gerekir. Sonunda, kullanıcının tarayıcısı tarafından güvenilen bir SSL sertifikası kullanmanız çok önemlidir. Bunu yaparak kullanıcının tarayıcısı gerçekten doğru siteyle konuştuğundan emin olabilir. Bağlantı kurulduktan sonra, o kullanıcıyla her zaman konuştuğunuzdan ve bağlantının şifreli olduğundan emin olabilirsiniz, yani gizli dinlemeye karşı güvende olursunuz.

Diğer yönde kimlik doğrulaması (yani gerçek kullanıcıyla konuştuğunuzdan emin olun) genellikle uygulama düzeyinde SSL protokolünün dışında, örneğin kullanıcı adı/şifre, openID veya başka bir kimlik bilgileri ile ele alınır.

Son bir not olarak, SSL bağlantısı sırasında el sıkışma istemcisi ve sunucusunun bir Cipher suite üzerinde anlaştığı ve müşterinin yalnızca "boş şifreleme" yapıyormuş gibi davranabileceği, yani hiçbir veriyi şifreleyemeyeceği belirtilmelidir. . Sunucunuz bu seçeneği kabul ederse, bağlantı SSL kullanır, ancak veriler yine de şifrelenmez. Bu, uygulamada bir sorun değildir, çünkü sunucu uygulamaları genellikle boş şifreyi bir seçenek olarak sunmaz.

23
Tronic

AviD'nin listelediklerine ek olarak, SSL yalnızca sizi o sunucuya yönlendiren DNS altyapısı ve iletişim yolundaki tüm kurumsal proxy'ler kadar güvenlidir.

DNS altyapısı saldırıya uğramışsa (önbellek zehirlenmesi vb.) Saldırgan, kullanıcılarınızı birçok saldırıya maruz bırakabilir.

Buna ek olarak, istemci Fiddler gibi bir şirket yazılımından ya da bir şirket proxy'sinden geçiyorsa, söz konusu yazılım SSL görüşmenizde kolayca yardımcı olabilir.

Bunu hafifletmek için SSL sertifikasının "yayıncısına" bakın. SSL bağlantısı bir proxy üzerinden geçiyorsa, yayıncı proxy'nin bağlantısı olacaktır. Doğrudan bir bağlantıdan geçiyorsanız, ilgili genel olarak güvenilen CA'yı görürsünüz.

[Daha fazla bilgi]

Şirket HTTPS proxy'si, web tarayıcısı ile Proxy (IP adresi web sunucusu günlüklerinizde görünen) arasındaki bağlantıyı yöneten bir şeydir. Bu durumda web içeriğinin (HTTPS şifresi de) şifresi çözülür ve daha sonra şirket proxy'sinde yeniden şifrelenir ve sunucunuza sunulur.

Proxy'yi kimin yönettiğine ve günlüklerinin nasıl kullanıldığına bağlı olarak, bu sizin açınızdan kabul edilebilir veya kötü bir şey olabilir.

SSL müdahalesinin nasıl yapıldığı hakkında daha fazla bilgi için, bkz --- link :

SSL Proxy bir SSL bağlantısına müdahale ettiğinde, istemci tarayıcısına benzetilmiş bir sunucu sertifikası sunar. İstemci tarayıcısı son kullanıcıya bir güvenlik açılır penceresi yayınlar, çünkü tarayıcı ProxySG tarafından kullanılan vericiye güvenmez. SSL Proxy tarafından kullanılan yayıncı sertifikası, istemci tarayıcısının sertifika deposunda güvenilir bir kök olarak içe aktarılırsa, bu pop-up oluşmaz.

ProxySG, yapılandırılmış tüm sertifikaları yönetim konsolu aracılığıyla indirilebilir hale getirir. Son kullanıcılardan ihraç sertifikasını Internet Explorer veya Firefox üzerinden indirmelerini ve tercih ettikleri tarayıcılarına güvenilir bir CA olarak yüklemelerini isteyebilirsiniz. Bu taklit sertifikalar için sertifika açılır penceresini ortadan kaldırır ...

Bazı şirketler, GPO üzerinden her iş istasyonuna (Proxy'nin) kök sertifikalarını dağıtarak yukarıda belirtilen sertifika pop-up sorununu çözer. Her ne kadar bu yalnızca Microsoft Sertifika deposunu kullanan yazılımı etkiler. Firefox ve Chrome gibi yazılımların farklı güncellenmesi gerekir).

20

SSL Sertifika Yetkililerine (CA) bağlı olduğundan ve temelde herhangi bir kuruluş CA olabileceğinden, sahte ancak CA imzalı sertifikalarla ortadaki adam saldırıları her zaman mümkündür. Bu nedenle SSL, şifreleme olmamasına rağmen hala büyük bir gelişme olsa da, bozuk CA sistemi nedeniyle güvenliği abartılıyor. Bu bağlamda, kendinden imzalı sertifikalar CA imzalı herhangi bir sertifika kadar güvenli olacaktır, ancak tarayıcılar bunları şüpheli olarak işaretler.

11
Jörn Zaefferer

SSL çok güvenlidir, ancak şifrelenmemiş bir satır üzerinden HERHANGİ bir sayfa çalıştırırsanız birisi oturum çerezini çalabilir. Yapabilseydin siteyi tamamen SSL yapardım. Veya çerezin yalnızca şifrelenmiş bağlantılar için göndermesini ve bu kullanıcıya özgü olmayan güvenli olmayan genel sayfalara sahip olmasını isteyebilirsiniz.

10
James T

Hala ortadaki adam saldırısı olasılığı vardır, ki bu durumda sizin siteniz olduğunu iddia eden üçüncü bir tarafa bağlanan ve daha sonra isteği ileten kullanıcı olabilir. Tabii ki, anlayışlı bir kullanıcı SSL bağlantısının veya yanlış sertifikanın eksikliğini fark etmelidir, ancak çoğu kullanıcı bu açık değildir ve bir asma kilit faviconu tarafından kopyalanır.

Bu gerçekten SSL'nin kendisi ile ilgili bir sorun değil, sadece farkında olması gereken bir şey. Güvenli bir şekilde, hiç kimsenin siteniz ile bağlantının kaynağı arasındaki SSL bağlantısına kulak asamadığını varsayabilirsiniz. Ancak, bağlantının kaynağının gerçekten kullanıcı olduğundan emin olamazsınız.

9
Magnus

SSL iletimi şifrelediğinden, hiçbir veri gizlice dinlenemez (sertifika güvenilir olduğundan).

Sorun, web uygulamanızda SSL'yi nerede (ve ne kadar) kullandığınız konusunda olsa da: örneğin, yalnızca kullanıcının kimliğini doğrulamak için bir SSL bağlantısına ihtiyacınız var (şifreli kullanıcı/geçiş çiftlerini sunucunuza göndermelerine izin vermek için) , bir çerezi geri gönderdiğinizde, çerezin kolayca ele geçirilebileceğinin farkında olmalısınız (örneğin, kullanıcınız korumasız bir kablosuz bağlantıdaymış gibi).

Son FireSheep draması bununla ilgili.

9
gbr

Hayır. Trafik analizi hala birine çok şey söyleyebilir.

Trafik analizi, iletişimdeki kalıplardan bilgi çıkarmak için mesajlara müdahale etme ve inceleme sürecidir. Mesajlar şifrelendiğinde ve şifresi çözülemediğinde bile gerçekleştirilebilir. Genel olarak, gözlenen mesaj sayısı arttıkça, hatta kesilip kaydedildiğinde, trafikten daha fazla çıkarılabilir.


TLS genellikle gizliliği korumak için kullanılır - bir saldırgan iletişim içeriği konusunda yüksek bir güven düzeyine erişmemelidir.

Farz

  1. bir saldırgan protokolünüzü bilir,
  2. bir saldırgan kimin kiminle iletişim kurduğunu bilir
  3. saldırgan mesajların şifresini çözemez.
  4. gerçek trafiğinizi bir çok saçma trafikte (saman) gizlemezsiniz

Saldırgan muhtemelen protokolden bağımsız olarak ne zaman uyanık olduğunuzu ve ne zaman uyuduğunuzu söyleyebilir ve kullandığınız protokolün doğasına bağlı olarak çok daha fazlasını söyleyebilir.


Protokolünüz çok basitse:

  1. Nükleer silahları ateşlemek istediğinizde "nükleer silahları ateşleyin ..."
  2. Nükleer silah ateşlemek istemediğinizde mesaj göndermezsiniz.

Verilerinizin şifresini çözemeyen bir kulak misafiri, nükleer silahları ateşlemek istediğiniz bir mesajın varlığına göre belirleyebilir, ancak belki de kim değil.


Protokolünüz daha karmaşıksa:

  1. Bir kitap istersiniz.
  2. Sana içerik gönderiyorum.

Bir saldırgan kimin okuduğunu söyleyemeyebilir "Savaş ve Barış" ve "Atlas Omuz silkti" ancak eski mesajlardan birine göre Kafka'nın 55'inden birini okuyup okumadığını sadece ayırt edebilir sayfa romanı "Metamorfoz".

7
Mike Samuel

SSL iki temel görevi yerine getirir: kimlik doğrulama ve şifreleme.

Kimlik doğrulama, sertifika yetkilileri (CA) aracılığıyla yapılır. Tarayıcılar, CA'ların imzalama anahtarları için bir SSL sertifikaları listesi ile birlikte gelir. CA'lar, bir varlığın ortak anahtarını açıklayan sertifikaları imzalar. Örneğin, Google.com'a sahip olsaydım, bunu Verisign'a kanıtlarım ve sertifikamı bir süre imzalayacaklardı. Bir CA ile ilgili sorunlar, imzalamaması gereken bir sertifikayı imzalar. Bu, bir başkası başka bir alan adına sahip gibi davrandığında, çok geniş veya sadece sade bir joker karakter sertifikası edindiği zaman ortaya çıkabilir XKCDs CA hain bir şey yayınlamaya başlar (belki hükümetler?). Yukarıdakilerin hepsinin örnekleri olduğunu gördük, ancak oldukça nadirdir.

Bir site için sertifika doğru şekilde imzalanmışsa ve güven zincirinizde sahte sertifika yoksa, bir siteye bağlandığınızda (tartışma amacıyla) sertifikanın eşleştiğinden emin olabilirsiniz. Normal şartlar altında bu bağlantı şifrelenir. Bu, herhangi birinin verilerinizi okumasını engeller.

SSL sertifikaları çok karmaşıktır ve SSL uygulamalarına karşı bir dizi saldırı vardır. SSL'nin etkili bir şekilde yapabileceği, GMail'de e-postanızı kontrol ettiğinizde yerel Starbucks'ta trafiğinizi izlememi engellemektir. Yapamayacağı şey, SSL olmadan her şeyi size aktardığım bir MITM saldırısı kullanmama engel olmak ve müşteriniz sizi asla şifrelenmiş bir oturum başlatmadığı için rahatsız etmiyor.

6
Jeff Ferland

SSL 3.0 ve güçlü şifreleme kullandığınızı varsayarsak, diğer olası sorunlar hakkında başkalarının çeşitli yanıtlarını saymazsak, güvenli olmalıdır.

Eski SSL protokollerini (2.0) kullanmak veya zayıf bir şifreleme anahtarı kullanmak sizi güvenlik açıklarına açabilir.

4
Doozer Blake

SSL genellikle aşağıdakileri sağlayarak güvenliği artırır:

  1. Sunucu Kimlik Doğrulaması (kullanıcı 'doğru' siteyle konuştuğunu bilir)
  2. Veri bütünlüğü (kullanıcı ve sunucu, trafiğin rotada değiştirilmediğini bilir)
  3. (isteğe bağlı olarak, ancak tipik olarak) Veri gizliliği (kullanıcı ve sunucu, trafikte yolun kesilmediğini bilir)
  4. (isteğe bağlı, ancak nadir) İstemcinin de sertifikası varsa istemci kimlik doğrulaması

Aslında iki tür SSL sertifikası vardır: sunucu sertifikası (her zaman dahil olan) ve bir istemci sertifikası (isteğe bağlı).

Bu sadece bir taslak ve birçok ifs, ands ve buts var. En tipik senaryoda, tarayıcı tabanlı SSL'de, şema çoğu durumda kriptografiyi veya protokolü bozmadan kırılabilir, ancak sadece yanlış şeyi yapmak için kullanıcıya güvenerek (yani tarayıcı uyarılarını göz ardı edin ve yine de bağlanır). Kimlik avı saldırıları, kullanıcıyı URL dışında gerçek anlamda benzeyen sahte bir SSL korumalı siteye göndererek de işe yarayabilir.

SSL ve kuzeni TLS'nin, en azından güvenli olmamasına rağmen, kusursuz olmakla birlikte, hala çok yararlı olduğunu söyledikten sonra.

4
frankodwyer

@Vladimir, http: //en.wikipedia.org/wiki/Forward_secrecy tercih edilir, ancak ayrıntıları yanlıştır. Sunucu bu tarayıcıdan seçti bu ciphersuite sunulan arasından. "mesaj kimlik doğrulaması için SHA1 ile RC4_128 ile şifrelenmiş" RC4 128-bit şifreleme ve HMAC-SHA-1 bütünlük kontrolü kullanır. (SSL/TLS'deki şifreli isimler yakın zamana kadar SHA demektedir ancak SHA-1 ve aslında HMAC-SHA-1 anlamına gelmektedir.) "Anahtar değişim mekanizması olarak ECDHE_ECDSA" tek tek iletilere uygulanmaz , oturumun başında bir kez meydana gelen el sıkışmasının bir parçasıdır (ECDHE), oturum oluşturmak için Geçici modda Diffie-Hellman'ın Eliptik Eğri varyantını (artı burada önemli olmayan bazı ek adımlar) kullanır anahtarlar şifreleme ve HMAC için kullanılır; ve ECDHE anahtar değişimi (yalnızca) Dijital İmza Algoritmasının Eliptik Eğri varyantı tarafından imzalanır. (Hiçbir şeyi doğrudan DH veya ECDH ile şifrelemezsiniz, sadece anahtar veya diğer küçük sırları yaparlar. anlaşması.)

2
dave_thompson_085

SSL kullanmadığınızda, tüm iletişim kolayca ele geçirilebilir - tek yapmanız gereken paket dinleyicisini (Wireshark) başlatmaktır.
SSL, tüm paketlerin şifrelenmesini önler, böylece ne gönderdiğinizi bilmenin bir yolu yoktur. Temel olarak, şifreleri ve özel içeriği ele geçirmeye karşı korumak için kullanılır. Belli ki başka birinin özel e-postalarınızı okumasını istemiyorsunuz, değil mi?
Google aramasına gelince, basitçe insanların istediklerini gizlemek için yaptılar. Çünkü bazı hükümetler bunu çok merak ediyor.

SSL güvenliği nasıl artırır? Kendi başına değil. Bu, şifreleme (SSL anahtarı) ve PKI (Ortak Anahtar Altyapısı) - esas olarak Sertifikaların birleşimidir. Tamam, soru nasıl oldu. Bir tarafta iletişim kanalınızı sabitler (yukarıya bakın), diğer yandan yasal işlerle konuşmanızı sağlar - sunucunun kimliğini doğrular. Kanal güvenli ve güvenilir.

Oldukça az sayıda SSL Sertifikası vardır, çünkü oldukça az sayıda PKI Hizmetleri . Temel olarak farklı hizmetlerin farklı türde SSL Sertifikası gerekir. Dolayısıyla, kod imzalama, e-posta şifreleme ve imzalama, yani sunucu kimlik doğrulaması vb. İle ilgili Sertifikalar vardır.

2
Paweł Dyda

Birisi hizmetimize SSL (https) ile bağlandığında ve doğru kimlik doğrulama verilerini gönderdiğinde, tüm hassas verileri bu hat üzerinden iletmek güvenli midir, yoksa hala gizli dinleme olabilir mi?

Bu zincirdeki zayıf bağlantı neredeyse SSL değildir, ancak genellikle sahte bir ara siteye web sahtekarlığı/köprü sahtekarlığı yoluyla veya geçersiz bir sertifika sunularak ve tarayıcı uyarısını devre dışı bırakarak kandırılabilen kullanıcı yine de bağlayın.

Bununla birlikte, tanımladığınız sistem en iyi yöntemdir, yapabileceğiniz başka bir şey yoktur (kullanıcılarınızı mümkünse SSL uyarılarını ciddiye almak için eğitmenin yanı sıra).

2
frankodwyer

Kısa cevap hayır. Daha uzun cevap: yukarıdaki cevapların bir koleksiyonu artı: Kimlik doğrulamayı çözersek, bu yüzden ortadaki adam, geleneksel SSL bağlantısı ile trafiği listeleyen birisinin, bir gizli sunucu anahtarı edinmeleri halinde daha sonra şifresini çözebilir (düşün NSA ve Ulusal Güvenlik Mektupları). TLS protokolünde, bağlantıyı gizli tutmak için Diffie-Helman protokolünü kullanma seçeneği vardır. Chrome'u kullanarak gmail.com'a erişirken aşağıdaki resme bakın. connection security

ECDHE_ECDSA mesaj kimlik doğrulaması için SHA1 ile RC4_128 metnine bakın. Bu şunu okur:

  1. Sunucu, SHA özeti ile RC4_128b SSL kanalı sundu
  2. Bu tünelin içinde her mesaj, anahtarın Diffie-Helman işlevi kullanılarak türetildiği Ekliptik eğrilerle şifrelenir ve Dijital İmza Algoritması kullanılarak Ekliptik Eğriler şifresi ile imzalanır

Başka bir deyişle, birisinin SSL sunucusunun özel anahtarı olsa bile, iletiler kullanımdan hemen sonra bellekten atılan geçici anahtarlarla şifrelenmiştir. İyi şanslar NSA!

2
Vladimir Jirasek

Kullanıcı için güvenli mi, yoksa sizin için güvenli mi? Ortadaki adam saldırısını varsayalım. Saldırgan kullanıcının trafiğini yakalamayı başarır, kullanıcı gibi davranır ve kullanıcı olarak davranır. Bu tür bir saldırı genellikle başarısız olur, çünkü kullanıcıya verilen sertifika doğru olmaz. Örneğin, saldırgan kullanıcıya web siteniz için kendinden imzalı bir sertifika verir. Ancak, kullanıcı aptalca davranırsa, kendinden imzalı sertifikayı kabul edebilir. Böylece saldırgan, kullanıcı ile sizin arasındaki tüm trafiği okuyabilir ve değiştirebilir ve bildiğim kadarıyla bunu tespit etmenin bir yolu yoktur.

Bu nedenle, trafiğin gizlenmesi ve değiştirilmesi kullanıcıyı incitirse, bu gerçekten kendi hatası ve kendi problemidir. Ve yine de tamamen önleyemezsiniz, çünkü MITM sizi tamamen kesebilir ve sadece kendiniz gibi davranan kullanıcıyla konuşabilir. Ancak, trafiğin gözetlenmesi ve değiştirilmesi sizi incitirse, kullanıcının aptal olmamasına veya kullanıcının kimliğini daha iyi doğrulamamasına güvenmelisiniz (kullanıcının bir sertifikaya ihtiyacı olacaktır ve MITM'in yapamayacağı bir şekilde kontrol edebilirsiniz. sahte).

2
gnasher729

TLS kullanan HTTPS'nin en modern sürümleri bile, istemci CA'ya güvenirse bir MitM (örneğin, bir Juniper aygıtı amaç için yapılandırılmış) tarafından kolayca ele geçirilebilir. Bu durumda güvenli değildir.

1
user3260912

Bence buradaki insanlar soruyu anlamıyor:

Güvenli olmayan bir hattınız varsa ve bu hat üzerinden başarılı bir SSH/SSL Bağlantısı yaparsanız, şimdi hattın "güvenli" olduğunu ve şifrelenmemiş verilerin şifrelenmiş Bağlantı ile HERHANGİ BİR YERDE geçirilebileceği varsayımını yapmanın güvenli olup olmadığını soruyor ( örneğin, düz bir şekilde, şifreli SSL/SSH Bağlantısının içinde değil).

Hayır derdim. Bu durumda, şifrelenmiş verileri görmezden gelen ve şifrelenmemiş verileri kaydeden pasif bir dinleyici olabilir.

ANCAK, hiçbir Aktif kulak misafiri (MITM) olmadığından emin olabilirsiniz, bu da kimliği doğrulanmış hatla aynı kaynak/hedefe sahip, kimliği doğrulanmamış bir SSL/SSH Bağlantısı oluşturabileceğiniz anlamına gelir. Bu, MITM'nin bazı konektörleri seçtiği hiçbir seçici kulak misafiri olmamasına rağmen AMA, kulak misafiri Bağlantıyı doğrulayıp doğrulayamayacağınızı bilemez, bu nedenle hangi MITM'ye Bağlantıdan saptamayacağını bilemez. MITMer, eğer MITM, tüm Bağlantıları MITM yapar ve insanların tüm kimlik doğrulama iletişim kutularını tıklatmasını umar.

Böylece: 123.123.123.123 ile 24.24.24.24 arasında bir SSL hizmetine kimlik doğrulaması bağlarsanız, SSH parmak izini karşılıklı olarak kimlik doğrulaması yapmadan bir SSH istemcisini 123.123.123.123'ten 24.24.24.24'e güvenli bir şekilde bağlayabilirsiniz. diğer tarafın NAT yönlendirici veya güvenlik duvarı.

Ancak bu güvenli anlamına gelse bile, IS bir kulak misafiri sadece rastgele MITM Bağlantıları ve tespit edilmemeyi umma küçük bir risk var, bu yüzden zaten hedef IP'ye doğrulanmış bir Bağlantıya sahip olduğunuz için, neden SSL güvenli bir web sitesine doğru SSH parmak izini göndermek kadar basit!

1