Pytanie:
Ręczne dodawanie „s” do „http”
pnp
2012-10-12 18:53:00 UTC
view on stackexchange narkive permalink

Zrobiłem przechwycenie mojego loginu przez Wireshark na stronie internetowej opartej na drupalu. Witryna nie używa https. I tak, całkiem oczywiście, udało mi się przechwycić moją nazwę użytkownika i hasło w postaci zwykłego tekstu, po prostu używając filtru http.request.method == POST w Wireshark.

Następnie próbowałem uzyskać dostęp do tej samej strony internetowej, ręcznie dodając s do http w adresie URL. Całkiem naturalnie moja przeglądarka pokazała to:

enter image description here

Następnie wykonałem swoje logowanie ponownie i ponownie przechwyciłem Wireshark.

Ku mojemu zaskoczeniu nie mam żadnych zrzutów odpowiadających filtrowi http.request.method == POST .

A więc moje pytania:

  1. Dlaczego tak naprawdę nie używam protokołu HTTPS, dlaczego nie mogę zapisać identyfikatora logowania i hasła w postaci zwykłego tekstu?

  2. Jaki efekt przyniosło ręczne dodanie s do http ?

AilibjtzhtCMT Istnieje?
Przepraszam, mój błąd. Wygląda na to, że minęło zbyt wiele czasu, odkąd używałem wireshark :(
Cztery odpowiedzi:
Iszi
2012-10-12 20:09:23 UTC
view on stackexchange narkive permalink

Wbrew temu, co myślisz, w rzeczywistości używałeś protokołu HTTPS. Jest to być może nadmierne uproszczenie, ale mniej więcej to, co się stało:

Po wejściu na stronę internetową z protokołem http: // na pasku adresu, skutecznie Powiedział swojemu komputerowi „Utwórz żądanie dotyczące tej strony internetowej z tego serwera i wyślij to żądanie do portu 80 na serwerze”. Jeśli serwer jest skonfigurowany do zezwalania na dostęp przez zwykły HTTP (najwyraźniej był), serwer odpowie, a Twoja sesja (o ile nie zostanie przekierowana) będzie kontynuowana przez HTTP.

Zmieniając protokół na https: // , zamiast tego skierowałeś swój komputer do próby uzgadniania SSL / TLS przez port 443 na serwerze, a następnie wysłał żądania HTTP przez ten tunel. Oczywiście to zadziałało lub nie byłbyś w stanie uzyskać dostępu do strony. Ponieważ połączenie SSL / TLS powiodło się, oznaczało to, że wszystkie kolejne żądania HTTP wysyłane przez ten tunel były zabezpieczone przed przypadkowym podsłuchiwaniem (np. Przez Wireshark).

Ale teraz zapytaj, co z tym okropnym czerwony ukośnik https i znak „x” na kłódce? Wskaźniki te nie oznaczają, że połączenie SSL / TLS nie powiodło się lub że komunikacja z witryną nie jest szyfrowana. Wszystkie te negatywne wskaźniki oznaczają, że witryna nie jest podpisana przez organ uznawany przez Twoją przeglądarkę. Dzieje się tak często w przypadku interfejsów internetowych na urządzeniach sieciowych SOHO, aplikacjach biznesowych lub witrynach internetowych, w których administrator zdecydował się użyć certyfikatu z podpisem własnym zamiast kupować go od uznanego organu (np. VeriSign).

Pod pewnymi względami jest to analogiczne do sprzedaży alkoholu w jurysdykcji, w której obowiązuje ograniczenie wiekowe. Ponieważ nie znam wszystkich zawiłości praw obowiązujących w świecie rzeczywistym, powiedzmy na potrzeby argumentacji, że prawo tylko posuwa się do stwierdzenia, że ​​sprzedaż alkoholu osobie, która jest młodszy niż określony wiek. To, czego prawo w tym hipotetycznym przypadku nie określa , to czy masz obowiązek sprawdzić dowód tożsamości. przed sprzedażą lub jakie formy dowodu osobistego są uważane za ważne dokumenty potwierdzające wiek w momencie sprzedaży. Autorytatywny dowód wieku kupującego jest ostatecznie wymagany w sądzie tylko wtedy, gdy legalność sprzedaży zostanie kiedykolwiek zakwestionowana. Jednak dla bezpieczeństwa nadal dobrym pomysłem jest sprawdzanie identyfikatorów przy każdej sprzedaży.

Tutaj jesteś sprzedawcą w sklepie wielobranżowym w doskonałym stanie Comodo. Większość twoich klientów to koledzy Comodoans, więc naturalnie będziesz w stanie łatwo rozpoznać i zweryfikować ich identyfikatory wydane przez rząd Comodo.

Jednak pewnego dnia otrzymasz klienta z odległego stanu VeriSign. Co teraz robisz? Na szczęście w Twoim sklepie jest książka o nazwie Trusted Root Certificates, która zawiera zdjęcia i wskazówki, jak weryfikować dokumenty tożsamości wydane w różnych stanach w Twoim kraju. Sprawdzasz książkę, porównujesz identyfikator klienta. do odpowiedniego zdjęcia i notatek i ocenić, że identyfikator I.D. jest rzeczywiście wydany przez organ zaufany w Twoim sklepie. Biorąc to pod uwagę, możesz teraz ufać, że informacje zawarte w ID. (w szczególności podając tożsamość i wiek klienta) jest dokładna i dlatego nie obawiaj się, wiedząc, że dokonujesz legalnej sprzedaży.

Innego dnia klient przyjeżdża z zagranicy. Nazywa się Drupal i pochodzi z krainy DigiNotar. Mówi, że jest na tyle dorosły, by kupować alkohol, a jego identyfikator DigiNotarian Government ID. zgadza się z jego stwierdzeniem. Jednak w Twojej książce Zaufane certyfikaty główne nie ma żadnych informacji, które pomogłyby Ci zweryfikować dowód tożsamości. ze swojego kraju. Co tutaj robisz?

Ściśle mówiąc, zgodnie z literą prawa w tym hipotetycznym kraju, Twoja sprzedaż byłaby nadal legalna, gdyby klient faktycznie był tak stary, jak mówi. Możesz założyć, że mówi prawdę, a jeśli rzeczywiście tak jest, kontynuuj swoje życie, nigdy nie będąc skazanym za jakiekolwiek przestępstwo związane z tym działaniem.

Ale bez dokumentów od organu zdaj sobie sprawę, wciąż ryzykujesz, że nie mówi prawdy. Bardzo możliwe, że nie jest w odpowiednim wieku, pomimo tego, co on i jego dowód osobisty. może żądać. W takim przypadku sprzedaż nadal będzie zakończona. Produkt nadal będzie przekazywany tylko między Tobą a Twoim klientem (nie będzie dostępny od razu dla nikogo innego, chyba że Twój klient zdecyduje się go dystrybuować), ale teraz problem polega na tym, że alkohol został przekazany komuś, kto zgodnie z prawem nie powinien go mieć - i możesz mieć przez to kłopoty.


TL; DR: tak długo, jak Twoja przeglądarka wyświetla jako protokół https: // , możesz mieć pewność, że dane w Twojej komunikacji są zabezpieczone między Twoim komputerem i jakiś punkt końcowy. Jeśli jednak wokół tego obszaru https: // są jakieś znaki ostrzegawcze, oznacza to, że przeglądarka nie ufa temu punktowi końcowemu za to, za co się podaje. To od Ciebie zależy, czy Ty ufasz oświadczeniom punktu końcowego o tożsamości wystarczającej do przesłania poufnych danych przez połączenie. Połączenie jest nadal bezpieczne w tym sensie, że nikt między tobą a drugim końcem połączenia HTTPS nie może podsłuchiwać danych, ale ryzykujesz, że drugi koniec nie jest tym, za kogo się podaje.


AKTUALIZACJA: Niektóre przeglądarki zaczynają teraz włączać kontrolę mechanizmów szyfrowania i innych właściwości połączenia HTTPS i odpowiednio ostrzegać. W takich przypadkach powyższe nadal ma zastosowanie, ale należy mieć świadomość, że podsłuchiwaczowi lub pośrednikowi będzie łatwiej złamać to zabezpieczenie, niż gdyby witryna używała silniejszych protokołów szyfrowania.

Pamiętaj, że możesz również uzyskać bezpłatne certyfikaty, kupowanie certyfikatu od firmy takiej jak Verisign nie jest konieczne, aby certyfikat był zaufany. Administrator systemu albo o tym nie wie, albo go to nie obchodzi.
* „Dopóki Twoja przeglądarka wyświetla jako protokół https: //, możesz mieć pewność, że dane w Twojej komunikacji są zabezpieczone między Twoim komputerem a jakimś punktem końcowym. *” - Nieprawda. Jeśli https jest przekreślony z powodu mieszanej zawartości, nie masz żadnej pewności. (W każdym razie nie jest jasne, co oznaczałoby stwierdzenie, że istnieje pewność, że komunikacja jest zabezpieczona na „jakimś punkcie końcowym”, podczas gdy ten punkt końcowy może być atakującym. Zapewnienie to całkiem bez znaczenia. Nie ma żadnego użytecznego sensu „połączenie jest nadal bezpieczne”).
@D.W. To, że komunikacja może być wysyłana do atakującego, jest * dokładnie * tym, co mówiłem, konkretnie frazując to do * jakiegoś punktu końcowego *. Pytanie zadane tutaj nie dotyczy tego, czy transmisja zmierza we właściwe miejsce. Chodzi o to, czy jest zaszyfrowany, czy nie.
@D.W. Istnieje również analogia do sprzedaży alkoholu, która ma znaczenie w przypadku treści mieszanych: jeśli grupa osób wchodzi razem do sklepu, a zwłaszcza jeśli wszyscy wydają się uczestniczyć w podejmowaniu decyzji o zakupie, każdemu z nich przypisujesz kartę i nie sprzedajesz, chyba że wszyscy mają dobry dowód.
Uwielbiam analogię do sprzedaży alkoholu! To absolutnie genialne. Będę musiał to zapisać, żeby móc go wykopać w odpowiednim momencie w przyszłości. Dziękuję Ci!
Analogia do sprzedaży alkoholu jest niesamowita! Po prostu powiedz trochę więcej na ten temat, jeśli chcesz - „_strony internetowe, w których administrator zdecydował się użyć certyfikatu z podpisem własnym _...”.
@pnp Oznacza to, że certyfikat SSL na stronie internetowej jest podpisany (uwierzytelniony) przez samego właściciela strony - zwykle tym samym certyfikatem. Ściśle mówiąc, nie ma w tym nic złego, o ile ufasz właścicielowi witryny i masz sposób na zweryfikowanie certyfikatu podpisującego (tj .: uwierzytelniona kopia klucza publicznego). Jednak przeglądarki zazwyczaj wyświetlają na nich błąd podpisu, ponieważ certyfikat nie jest podpisany przez uznany urząd, który został już skonfigurowany w magazynie zaufanych certyfikatów głównych.
W przypadku hostingu współdzielonego wydaje się dość powszechne, że żądanie HTTPS odpowiada za pomocą certyfikatu wystawionego na „snakeoil.dom” podpisanego przez ośrodek Snake Oil CA. O dziwo, przeglądarki nie ufają temu (nie tylko dlatego, że nazwa domeny nie pasuje), ale połączenie jest nadal szyfrowane.
@TRiG Jeśli przeglądarka jej nie ufa, powinien zostać zgłoszony błąd. Po ominięciu błędu przez użytkownika połączenie zostanie oczywiście zaszyfrowane. Tak powinno się stać. Główny urząd certyfikacji to tylko lista certyfikatów, którym przeglądarka ufa domyślnie - użytkownik może nadal ufać wszystkim, co znajduje się poza tą listą.
@Iszi. Przepraszam, może powinienem był umieścić to słowo * dziwnie * kursywą.
@TRiG Co w tym dziwnego? Czy olej z węża jest w sklepie Trusted Root CA Twojej przeglądarki? Jeśli nie (jak się spodziewam), to wcale nie jest dziwne.
@Iszi. Całkiem. To nie jest dziwne. W ogóle. W ogóle. Wiem to. I spodziewałbym się, że wszyscy inni to wiedzą. Więc ... czuję, że nie tłumaczę się dobrze.
@TRiG W takim razie zgubiłem się - mówisz, że jest w tym coś jeszcze dziwnego, czy też twój komentarz o tym, że jest dziwny, miał na myśli wyłącznie sarkazm?
pozwól nam [kontynuować tę dyskusję na czacie] (http://chat.stackexchange.com/rooms/6366/discussion-between-trig-and-iszi)
Jedna opinia na temat analogii do alkoholu. Jeśli dobrze rozumiem odpowiedzi, przeglądarka jest sklepem, a serwer jest klientem. Byłoby łatwiej, gdyby był przykład z przeglądarką jako klientem.
@Manoj Być może, ale wtedy analogia całkowicie się załamuje. W większości sytuacji (jeśli nie we wszystkich) klienci nie są prawnie zobowiązani do weryfikowania czegokolwiek na temat sklepów, w których kupują towary. Dlatego nie miałoby sensu, aby klient prosił sklep o jakikolwiek dowód tożsamości lub pozwolenie na sprzedaż, nie mówiąc już o oczekiwaniu, że klient będzie miał przez cały czas jakiś dokument weryfikacyjny analogiczny do zaufanych certyfikatów głównych.
Istnieją inne możliwe przyczyny przekreślenia na czerwono, np. Zła nazwa serwera lub wygasły certyfikat.
@musiKk „Zła nazwa serwera” jest nieco bardziej oczywistym powodem odrzucenia identyfikatora w podanej analogii. „Wygasły certyfikat” może mniej, ale nadal jest to problem znany każdemu, kto wcześniej sprzedawał materiały z ograniczeniami wiekowymi. Pewnego razu musiałem odmówić zakupu alkoholu w 21. urodziny klienta, ponieważ jego dowód tożsamości stracił ważność tego samego dnia. Pytanie tutaj nie dotyczy tylko tego, w jaki sposób certyfikaty są weryfikowane lub mogą być nieważne (chociaż sporo się nad tym zastanawiałem), ale dotyczy tego, jak HTTPS będzie nadal działał nawet z nieprawidłowymi certyfikatami.
@Iszi No cóż, szczerze mówiąc nie czytałem twojej analogii. Analogia prowadzi tylko do tego stopnia i zwykle rodzi więcej pytań niż odpowiedzi. Mój komentarz odnosi się tylko do (małej) części technicznej.
ewanm89
2012-10-12 19:12:34 UTC
view on stackexchange narkive permalink

Negocjujesz protokół ssl / tls, w przeciwnym razie otrzymasz odmowę połączenia („Ups! Google Chrome nie może połączyć się z ...”) lub błąd przekroczenia limitu czasu połączenia („Ta strona internetowa jest niedostępna Google Chrome nie może załadować strony internetowej ponieważ ... odpowiedź zajęła zbyt dużo czasu. ”) lub wreszcie błąd protokołu SSL („ błąd połączenia SSL ”).

Negocjujesz protokół SSL / tls i szyfrujesz połączenie, ale certyfikat serwera nie jest zaufany (ponieważ nie wie, że klucz należy do serwera) i dlatego połączenie nie może być zaufane, więc Google Chrome oznacza to jako takie za pomocą krzyżyka na zamku i ukośnika przez https: // i tak masz stronę „ten certyfikat nie jest zaufany” i kliknąłeś przycisk „mimo to kontynuuj”.

Luc
2012-10-12 19:22:16 UTC
view on stackexchange narkive permalink

Twoja przeglądarka wykreśla https i zmienia kolor na czerwony, ponieważ nie można zweryfikować serwera. Możesz rozmawiać zarówno z serwerem atakującego, jak i własnym, ponieważ nie masz zaufanego certyfikatu.

Jednak brak weryfikacji serwera nie oznacza, że ​​nie szyfruje połączenia. Cały ruch jest nadal szyfrowany, tylko przeglądarka nie może upewnić się, że „hasło” wysłane do niej przez serwer (czyli „klucz publiczny”) pochodzi rzeczywiście z Twojego serwera. Gdy spróbujesz użyć https, a przeglądarka nie może ustawić zaszyfrowanego kanału, po prostu odrzuciłaby połączenie, dając jeden z wymienionych błędów @ ewanm89.

Więc Wireshark nie ma pojęcia, co się dzieje to połączenie https. Ponieważ jest to port 443, Wireshark może odgadnąć, że jest to zaszyfrowany ruch HTTP, ale tak naprawdę nie może tego stwierdzić.

Aby dowiedzieć się więcej o SSL (technice stojącej za https), zobacz to pytanie: Jak działa SSL / TLS?

D.W.
2012-10-12 20:45:41 UTC
view on stackexchange narkive permalink

Najbardziej prawdopodobnym wyjaśnieniem jest to, że certyfikat serwera nie jest podpisany przez urząd certyfikacji („niezaufany”), jak powiedzieli inni.

Istnieje jednak inne potencjalne wyjaśnienie: możliwe, że wynikać z „zawartości mieszanej”. Jeśli masz stronę HTTPS, która zawiera JavaScript (lub prawdopodobnie obrazy) ze źródła HTTP, to przeglądarka nadal będzie wyświetlać tę stronę, ale odmówi zaufania stronie jako bezpiecznej i wskaże problem w jakiś sposób, na przykład przekreślając https w pasku adresu. Dzieje się tak, ponieważ podczas korzystania z „treści mieszanej” dochodzi do wielu ataków, więc takie strony naprawdę nie powinny być traktowane tak samo, jak strona korzystająca wyłącznie z protokołu HTTPS (wykorzystanie zasobów HTTP skutecznie osłabia ochronę zapewnianą przez HTTPS).

Wyświetli szary https z żółtą ikoną ostrzeżenia przy mieszanej zawartości. Ale tak, wydaje mi się, że ludzie niezwiązani z technologią nie wiedzieliby i nie zadawaliby tego samego pytania, co teraz.
Sprawdziłem warunki błędów chrome zaraz po zobaczeniu zrzutu ekranu przed napisaniem mojej odpowiedzi.
Chociaż zawartość mieszana nie jest moim przypadkiem (ponieważ wiem, do czego uzyskiwałem dostęp), Twoja odpowiedź dodaje wartości z innego punktu widzenia, na który inni nie mają większego wpływu. +1. Dzięki


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 3.0, w ramach której jest rozpowszechniana.
Loading...