SSL i nieporozumienie typu man-in-the-middle

91

Przeczytałem mnóstwo dokumentacji związanej z tym problemem, ale nadal nie mogę zebrać wszystkich elementów razem, więc chciałbym zadać kilka pytań.

  1. Przede wszystkim opiszę pokrótce procedurę uwierzytelniania, tak jak ją rozumiem, ponieważ mogę się w tym zakresie pomylić: Klient rozpoczyna połączenie, na które serwer odpowiada kombinacją klucza publicznego, metadanych i podpisu cyfrowego zaufany organ. Następnie klient podejmuje decyzję, czy ufa serwerowi, szyfruje jakiś losowy klucz sesji kluczem publicznym i odsyła go. Ten klucz sesji można odszyfrować tylko za pomocą klucza prywatnego przechowywanego na serwerze. Serwer robi to, a następnie rozpoczyna się sesja HTTPS.

  2. Tak więc, jeśli mam rację powyżej, pytanie brzmi, jak atak man-in-the-middle może wystąpić w takim scenariuszu? Chodzi mi o to, że nawet jeśli ktoś przechwyci odpowiedź serwera (np. Www.server.com) kluczem publicznym i ma jakieś środki, aby pomyśleć, że jest on www.server.com, nadal nie byłby w stanie odszyfrować mojego klucza sesji bez klucza prywatnego.

  3. Mówiąc o wzajemnym uwierzytelnianiu, czy chodzi o zaufanie serwera do tożsamości klienta? To znaczy klient może już być pewien, że komunikuje się z odpowiednim serwerem, ale teraz serwer chce się dowiedzieć, kim jest klient, prawda?

  4. I ostatnie pytanie dotyczy alternatywy dla wzajemnego uwierzytelniania. Jeśli w opisanej sytuacji występuję jako klient, co jeśli wyślę login / hasło w nagłówku HTTP po nawiązaniu sesji SSL? Z mojego punktu widzenia ta informacja nie może zostać przechwycona, ponieważ połączenie jest już zabezpieczone i serwer może na nich polegać w celu mojej identyfikacji. Czy się mylę? Jakie są wady takiego podejścia w porównaniu z uwierzytelnianiem wzajemnym (ważne są tylko kwestie bezpieczeństwa, a nie złożoność implementacji)?

Vadim Chekry
źródło

Odpowiedzi:

106

Ataki typu man-in-the-middle na SSL są naprawdę możliwe tylko wtedy, gdy jeden z warunków wstępnych SSL jest zepsuty. Oto kilka przykładów;

  • Klucz serwera został skradziony - oznacza, że ​​osoba atakująca może wyglądać na serwer, a klient nie ma możliwości dowiedzenia się o tym.

  • Klient ufa niewiarygodnemu urzędowi certyfikacji (lub takiemu, któremu ukradziono klucz główny) - ktokolwiek posiada zaufany klucz CA, może wygenerować certyfikat udający serwer, a klient mu ufa. Przy liczbie urzędów certyfikacji istniejących obecnie w przeglądarkach może to stanowić prawdziwy problem. Oznacza to, że certyfikat serwera zmieniłby się na inny ważny, co większość klientów przed tobą ukryje.

  • Klient nie zadaje sobie trudu, aby poprawnie zweryfikować certyfikat na swojej liście zaufanych urzędów certyfikacji - każdy może utworzyć urząd certyfikacji. Bez weryfikacji „Ben's Cars and Certificates” będzie wyglądać tak samo, jak Verisign.

  • Klient został zaatakowany, a fałszywy CA został wstrzyknięty do jego zaufanych uprawnień roota - umożliwia atakującemu wygenerowanie dowolnego certyfikatu, który mu się podoba, a klient mu zaufa. Złośliwe oprogramowanie ma tendencję do na przykład przekierowywania Cię do fałszywych witryn bankowych.

Szczególnie punkt 2 jest raczej nieprzyjemny, nawet jeśli płacisz za wysoce zaufany certyfikat, Twoja witryna nie będzie w żaden sposób zablokowana na tym certyfikacie, musisz ufać wszystkim urzędom certyfikacji w przeglądarce klienta, ponieważ każdy z nich może wygenerować fałszywy certyfikat dla Twoja witryna jest równie ważna. Nie wymaga również dostępu ani do serwera, ani do klienta.

