Czy nawiązane połączenie HTTPS oznacza, że ​​linia jest naprawdę bezpieczna?

Question

view on stackexchange narkive permalink

Z punktu widzenia osoby oferującej aplikację internetową, gdy ktoś łączy się za pomocą protokołu TLS (https) z naszą usługą i przesyła prawidłowe dane uwierzytelniające, czy przesyłanie wszystkich wrażliwych danych przez tę linię jest bezpieczne, czy też może nadal podsłuchujesz?

To pytanie było Pytanie tygodnia dotyczące bezpieczeństwa IT .
Przeczytaj 29 lipca 2011 r. wpis na blogu , aby uzyskać więcej informacji, lub prześlij własne pytanie tygodnia.

Answer 1

view on stackexchange narkive permalink

Ważne jest, aby zrozumieć, co robi SSL, a czego nie, zwłaszcza, że ​​jest to bardzo częste źródło nieporozumień.

• Szyfruje kanał
• Stosuje sprawdzanie integralności
• Zapewnia uwierzytelnianie

Tak więc szybki odpowiedź powinna brzmieć: „tak, przesyłanie wrażliwych danych jest wystarczająco bezpieczne”. Jednak sprawy nie są takie proste.

• Najnowsze wersje SSL - wersja 3 lub jeszcze lepsza: TLS, nawet TLS 1.2, są zdecydowanie lepsze niż poprzednie wersje. Na przykład. SSL 2 był stosunkowo łatwy do MITM (Man in the middle). Więc najpierw zależy to od wersji protokołu.
• Zarówno szyfrowanie kanału, jak i sprawdzanie integralności są konfigurowalne w protokole, tj. możesz wybrać, które algorytmy mają być używane (zestaw szyfrów). Oczywiście, jeśli używasz RSA1024 / SHA512, to znacznie lepiej ... Jednak SSL obsługuje nawet tryb szyfrowania NULL - tj. Nie ma żadnego szyfrowania, po prostu zawijając żądania do tunelu przez protokół SSL. To znaczy brak ochrony. (Jest to konfigurowalne zarówno po stronie klienta, jak i serwera, wybrany zestaw szyfrów jest pierwszym pasującym zestawem zgodnie ze skonfigurowaną kolejnością).
• Uwierzytelnianie w SSL ma dwa tryby: tylko uwierzytelnianie serwera i uwierzytelnianie wzajemne (certyfikaty klienta). W obu przypadkach bezpieczeństwo zapewniane przez certyfikaty kryptograficzne jest zdecydowanie wystarczająco silne, jednak ważność rzeczywistego uwierzytelnienia jest tak dobra, jak sprawdzanie ważności: Czy w ogóle zadajesz sobie trud sprawdzania certyfikatu? Czy zapewniasz jego ważność? Łańcuch zaufania? Kto to wydał? Itd.
• Ten ostatni punkt ponownego uwierzytelnienia jest o wiele łatwiejszy w aplikacjach internetowych , w których klient może z łatwością wyświetlić certyfikat serwera, łatwo wyświetlić ikonę kłódki itp. Z usługami sieciowymi , zwykle musisz dokładniej sprawdzić jego ważność (w zależności od wybranej platformy). Zwróć uwagę, że w tym samym punkcie pojawiło się tak wiele aplikacji mobilnych - nawet jeśli twórca aplikacji pamiętał, aby używać tylko protokołu TLS między telefonem a serwerem, jeśli aplikacja nie weryfikuje jawnie certyfikatów, oznacza to, że TLS jest uszkodzony.
• Chociaż istnieją głównie teoretyczne ataki na kryptografię SSL, z mojego punktu PoV jest nadal wystarczająco silny do prawie wszystkich celów i będzie trwał przez długi czas.
• Co właściwie robi się z danymi na drugim końcu? Na przykład. jeśli są bardzo wrażliwe, a nawet dane karty kredytowej, nie chcesz, aby były przechowywane w pamięci podręcznej przeglądarki ani w historii itp.
• Pliki cookie (a tym samym uwierzytelnianie) mogą być współużytkowane przez bezpieczny kanał SSL i niezabezpieczony kanał HTTP - chyba że wyraźnie oznaczono go atrybutem „bezpieczny”.

