HTTPS jest bezpieczny w publicznych punktach dostępu. Podczas konfigurowania TLS, warstwy zabezpieczeń używanej przez HTTPS, przesyłany jest tylko klucz publiczny i zaszyfrowane wiadomości (i one również są podpisane przez certyfikaty główne). Klient używa klucza publicznego do zaszyfrowania klucza głównego, który następnie serwer odszyfrowuje swoim kluczem prywatnym. Wszystkie dane są szyfrowane za pomocą funkcji wykorzystującej główny sekret i pseudolosowe liczby generowane przez każdą stronę.

W ten sposób

• dane są bezpieczne, ponieważ są podpisane przez główny sekret i liczby pseudolosowe
• główny sekret i liczby pseudolosowe są bezpieczne, ponieważ podczas uzgadniania TLS używa się szyfrowania klucza publicznego i prywatnego
• klucz publiczny-prywatny szyfrowanie jest bezpieczne, ponieważ:
  • klucze prywatne są utrzymywane w tajemnicy
  • szyfrowanie klucza publicznego-prywatnego jest bezużyteczne bez klucza prywatnego
  • klucze publiczne są znane być zgodne z prawem, ponieważ są podpisane przez certyfikaty główne, które zostały dostarczone wraz z komputerem
  • lub zostały przez Ciebie specjalnie autoryzowane (zwróć uwagę na ostrzeżenia przeglądarki!)

Dlatego połączenia i dane HTTPS są bezpieczne, o ile:

1. ufasz certyfikatom dostarczonym z komputerem,
2. dbasz o to, aby autoryzować tylko zaufane certyfikaty.

Krótka odpowiedź: to zależy.

Sam SSL / TLS nie jest bardziej podatny na publiczne połączenie Wi-Fi niż przez „zwykły” Internet. Został zaprojektowany do użytku w kanałach otwartych.

Należy jednak wziąć pod uwagę kilka innych aspektów:

• Często użytkownicy nie przeglądają bezpośrednio witryny HTTPS, zaczynają od witryny HTTP i stamtąd przekierowują . Np. Otwierasz http://example.org/ i klikasz link Email , który przekierowuje Cię do https://mail.example.org/ . Ponieważ oryginalna strona HTTP nie jest zaszyfrowana, ten złośliwy użytkownik może zmodyfikować Twój ruch, powodując, że link Email NIE przekierowuje do HTTPS, ale może gdzieś indziej. Na przykład, jeśli kliknąłeś link Email na stronie głównej example.org, czy zauważysz, że przekierował Cię do http://mail.exxxample.org/ ? (jako przykład). Ty może, ktoś inny nie.
• Jeśli użytkownik przejmie twoje połączenie, ale dostarczy swój własny fałszywy certyfikat SSL zamiast certyfikatu example.org - Twoja przeglądarka będzie pokaż błąd, że certyfikat jest nieprawidłowy. Jednak większość użytkowników po prostu to kliknie, umożliwiając atakującemu przejście do bezpiecznej witryny MITM przez SSL.
• Kolejny aspekt do rozważenia, nie zakładaj, że publiczny hotspot jest bezpiecznie skonfigurowany. Jak to pytanie pokazuje, routery z pw są zbyt powszechne i mogą powodować znacznie więcej szkód, niezależnie od Twojego SSL.

Sesja, która odbywa się całkowicie za pośrednictwem protokołu HTTPS, jest dość bezpieczna, ponieważ wszystkie żądania z przeglądarki i strony przesyłane przez serwer są szyfrowane.

Jednak w przypadku dostępu za pośrednictwem protokołu HTTPS wiele witryn wykonuje tylko krok uwierzytelniania przez HTTPS, a następnie powrót do HTTP na resztę sesji. Zatem samo hasło jest bezpieczne, ale identyfikator sesji używany przez serwer do identyfikacji użytkownika podczas tej sesji jest wyraźnie przesyłany przez przeglądarkę. Zmniejsza to obciążenie serwera internetowego (ponieważ szyfrowanie / deszyfrowanie obciąża procesor), ale sprawia, że ​​witryna jest znacznie mniej bezpieczna. Gmail jest bezpieczny, ponieważ używa HTTPS przez całą sesję, ale Facebook i wiele innych witryn tego nie robi.

