SSL i nieporozumienie typu man-in-the-middle

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)?

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.

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.

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.

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.

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.