Krótsza odpowiedź? Tak, SSL może być wystarczająco bezpieczny, ale (jak w przypadku większości rzeczy) zależy to od tego, jak go używasz. :)

Answer 2

view on stackexchange narkive permalink

Występuje tutaj kilka problemów, z których głównym jest uwierzytelnianie. Obie strony muszą mieć pewność, że rozmawiają z odpowiednią osobą lub instytucją, aby udaremnić ataki typu man-in-the-middle. W końcu ważne jest, abyś używał certyfikatu SSL, któremu ufa przeglądarka użytkownika. W ten sposób przeglądarka użytkownika może być pewna, że ​​naprawdę mówi do właściwej witryny. Po nawiązaniu połączenia możesz mieć pewność, że cały czas rozmawiasz z tym użytkownikiem, a połączenie jest szyfrowane, czyli zabezpieczone przed podsłuchem.

Uwierzytelnianie w drugim kierunku (tj. upewnienie się, że rozmawiasz z rzeczywistym użytkownikiem) jest zwykle obsługiwane poza protokołem SSL na poziomie aplikacji przez np. nazwę użytkownika / hasło, openID lub inną formę kwalifikacje.

Na koniec należy wspomnieć, że podczas uzgadniania połączenia SSL klient i serwer zgadzają się na zestaw szyfrów i klient może udawać, że wykonuje tylko „szyfrowanie zerowe”, tj. , nie szyfruj żadnych danych. Jeśli Twój serwer zgadza się na tę opcję, połączenie korzysta z SSL, ale dane nadal nie są szyfrowane. W praktyce nie stanowi to problemu, ponieważ implementacje serwerów zwykle nie oferują opcji szyfru zerowego.

Answer 3

view on stackexchange narkive permalink

Oprócz tego, co wymienia AviD, SSL jest tylko tak bezpieczny, jak infrastruktura DNS, która skierowała Cię na ten serwer, i wszelkie korporacyjne serwery proxy na ścieżce komunikacyjnej.

Jeśli infrastruktura DNS zostanie zhakowana ( zatruwanie pamięci podręcznej itp.), osoba atakująca może narazić użytkownika na wiele ataków.

Ponadto, jeśli klient korzysta z oprogramowania takiego jak Fiddler lub korporacyjnego serwera proxy, oprogramowanie to może łatwe w rozmowie SSL.

Aby temu zaradzić, spójrz na „wystawcę” certyfikatu SSL. Jeśli połączenie SSL odbywa się przez proxy, wystawcą będzie ten z proxy. Jeśli korzystasz z połączenia bezpośredniego, zobaczysz odpowiedni publicznie zaufany urząd certyfikacji.

[Więcej informacji]

Firmowy serwer proxy HTTPS to coś, co zarządza połączeniem między przeglądarką internetową a serwerem proxy (którego adres IP pojawia się w dziennikach serwera internetowego). W takim przypadku zawartość sieci Web (również hasło HTTPS) jest odszyfrowywana, a następnie ponownie szyfrowana na firmowym serwerze proxy i prezentowana na serwerze.

W zależności od tego, kto zarządza serwerem proxy i jak używane są jego dzienniki, może to być akceptowalne lub złe z Twojej perspektywy.

Aby uzyskać więcej informacji o tym, jak odbywa się przechwytywanie SSL zobacz ten link:

Gdy serwer proxy SSL przechwytuje połączenie SSL, prezentuje emulowany certyfikat serwera przeglądarce klienta. Przeglądarka klienta wysyła wyskakujące okienko bezpieczeństwa do użytkownika końcowego, ponieważ przeglądarka nie ufa wystawcy używanemu przez ProxySG. To wyskakujące okienko nie pojawia się, jeśli certyfikat wystawcy używany przez SSL Proxy jest importowany jako zaufany katalog główny w magazynie certyfikatów przeglądarki klienta.