W ten sposób narzędzia takie jak Firesheep mogą przejmować konta użytkowników, gdy atakujący udostępnia niezaszyfrowaną sieć bezprzewodową.

Możesz zabezpieczyć się przed tym atakiem, używając VPN do szyfrowania wszystkich danych sesji lub używając tylko sieci, które mają silne szyfrowanie dla poszczególnych użytkowników, takie jak WPA -PSK (WEP używa tego samego klucza dla każdego użytkownika, więc nie zapewnia ochrony przed tym atakiem).

Ponieważ odpowiedzi wydają się być wszędzie (tak, nie, może być, powinno), pozwólcie mi najpierw powtórzyć odpowiedź @ waiwai933: jest bezpieczna.

Mówiąc konkretnie, zapytałeś : "Gdyby ten złośliwy użytkownik węszył wszystkie moje przychodzące i wychodzące pakiety. Czy może obliczyć te same klucze i odczytać również mój zaszyfrowany ruch, a nawet wysłać zaszyfrowane wiadomości do serwera w moim imieniu?" Odpowiedź brzmi: nie i nie. Z przypisem.

Powód, dla którego nie może obliczyć tych samych kluczy, wydaje się paradoksalny i w rzeczywistości był przełomem w kryptografii, kiedy została po raz pierwszy opublikowana przez Diffiego i Hellmana. TLS wykorzystuje protokół wymiany kluczy, taki jak Diffie-Hellman, ale jest bardziej wyrafinowany, aby chronić przed atakami typu man-in-the-middle. Protokół umożliwia dwóm osobom, które nigdy wcześniej nie wymieniły informacji, obliczenie tajnego klucza, którego nikt nie widzi wszystkich wiadomości, nie może obliczyć.

Gdy masz wspólny tajny klucz, możesz go użyć do szyfrowania ruchu. Ponieważ złośliwy użytkownik nie zna klucza, nie może zaszyfrować ruchu, który wygląda tak, jakby pochodził od Ciebie.

Teraz te przypisy.

• Zakładamy, że protokół SSL / TLS jest poprawny. W przypadku większości protokołów kryptograficznych od czasu do czasu są wykrywane i naprawiane błędy. SSL / TLS miał ostatnio błąd (wspomniany w kilku odpowiedziach jako powód, dla którego nie jest bezpieczny), jednak został on tymczasowo obejść i teraz naprawiony (RFC 5746), a poprawka jest w różne etapy wdrażania. (W twoim scenariuszu błąd pozwolił złośliwemu użytkownikowi na wysyłanie pakietów w twoim imieniu, ale nie odczytanie twojego ruchu.) Zawsze jest możliwe, że atakujący wie, jak złamać TLS / SSL z powodu nieopublikowanego błędu w protokole.
• Rzecz oczywista, ale warta powtórzenia: złośliwy użytkownik może zobaczyć Twoje żądanie i wysłać własną odpowiedź, używając własnego certyfikatu. Więc sprawdź certyfikat.
• Być może kolejny oczywisty punkt: możesz być pewien, że protokół SSL / TLS będzie używany na przyszłych stronach tylko wtedy, gdy bieżąca strona korzysta z protokołu HTTPS. Na przykład, jeśli jesteś na stronie HTTP, która chce, abyś się zalogował, iz wcześniejszych doświadczeń wiesz, że kliknięcie przycisku logowania przekieruje Cię do połączenia HTTPS, ta funkcja może zostać usunięta przez aktywnego złośliwego użytkownika w Twojej sieci. Dlatego loguj się tylko na strony, które już korzystają z protokołu HTTPS (chyba że wiesz, jak wykryć, czy strona logowania została zmodyfikowana).

HTTPS jest dość odporny na odszyfrowanie w wyniku podsłuchiwania pakietów. Jednak strona uwierzytelniania serwera zależy od nieco słabej metody dystrybucji certyfikatów CA, a CA niewiele robią w zakresie weryfikacji tożsamości. Kilka lat temu wydano certyfikat firmy Microsoft oszustom. Zobacz artykuł na ten temat Bruce'a Schneiera - w praktyce dla ogólnodostępnych stron internetowych nie mamy nic lepszego.

W praktyce zarówno SSL, jak i TLS mają problemy, ale dotyczą one ataku typu Man In the Middle. Aby zapoznać się z przykładem problemu z renegocjacją TLS MITM, zobacz tutaj