Joachim Isaksson
źródło
4
Istnieją również narzędzia, takie jak sslstrip , które będą próbować w przejrzysty sposób przepisać linki https na linki http.
mpontillo
3
Inną kwestią dotyczącą weryfikacji certyfikatu jest to, że klient musi zweryfikować nazwę hosta. Nie wystarczy sprawdzić, czy certyfikat jest autentyczny, musi być wydany podmiotowi, z którym chcesz porozmawiać (patrz tutaj i tutaj ). Jeśli chodzi o sslstrip, to ostatecznie użytkownik musi sprawdzić, czy chce używać SSL / TLS (chociaż HSTS może pomóc).
Bruno
Czy mógłbym napisać wtyczkę do przeglądarki Chrome (lub jakąkolwiek inną przeglądarkę), która przechwytuje dane, ZANIM przeglądarka je zaszyfruje?
Rosdi Kasim,
Innym powodem jest „nadużycie zaufania”, jak w przypadku TürkTrust.
ceremonia
1
@Remover Niezupełnie ... # 1 to klucz prywatny na serwerze, połączony z prawdziwym kluczem publicznym. W tym scenariuszu rozmawiałbyś z prawdziwym serwerem, ale ktoś inny mógłby odszyfrować ruch, będąc w środku. Nie mogą modyfikować certyfikatu. # 2 polega na wysłaniu zupełnie innego certyfikatu, wydanego przez „zaufany” ośrodek certyfikacji, który będzie wydawał się klientowi autentyczny. Osoba atakująca może następnie wysyłać żądania proxy w Twoim imieniu i wyświetlać w ten sposób wiadomości. Oba skutkują kompromisem, ale numer 1 jest pod twoją kontrolą. # 2 niestety tak nie jest.
Podstawowy
17

Przede wszystkim opiszę pokrótce procedurę uwierzytelniania, jak ją rozumiem, może się mylę na tym etapie. Tak więc klient nawiązuje połączenie, a serwer odpowiada na nie kombinacją klucza publicznego, niektórych metadanych i podpisu cyfrowego zaufanego organu.

Serwer odpowiada za pomocą łańcucha certyfikatów X.509 i podpisu cyfrowego podpisanego własnym kluczem prywatnym.

Następnie klient podejmuje decyzję, czy ufa serwerowi

Poprawny.

szyfruje losowy klucz sesji za pomocą klucza publicznego i odsyła go z powrotem.

Nie. Klient i serwer uczestniczą we wspólnym procesie generowania klucza sesji, w wyniku czego sam klucz sesji nigdy nie jest w ogóle przesyłany.

Ten klucz sesji można odszyfrować tylko za pomocą klucza prywatnego przechowywanego na serwerze.

Nie.

Serwer to robi

Nie.

a następnie rozpoczyna się sesja HTTPS.

Rozpoczyna się sesja TLS / SSL , ale najpierw trzeba wykonać więcej kroków.

Tak więc, jeśli mam rację powyżej, pytanie brzmi, jak może wystąpić atak man-in-the-middle w takim scenariuszu?

Udając serwer i działając jako punkt końcowy SSL. Klient musiałby pominąć każdy krok autoryzacji. Niestety jedynym krokiem autoryzacji w większości sesji HTTPS jest sprawdzenie nazwy hosta.

Chodzi mi o to, że nawet jeśli ktoś przechwyci odpowiedź serwera (np. Www.server.com) kluczem publicznym, a potem za pomocą jakichś środków pozwól mi pomyśleć, że jest on www.server.com, nadal nie byłby w stanie odszyfrować mojego klucza sesji bez klucza prywatnego.

Patrz wyżej. Nie ma klucza sesji do odszyfrowania. Samo połączenie SSL jest bezpieczne, to z kim rozmawiasz może nie być bezpieczne.

Mówiąc o wzajemnym uwierzytelnianiu, czy chodzi o zaufanie serwera do tożsamości klienta? Chodzi mi o to, że klient może już być pewien, że komunikuje się z odpowiednim serwerem, ale teraz serwer chce się dowiedzieć, kto jest klientem, prawda?

Poprawny.