ProxySG udostępnia wszystkie skonfigurowane certyfikaty do pobrania za pośrednictwem swojej konsoli zarządzania. Możesz poprosić użytkowników końcowych o pobranie certyfikatu wystawcy za pośrednictwem przeglądarki Internet Explorer lub Firefox i zainstalowanie go jako zaufany urząd certyfikacji w wybranej przeglądarce. Eliminuje to wyskakujące okienko certyfikatu dla emulowane certyfikaty ...

Niektóre firmy omijają wspomniany powyżej problem wyskakujących okienek certyfikatów, wdrażając certyfikaty główne (serwera proxy) na każdej stacji roboczej za pośrednictwem GPO. Chociaż wpłynie to tylko na oprogramowanie korzystające z magazynu certyfikatów Microsoft. Oprogramowanie takie jak Firefox i Chrome wymaga innych aktualizacji.

Answer 4

view on stackexchange narkive permalink

Ponieważ SSL opiera się na urzędach certyfikacji (CA) i praktycznie każda organizacja może zostać CA, ataki typu man-in-the-middle z fałszywymi certyfikatami podpisanymi przez CA są zawsze możliwe. Tak więc, chociaż SSL nadal stanowi ogromny postęp w stosunku do braku szyfrowania, jego bezpieczeństwo jest przecenione z powodu zepsutego systemu CA. Pod tym względem certyfikaty z podpisem własnym byłyby tak samo bezpieczne, jak każdy certyfikat podpisany przez urząd certyfikacji, ale przeglądarki oznaczają je jako podejrzane.

Answer 5

view on stackexchange narkive permalink

SSL jest bardzo bezpieczny, chociaż ktoś może ukraść czyjś plik cookie sesji, jeśli uruchomisz DOWOLNĄ stronę w niezaszyfrowanej linii. Gdybyś mógł, uczyniłbym witrynę w całości zgodną z SSL. Lub może wysyłaj plik cookie tylko dla połączeń szyfrowanych i mieć niezabezpieczone strony publiczne, które nie są specyficzne dla tego użytkownika.

Answer 6

view on stackexchange narkive permalink

Nadal istnieje możliwość ataku typu man-in-the-middle, którym w Twoim przypadku byłby użytkownik łączący się z osobą trzecią, która twierdzi, że jest Twoją witryną, a następnie przekazuje żądanie. Oczywiście, doświadczony użytkownik powinien zauważyć brak połączenia SSL lub niewłaściwy certyfikat, ale większość użytkowników nie jest tak włączona i zostaje oszukana przez ikonę ulubionej kłódki.

To nie jest tak naprawdę problem z SSL po prostu coś, o czym należy pamiętać. Możesz spokojnie założyć, że nikt nie jest w stanie podsłuchać połączenia SSL między Twoją witryną a źródłem połączenia. Nie możesz jednak być pewien, że źródłem połączenia jest naprawdę użytkownik.

Answer 7

view on stackexchange narkive permalink

Ponieważ SSL szyfruje transmisję, żadne dane nie mogą zostać podsłuchane (ponieważ certyfikat jest zaufany).

Chociaż problem tkwi w tym, gdzie (i jak bardzo) używasz SSL w swojej aplikacji internetowej: powiedz, na przykład, potrzebujesz połączenia SSL tylko w celu uwierzytelnienia swojego użytkownika (aby umożliwić im wysyłanie zaszyfrowanych par użytkownik / przepustka na twój serwer), to kiedy wysyłasz plik cookie, powinieneś mieć świadomość, że może on być łatwo przechwycony ( Twój użytkownik korzysta z niezabezpieczonego połączenia bezprzewodowego).

Cały ostatni dramat FireSheep dotyczy tego.

Answer 8

view on stackexchange narkive permalink

Nie. Analiza ruchu wciąż może komuś wiele powiedzieć.