Oczywiście ten atak wymaga, aby osoba atakująca znajdowała się na środku ścieżki komunikacyjnej, co nieco ogranicza zagrożenie :-)

Jeśli obawiasz się bezpiecznego przechodzenia do jakiejś witryny w niezabezpieczonej sieci, najlepsze kroki, jakie możesz podjąć, aby zapewnić bezpieczeństwo, to:

• Upewnij się, że witryna korzysta z protokołu HTTPS , a nie HTTP.

• Upewnij się, że witryna ma ważny certyfikat. Nie klikaj ostrzeżeń. Nie akceptuj nieprawidłowych certyfikatów.

• Użyj HTTPS Everywhere lub Force-TLS, aby upewnić się, że korzystasz z HTTPS (tj. szyfrowane SSL) połączenie ze wszystkim, co jest związane z tą witryną.

Całkowicie w praktyce. Szyfrowanie zaczyna się od osób root ssl (Verisign, Thawte itp.) I dlatego jest odpowiednie dla niezabezpieczonych linii. AFAIK TLS nie ma problemu z atakami man in the middle, tylko słabsze / starsze uściski dłoni, które mają ten problem.

Większość zapomina o aspekcie użytkownika io tym, jak mogą używać tego komputera w hotspocie. Większość ludzi używa podobnych haseł w innych witrynach, może blogować itp. mogą one nie być tak bezpieczne, jak Gmail HTTPS / SSL, z którym możesz się łączyć. Problem, który widzę z punktu widzenia bezpieczeństwa, większość ludzi dostanie się do innych witryn, aby ujawnić program przechwytujący pakiety z wystarczającą ilością informacji, aby uzyskać dostęp do niektórych kont. Najlepiej jest, jak wspomniano, jeśli używasz nieszyfrowanego połączenia bezprzewodowego, miejmy nadzieję, że masz VPN, z którym możesz się później połączyć, co zapewni dodatkową warstwę bezpieczeństwa.

Połączenie jest dość bezpieczne, jeśli chodzi o bezpieczne połączenia (ssl). Pod warunkiem, że jest używany ze świadomością:

• Nie powinno być przekierowań z HTTPS na HTTP
• Niektóre witryny używają HTTP cmd przez strony HTTPS, nie powinno być wszelkie poufne informacje przesyłane przez to
• Słabo skonfigurowane serwery https i przestarzałe przeglądarki są nadal możliwe do wykorzystania nawet przez bezpieczne gniazda

O ile wiemy, odpowiedź na sortowanie jest taka, że ​​jeśli HTTPS jest skonfigurowany poprawnie, jesteś bezpieczny w 99% przypadków. To jest duże, jeśli. To nie jest tak proste, jak samo wyświetlenie HTTPS w przeglądarce. SSL-Strip nadal działa w niektórych bezpiecznych witrynach / przeglądarkach.

Nie zapominajmy, że przed SSL-Strip nikt nie sądził, że takie narzędzie może działać. Cyberbezpieczeństwo to nieustannie zmieniająca się dziedzina i gra typu „whak-a-mole”. W pewnym momencie pojawi się nowy exploit, który pozwoli ci przeprowadzić atak, o którym wspominasz w dowolnej witrynie. Spójrz na „niezniszczalny” standard WPA2. W końcu nie jest tak niezniszczalny. Zostanie załatany, ale nie zrobi wiele dla osób zhakowanych wcześniej.

Obecnie istnieje sposób na odszyfrowanie poprawnie skonfigurowanego ruchu SSL. Wymaga dostępu do CA i wystawienia w pełni zaufanych certyfikatów. Twoja przeglądarka nie wykryje ataku MiTm przy użyciu tego. Dobra wiadomość jest taka, że ​​jest to niezwykle trudne… na razie. Korzystanie z VPN nie gwarantuje bezpieczeństwa, ponieważ sama sieć VPN może być atakującym Mitm.

Zasadniczo wszystko, co jest online, może i w pewnym momencie zostanie zhakowane. Są rzeczy, które możesz zrobić (VPN, zaktualizowana przeglądarka itp.), Aby zminimalizować ryzyko, ale nigdy nie jesteś w 100% bezpieczny. Nie pozwól nikomu powiedzieć inaczej.