Pytanie:
Czy odwiedzanie witryn HTTPS w publicznym hotspocie jest bezpieczne?
Calmarius
2011-01-09 16:31:42 UTC
view on stackexchange narkive permalink

Często mówi się, że połączenia HTTPS SSL / TLS są szyfrowane i uważane za bezpieczne, ponieważ komunikacja między mną a serwerem jest szyfrowana (zapewnia również uwierzytelnianie serwera), więc jeśli ktoś podsłuchuje moje pakiety, odszyfrowanie będzie wymagało milionów lat jeśli w teorii używasz brutalnej siły.

Załóżmy, że korzystam z publicznej sieci Wi-Fi, a na tej samej sieci Wi-Fi jest złośliwy użytkownik, który podsłuchuje każdy pakiet. Teraz załóżmy, że próbuję uzyskać dostęp do mojego konta Gmail za pomocą tego Wi-Fi. Moja przeglądarka uzgadnia protokół SSL / TLS z serwerem i pobiera klucze do szyfrowania i deszyfrowania.

Jeśli 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 na serwer w moim imieniu?

Myślę, że jest to właściwe, ponieważ zrozumienie zagrożeń związanych z takim środowiskiem leży w gestii specjalistów ds. Bezpieczeństwa. Niektórzy z nas musieli uruchamiać publiczne hotspoty w witrynach korporacyjnych, a niektórzy muszą pracować z różnych lokalizacji - co może obejmować publiczne punkty aktywne.
A co z sslstrip? (http://www.thoughtcrime.org/software/sslstrip/) Zobacz także [ten film] (http://bit.ly/1BylXv) o sslstrip
Aby dodać do poniższych odpowiedzi [zależy to od bezpieczeństwa odwiedzanej witryny] (http://security.stackexchange.com/a/80363/8340) - [zobacz także moje wskazówki] (http: // security .stackexchange.com / a / 44976/8340).
Pamiętaj, że chociaż witryny HTTPS mogą być bezpieczne w tym scenariuszu, jeśli w dowolnym momencie podczas sesji przeglądania witryna HTTP zostanie kiedykolwiek załadowana (nawet w ramce iframe lub osobnej karcie), złośliwy punkt dostępu może to wykorzystać do wykradania plików cookie na _all_ popularnychwitryny inne niż HTTPS (nawet te, których aktualnie nie przeglądasz) i instaluj backdoory dla tych witryn, które utrzymują się nawet wtedy, gdy nie masz już połączenia ze złośliwym hotspotem: https://samy.pl/poisontap/ Więc tak.
Jedenaście odpowiedzi:
waiwai933
2011-01-09 16:51:24 UTC
view on stackexchange narkive permalink

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.
Och, zapomniałem, że mamy asymetryczne systemy szyfrowania.
3. Upewniasz się, że wszystkie Twoje dane faktycznie przechodzą przez HTTPS (niektóre witryny są częściowo zaszyfrowane, a częściowo nie)
Moje lokalne kąpieliska (Hillingdon, Wielka Brytania) zwracają własne certyfikaty, więc w rzeczywistości mają pełny wgląd w to, co wysyłasz, nawet jeśli wyświetla się https.99,9% użytkowników nie zauważyłoby tego.
Pytanie: Czy możesz wyjaśnić, w jaki sposób jakakolwiek odpowiedź z serwera HTTPS mogłaby zostać zaszyfrowana w taki sposób, że ktoś słuchający w środku nie mógł jej zinterpretować?Jedynym kluczem, który ma klient, jest klucz publiczny, który jest również dostępny dla nasłuchującego / hakera.
@JoshG Klient ma również klucz prywatny, o którym tylko on wie.Na tym polega istota szyfrowania asymetrycznego (para kluczy publiczny / prywatny).Aby odszyfrować odpowiedź z serwera, człowiek pośrodku potrzebowałby klucza prywatnego klienta.
AviD
2011-01-11 12:37:30 UTC
view on stackexchange narkive permalink

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.
Wszystkie witryny Google są poddawane edycji HSTS. Lepiej użyć „example.org”.
@Pacerier tak, * teraz *, kiedyś nie było :-) Również ich certyfikaty są w większości przypięte (ponownie mój drugi punkt), więc ... tak. Dzięki!
Alex Howell
2011-01-09 17:11:23 UTC
view on stackexchange narkive permalink

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

O ile wiem, [WPA-PSK nie jest skuteczną obroną przed atakami typu Firesheep] (http://www.kennynet.co.uk/2010/11/26/ubuntu-firesheep-aircrack-and-wpa/ ). Rozumiem, że [aircrack-ng może odszyfrować szyfrowanie WPA-PSK] (http://www.aircrack-ng.org/doku.php?id=airdecap-ng), jeśli przechwycisz początkowy uścisk dłoni, który jest łatwy do zrobić. WPA-PSK [nie jest zabezpieczony przed tego rodzaju atakami] (http://wifinetnews.com/archives/2003/11/weakness_in_passphrase_choice_in_wpa_interface.html) i [zapewnia fałszywe poczucie bezpieczeństwa] (http: //wiki.wireshark. org / HowToDecrypt802.11).
Ta odpowiedź pomija również ryzyko ataków MITM (ataków aktywnych). Obecnie Firesheep nie przeprowadza ataków MITM, ale może, a wtedy może istnieć ryzyko, nawet jeśli witryna korzysta wyłącznie z HTTPS. (np. jeśli nie oznacza swoich plików cookie flagą SECURE).
@D.W., Dzięki - dlatego zasugerowałem przeniesienie pierwotnego pytania z superuser.com do tutaj - to pytanie pochodziło stamtąd, a nie od „ochroniarza”. Przy okazji, kiedy widzisz złe odpowiedzi, szczególnie te, które są wyraźnie NIEPRAWIDŁOWE, powinieneś je zlekceważyć. To pomaga przenieść poprawne odpowiedzi na górę i zatopić niewłaściwe.
Prawdopodobnie warto zauważyć, że nie jest już tak, że „szyfrowanie / deszyfrowanie” wymaga dużej mocy obliczeniowej. Ważne jest, aby nie utrwalać mitu, że obciążenie procesora jest warte rozważenia, gdy myślisz o używaniu protokołu HTTPS we wszystkich częściach witryny. zobacz: https://istlsfastyet.com/
PulpSpy
2011-01-13 05:06:37 UTC
view on stackexchange narkive permalink

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).
RedGrittyBrick
2011-01-09 16:51:55 UTC
view on stackexchange narkive permalink

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.

Nieprawidłowe certyfikaty są problemem we wszystkich typach połączeń - nie tylko w publicznym hotspocie Wi-Fi.
Richard ma rację, nie ma nic specjalnego w publicznych hotspotach Wi-Fi pod względem certyfikatów. Czułem, że warto o tym wspomnieć, bo tam też ma zastosowanie. Nieuczciwy operator hotspotu może przekierować Cię na swój własny serwer internetowy przy użyciu fałszywego certyfikatu.
ale nieprawidłowe certyfikaty i MITM stanowią znacznie większe ryzyko w publicznym Wi-Fi
Rory Alsop
2011-01-09 20:25:06 UTC
view on stackexchange narkive permalink

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

D.W.
2011-01-12 08:02:56 UTC
view on stackexchange narkive permalink

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ą.

tobylane
2011-01-09 16:49:26 UTC
view on stackexchange narkive permalink

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.

TLS jest podatny na MITM
IrqJD
2011-01-09 23:44:02 UTC
view on stackexchange narkive permalink

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.

Arjun sharma
2016-10-24 16:37:08 UTC
view on stackexchange narkive permalink

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
FrostyFire
2017-12-06 07:59:51 UTC
view on stackexchange narkive permalink

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.



To pytanie i odpowiedź zostało automatycznie przetłumaczone z języka angielskiego.Oryginalna treść jest dostępna na stackexchange, za co dziękujemy za licencję cc by-sa 2.0, w ramach której jest rozpowszechniana.
Loading...