Analiza ruchu to proces przechwytywania i sprawdzania wiadomości w celu wyprowadzenia informacji z wzorców komunikacji. Można to wykonać nawet wtedy, gdy wiadomości są zaszyfrowane i nie można ich odszyfrować. Ogólnie rzecz biorąc, im większa liczba wiadomości zaobserwowanych, a nawet przechwyconych i przechowywanych, tym więcej można wywnioskować z ruchu.

---

TLS jest zwykle wdrażany w celu zachowania poufności - atakujący nie powinien osiągać wysokiego poziomu pewności co do treści komunikacji.

Zakładając, że

1. atakujący zna Twój protokół,
2. napastnik zna kto komunikuje się z kim
3. atakujący nie może odszyfrować wiadomości.
4. nie zasłaniasz swojego prawdziwego ruchu dużą ilością bezsensownego ruchu (sieczki)

Atakujący prawdopodobnie może stwierdzić, kiedy jesteś obudzony i kiedy śpisz, niezależnie od protokołu, i może być w stanie powiedzieć dużo więcej w zależności od charakteru protokołu, którego używasz.

---

Jeśli twój protokół jest bardzo prosty:

1. Wysyłasz wiadomość „wystrzel bomby atomowe w ...”, kiedy chcesz wystrzelić broń nuklearną
2. Nie wysyłasz wiadomość, gdy nie chcesz wystrzelić żadnej broni nuklearnej.

Podsłuchiwacz, który nie może odszyfrować twoich danych c określić na podstawie samej obecności wiadomości, że chcesz wystrzelić bomby, ale może nie do kogo.

---

Jeśli twój protokół jest bardziej złożony:

1. Ty poproś o książkę.
2. Przesyłam Ci treść.

Osoba atakująca może nie być w stanie stwierdzić, kto czyta „Wojna i pokój” kontra Atlas wzruszył ramionami ”, ale potrafi rozróżnić, opierając się wyłącznie na rozmiarze wiadomości, czy czytają jedną z 55-stronicowych powieści„ The Metamorphosis ”, w porównaniu z Kafką.

Answer 9

view on stackexchange narkive permalink

SSL wykonuje dwa podstawowe zadania: uwierzytelnianie i szyfrowanie.

Uwierzytelnianie odbywa się za pośrednictwem urzędów certyfikacji (CA). Przeglądarki są dostarczane z listą certyfikatów SSL dla kluczy podpisujących urzędów certyfikacji. Urzędy certyfikacji podpisują certyfikaty, które opisują klucz publiczny jednostki. Na przykład, gdybym był właścicielem Google.com, udowodniłbym to Verisign, a oni podpisaliby mój certyfikat na jakiś czas. Pojawiają się problemy, gdy urzędnik certyfikacji podpisuje certyfikat, którego nie powinien podpisywać. Może się to zdarzyć, gdy ktoś udaje, że jest właścicielem innej domeny, nabywa zbyt szeroki certyfikat z symbolem wieloznacznym lub po prostu XKCD wydał CA coś niecnego (być może rządy?). Widzieliśmy wszystkie powyższe przypadki, ale zdarza się to dość rzadko.

Jeśli certyfikat dla witryny jest prawidłowo podpisany i nie ma fałszywego certyfikatu w łańcuchu zaufania, to gdy łączysz się z możesz (do celów dyskusji) mieć pewność, że certyfikat jest zgodny. W normalnych okolicznościach to połączenie jest szyfrowane. To uniemożliwia komukolwiek odczytanie twoich danych.

Certyfikaty SSL są bardzo złożone i istnieje wiele ataków na implementacje SSL. To, co SSL może skutecznie zrobić, to uniemożliwić mi obserwowanie Twojego ruchu w lokalnej kawiarni Starbucks podczas sprawdzania poczty e-mail w Gmailu. To, czego nie może zrobić, to uniemożliwić mi użycie ataku MITM, w którym przekazuję Ci wszystko bez SSL, a Twój klient nie jest skonfigurowany tak, aby przeszkadzać Ci, że nigdy nie rozpoczął szyfrowanej sesji.