I ostatnie pytanie dotyczy alternatywy dla wzajemnego uwierzytelniania. Jeśli w opisanej sytuacji występuję jako klient, co jeśli wyślę login / hasło w nagłówku HTTP po nawiązaniu sesji SSL? Jak widzę, ta informacja nie może zostać przechwycona, ponieważ połączenie jest już zabezpieczone, a serwer może na nich polegać w celu mojej identyfikacji. Czy się mylę?

Nie.

Jakie są wady takiego podejścia w porównaniu z uwierzytelnianiem wzajemnym (ważne są tylko kwestie bezpieczeństwa, a nie złożoność implementacji)?

Jest tak bezpieczne, jak nazwa użytkownika / hasło, które są o wiele łatwiejsze do wycieku niż klucz prywatny.

Markiz Lorne
źródło
Dziękuję za wyjaśnienie. Jedyne, czego nie dostałem, to dlaczego powiedziałeś, że klient nie wysyła klucza sesji do serwera? Cóż, może użyłem złej terminologii, tutaj ta część danych nazywa się "pre-master secret", ale czy nie jest wysyłana przez klienta i jest odszyfrowywana kluczem prywatnym serwera?
Vadim Chekry
1
@VadimChekry Sekret wstępny nie jest kluczem sesji. Jest to jeden z kilku elementów danych używanych do generowania klucza sesji, niezależnie na obu końcach. Proces jest opisany w RFC 2246.
Marquis of Lorne,
1
@Chris Jesteś znacznie mniej podatny na ataki, jednak możliwe jest fałszowanie adresu IP. Nic nie zastąpi samodzielnego sprawdzenia tożsamości peera w certyfikacie.
Markiz Lorne
1
+1 W większości przypadków jest to całkiem dobra odpowiedź. Jednak niektóre punkty nie są wyjaśnione za pomocą jednowyrazowych odpowiedzi. Mógłbyś udzielić ostatecznej odpowiedzi, gdybyś poszerzył i / lub rozwinął wspomniane punkty (tj. Zamiast „nie”, mógłbyś pokrótce wspomnieć, co faktycznie się dzieje) w części głównej. To naprawdę wyjaśniłoby kilka rzeczy. Dzięki.
głosy
1
@ tjt263 Pierwsze „nie” wyjaśnia, co naprawdę się dzieje. Następne dwa „nie” odnoszą się do tego samego błędnego przekonania, które spowodowało pierwsze „nie”, i mają to samo wyjaśnienie. Kolejne i ostatnie „nie” odnosi się do „czy się mylę” i odnosi się do informacji przytoczonych właśnie z PO. Dlatego trudno jest zrozumieć, czego według ciebie faktycznie brakuje.
Markiz Lorne
17

Każdy, kto znajduje się na drodze między klientem a serwerem, może przeprowadzić atak typu man in the middle na https. Jeśli uważasz, że jest to mało prawdopodobne lub rzadkie, weź pod uwagę, że istnieją produkty komercyjne, które systematycznie odszyfrowują, skanują i ponownie szyfrują cały ruch SSL przez bramę internetową. Działają na zasadzie wysyłania klientowi certyfikatu ssl utworzonego w locie ze szczegółami skopiowanymi z „prawdziwego” certyfikatu ssl, ale podpisanego przy użyciu innego łańcucha certyfikatów. Jeśli ten łańcuch zakończy się z którymkolwiek z zaufanych urzędów certyfikacji przeglądarki, ten MITM będzie niewidoczny dla użytkownika. Produkty te są sprzedawane głównie firmom w celu „zabezpieczania” (policyjnych) sieci korporacyjnych i powinny być używane za wiedzą i zgodą użytkowników. Jednak z technicznego punktu widzenia nic nie stoi na przeszkodzie, aby usługodawcy internetowi lub inni operatorzy sieciowi mogli ich używać. (Można bezpiecznie założyć, że NSA ma co najmniej jeden zaufany klucz podpisywania głównego urzędu certyfikacji ).

Jeśli udostępniasz stronę, możesz dołączyć nagłówek HTTP wskazujący, jakim kluczem publicznym ma być podpisana strona. Może to pomóc w ostrzeżeniu użytkowników MITM o ich „bezpiecznym” połączeniu, ale jest to technika polegająca na zaufaniu przy pierwszym użyciu. Jeśli Bob nie ma jeszcze rekordu „prawdziwego” klucza publicznego, Mallory po prostu przepisuje nagłówek pkp w dokumencie. Lista stron internetowych korzystających z tej technologii (HPKP) jest przygnębiająco krótka. Obejmuje Google i Dropbox na swoim koncie. Zazwyczaj brama przechwytująca https będzie przechodzić przez strony z kilku dużych zaufanych witryn, które używają HPKP. Jeśli zobaczysz błąd HPKP, gdy się tego nie spodziewasz, bądź ostrożny.