Answer 10

view on stackexchange narkive permalink

Nie licząc różnych odpowiedzi innych osób na temat innych potencjalnych problemów, zakładając, że używasz SSL 3.0 i silnego szyfrowania, powinno być bezpieczne.

Korzystanie ze starszych protokołów ssl (2.0) lub używanie słabego klucza szyfrowania może otworzyć cię na luki w zabezpieczeniach.

Answer 11

view on stackexchange narkive permalink

SSL ogólnie zwiększa bezpieczeństwo, zapewniając:

1. Uwierzytelnianie serwera (użytkownik wie, że rozmawia z „właściwą” witryną)
2. Integralność danych (użytkownik i serwer wiedzieć, że ruch nie jest modyfikowany na trasie)
3. (opcjonalnie, ale zazwyczaj) Prywatność danych (użytkownik i serwer wiedzą, że ruch nie jest przechwytywany na trasie)
4. (opcjonalnie , ale rzadko) Uwierzytelnianie klienta, jeśli klient też ma certyfikat

Zasadniczo istnieją tylko dwa typy certyfikatów SSL: certyfikat serwera (który jest zawsze używany) i certyfikat klienta (który jest opcjonalne).

To tylko szkic i istnieje wiele „jeśli”, „i” oraz „ale”. W najbardziej typowym scenariuszu, SSL opartym na przeglądarce, schemat może w wielu przypadkach zepsuć się bez łamania kryptografii lub protokołu, ale po prostu polegając na tym, że użytkownik zrobi niewłaściwą rzecz (tj. Zignoruje ostrzeżenia przeglądarki i mimo wszystko się połączy). Ataki phishingowe mogą również działać, wysyłając użytkownika do fałszywej witryny chronionej protokołem SSL, przypominającej prawdziwą witrynę pod każdym względem oprócz adresu URL.

Powiedziawszy, że SSL i jego kuzyn TLS są nadal bardzo przydatne, ponieważ przynajmniej pozwalają na bezpieczną komunikację, choć daleką od niezawodności.

Answer 12

view on stackexchange narkive permalink

Kiedy ktoś łączy się z naszą usługą za pomocą protokołu SSL (https) i przesyła prawidłowe dane uwierzytelniające, czy przesyłanie wszystkich poufnych danych przez tę linię jest bezpieczne, czy też nadal istnieje podsłuch?

Słabym ogniwem w tym łańcuchu prawie na pewno nie jest SSL, ale użytkownik, którego zazwyczaj można nakłonić do połączenia się z fałszywą witryną pośredniczącą, albo poprzez spoofing sieciowy / hiperłącza, albo przez przedstawienie nieprawidłowego certyfikatu i odrzucając ostrzeżenie przeglądarki i kontynuując nawiązywanie połączenia mimo wszystko.

Jednak system, który opisujesz, i tak jest najlepszą praktyką, niewiele więcej możesz zrobić (poza edukowaniem użytkowników, aby poważnie traktowali ostrzeżenia SSL, jeśli możesz).

Answer 13

view on stackexchange narkive permalink

Gdy nie używasz SSL, cała komunikacja może być łatwo przechwycona - jedyne, co musisz zrobić, to uruchomić sniffer pakietów (np. Wireshark).
SSL zapobiega temu, wszystkie pakiety są szyfrowane, więc istnieje nie ma sposobu, aby wiedzieć, co wysyłasz. Zasadniczo służy do ochrony haseł i treści prywatnych przed przechwyceniem. Oczywiście nie chcesz, aby ktoś inny czytał Twoje prywatne e-maile, prawda?
Jeśli chodzi o wyszukiwarkę Google, po prostu zrobili to, aby ukryć to, o co ludzie proszą. Dzieje się tak, ponieważ niektóre rządy są po prostu zbyt ciekawe.