Jeśli chodzi o hasła, wszystko w połączeniu https jest zabezpieczone przez https, z wyjątkiem nazwy domeny, która musi być wyraźna, aby żądanie mogło zostać skierowane. Ogólnie rzecz biorąc, nie zaleca się umieszczania haseł w ciągu zapytania, gdzie mogą kręcić się w dziennikach, zakładkach itp. Ale ciąg zapytania nie jest widoczny, dopóki https nie zostanie naruszony.

bbsimonbb
źródło
Ale to oznacza, że ​​ten sprzęt MITM (ten, który odszyfrowuje / skanuje i ponownie szyfruje ruch) musi mieć dostęp do jednego z zaufanych urzędów certyfikacji, prawda? (aby „sfałszować” certyfikat serwera). Powiedzmy, że to się dzieje. Wtedy ktoś to rozwala, informacja staje się publiczna, w presecie będzie skandal i certyfikat CA zostanie usunięty ze wszystkich przeglądarek, prawda? To znaczy idealnie ...
jazzcat
2
Nie? Nie. „Inspekcja SSL” na bramie wymaga tworzenia i podpisywania certyfikatów w locie, ale nie wymaga do tego certyfikatu głównego. Ma jakiś pośredni certyfikat, który ma łańcuch. To, czy katalog główny łańcucha jest zaufany w przeglądarce, określa, czy zostanie wyświetlony błąd certyfikatu. W pracy zostaliśmy poproszeni o zainstalowanie certyfikatu głównego fortinet, aby nasze przeglądarki nie wyświetlały błędów certyfikatów. Ale jeśli łańcuch zakończył się już zaufanym certyfikatem, jest przezroczysty.
bbsimonbb
Kolega z pracy w ograniczonym stopniu rozumiał, dlaczego te techniki MITM w sieci korporacyjnej są złym pomysłem dla Google, aby wymusić SSL - czy rzeczywiście może mieć odrobinę poprawności?
EmSixTeen
1
Przepraszam, nie rozumiem pytania!
bbsimonbb
2
  1. Poprawny
  2. Nie tak dobrze. W tego rodzaju ataku serwer itermediate otrzymuje Twoje żądanie i wysyła je do miejsca docelowego w Twoim imieniu. a następnie odpowiedz z wynikiem. W rzeczywistości jest to serwer pośredni, który zapewnia bezpieczne połączenie z tobą, a nie prawdziwy serwer, z którym chcesz się komunikować. dlatego MUSISZ zawsze sprawdzić, czy certyfikat jest ważny i zaufany.
  3. może być poprawne
  4. Jeśli jesteś pewien, że zabezpieczone połączenie jest zaufane, możesz bezpiecznie wysłać nazwę użytkownika / hasło.
Boynux
źródło
Około 2 - zakładam, że klient dokładnie sprawdza metadane przesyłane przez serwer podczas procedury nawiązywania połączenia i nie ufa WSZYSTKIM certyfikatom. Czy więc taki scenariusz nie byłby możliwy, gdyby: a) klient nie robił tego, co powiedziałem powyżej, lub b) pośrednik miał gdzieś certyfikat podpisany przez zaufany CA?
Vadim Chekry
1
Bardzo rzadko zdarza się, że serwer pośredniczący wysyła ważny certyfikat, w zeszłym roku zdarzyło się to z Comodo CA, jeśli dobrze pamiętam. Ale normalnie, jeśli jest to zaufane połączenie, jest całkowicie bezpieczne.
Boynux
1

Wszystko, co powiedziałeś, jest poprawne, z wyjątkiem części dotyczącej klucza sesji. Celem CA jest pokonanie ataku typu man-in-the-middle - wszystko inne jest wykonywane przez sam SSL. Uwierzytelnianie klienta jest alternatywą dla schematu nazwy użytkownika i hasła.

David Schwartz
źródło