Jak SSL zwiększa bezpieczeństwo? Samo to nie działa. Co to jest połączenie szyfrowania (klucz SSL) i PKI (infrastruktura klucza publicznego) - głównie certyfikaty. OK, pytanie brzmiało jak. Z jednej strony zabezpiecza Twój kanał komunikacyjny (patrz wyżej), z drugiej zapewnia, że ​​rozmawiasz z legalną firmą - uwierzytelnia serwer. Kanał jest więc bezpieczny i zaufany.

Istnieje sporo certyfikatów SSL, podobnie jak sporo usług PKI. Zasadniczo różne usługi wymagają innego typu certyfikatu SSL. Są więc certyfikaty do podpisywania kodu, szyfrowania i podpisywania e-maili, te dotyczące np. Uwierzytelniania serwera i tak dalej.

Answer 14

view on stackexchange narkive permalink

Krótka odpowiedź brzmi: nie, dłuższa odpowiedź: zbiór powyższych odpowiedzi oraz: jeśli rozwiążemy problem z uwierzytelnianiem, a więc pośrednim, że przy tradycyjnym połączeniu SSL ktoś, kto nasłuchuje ruchu, może go później odszyfrować, jeśli uzyskali tajny klucz serwera (pomyśl o NSA i National Security Letters). W protokole TLS istnieje opcja użycia protokołu Diffie-Helman w celu zapewnienia poufności połączenia. Zobacz poniższy obrazek, gdy wchodzę na gmail.com przy użyciu przeglądarki Chrome.

Spójrz na tekst RC4_128 z SHA1 dla uwierzytelniania wiadomości ECDHE_ECDSA. To brzmi:

1. Serwer oferowany kanał SSL RC4_128b ze skrótem SHA
2. Wewnątrz tego tunelu każda wiadomość jest szyfrowana za pomocą krzywych ekliptycznych, gdzie klucz jest wyprowadzany za pomocą funkcji Diffiego-Helmana i jest podpisane za pomocą szyfru krzywych ekliptycznych przy użyciu algorytmu podpisu cyfrowego

Innymi słowy, nawet jeśli ktoś ma klucz prywatny serwera SSL, wiadomości zostały zaszyfrowane kluczami tymczasowymi, które są usuwane z pamięci wkrótce potem posługiwać się. Powodzenia w NSA!

Answer 15

view on stackexchange narkive permalink

@Vladimir ma rację, że http://en.wikipedia.org/wiki/Forward_secrecy jest pożądany, ale zawiera błędne szczegóły. Serwer wybrał ten zestaw szyfrów spośród tych oferowanych przez przeglądarkę. „zaszyfrowane za pomocą RC4_128 z SHA1 do uwierzytelniania wiadomości” wykorzystuje 128-bitowe szyfrowanie RC4 i kontrolę integralności HMAC-SHA-1. (Nazwy zestawu szyfrowania w SSL / TLS do niedawna mówią SHA, ale mają na myśli SHA-1, a właściwie HMAC-SHA-1.) „ECDHE_ECDSA jako mechanizm wymiany kluczy” nie dotyczy pojedynczych wiadomości, jest częścią (większości) uścisk dłoni, który występuje raz na początku sesji: ECDHE używa wariantu krzywej eliptycznej Diffiego-Hellmana w trybie efemerycznym (plus kilka dodatkowych kroków, które nie są tutaj ważne), aby utworzyć sesyjne klucze używane do szyfrowania i HMAC ; a wymiana kluczy ECDHE (tylko) jest podpisana przez wariant krzywej eliptycznej algorytmu podpisu cyfrowego. (Nigdy nie możesz niczego zaszyfrować bezpośrednio za pomocą DH lub ECDH, oni robią tylko klucz lub inną małą tajną umowę).

Answer 16

view on stackexchange narkive permalink

Czy jest to bezpieczne dla użytkownika, czy dla Ciebie? Załóżmy, że atak man-in-the-middle. Atakującemu udaje się przechwycić ruch użytkownika, udaje Ciebie wobec użytkownika i podszywa się pod Ciebie. Tego rodzaju atak zwykle kończy się niepowodzeniem, ponieważ certyfikat przekazany użytkownikowi byłby nieprawidłowy. Na przykład osoba atakująca przekazuje użytkownikowi certyfikat z podpisem własnym dla witryny sieci Web. Jeśli jednak użytkownik zachowuje się głupio, może zaakceptować certyfikat z podpisem własnym. Więc teraz osoba atakująca może odczytywać i modyfikować cały ruch między użytkownikiem a tobą, i o ile wiem, nie ma sposobu, abyś to wykrył.

Więc jeśli szpiegowanie i modyfikacja ruchu szkodzi użytkownikowi, to naprawdę jest to jego wina i jego własny problem. I nie możesz temu całkowicie zapobiec, ponieważ MITM może cię całkowicie odciąć i po prostu porozmawiać z użytkownikiem udającym ciebie. Ale jeśli szpiegowanie i modyfikacja ruchu cię boli, musisz ufać, że użytkownik nie jest głupi lub lepiej uwierzytelnić użytkownika (użytkownik potrzebowałby certyfikatu i możesz to sprawdzić w sposób, którego MITM nie może imitacja).

Answer 17

view on stackexchange narkive permalink

Myślę, że ludzie tutaj nie rozumieją pytania:

Jeśli masz niebezpieczną linię i tworzysz udane połączenie SSH / SSL przez tę linię, teraz pyta, czy można bezpiecznie założyć założenie że linia jest „bezpieczna” i że niezaszyfrowane dane mogą być przekazywane RAZEM z zaszyfrowanym połączeniem (np. na widoku, a nie wewnątrz zaszyfrowanego połączenia SSL / SSH).

Powiedziałbym nie. W takim przypadku może istnieć pasywny podsłuchiwacz, który po prostu ignoruje zaszyfrowane dane i zapisuje niezaszyfrowane dane.

ALE możesz być pewien, że nie ma aktywnego podsłuchiwacza (MITM), co oznacza, że ​​możesz bezpiecznie ustanowić nieuwierzytelniony SSL / Połączenie SSH z tym samym źródłem / miejscem docelowym, co uwierzytelniona linia. To zapewnia, że ​​nie ma selektywnego podsłuchiwania, który MITM ma określone złącza, ALE podsłuchujący nie może wiedzieć, czy zamierzasz uwierzytelnić połączenie, czy nie, więc nie może wiedzieć, które połączenie z MITM ma uniknąć wykrycia. MITMer zrobiłby, gdyby miał MITM, MITM wszystkie połączenia i miał nadzieję, że ludzie po prostu klikną wszystkie okna dialogowe uwierzytelniania.

Zatem: Jeśli łączysz się uwierzytelniony z usługą SSL od, powiedzmy, 123.123.123.123 do 24.24.24.24, można również bezpiecznie podłączyć klienta SSH od 123.123.123.123 do 24.24.24.24 bez wzajemnego uwierzytelniania odcisku palca SSH, pod warunkiem, że możesz ufać wszystkiemu za routerem NAT lub zaporą ogniową drugiej strony.

Ale nawet jeśli to ogólnie oznacza bezpieczne , istnieje niewielkie ryzyko, że podsłuchiwacz po prostu losowo połączy MITM i ma nadzieję, że nie zostanie wykryty, więc skoro masz już uwierzytelnione połączenie z docelowym adresem IP, dlaczego nie użyć tego uwierzytelnionego połączenia do wzajemnej weryfikacji odcisku palca SSH? To proste, jak opublikowanie prawidłowego odcisku palca SSH na zabezpieczonej stronie SSL!

Answer 18

view on stackexchange narkive permalink

Nawet najnowocześniejsze wersje HTTPS korzystające z TLS mogą zostać łatwo przechwycone przez MitM (np. urządzenie Juniper skonfigurowane do tego celu), jeśli klient ufa CA. W tym konkretnym przypadku nie jest to bezpieczne.