HTTP przez port 443 vs HTTPS przez port 80

Jaka jest różnica pomiędzy

http://serverfault.com:443 i /server/:80

Który z nich jest teoretycznie bezpieczniejszy?

http i https odnoszą się do używanego protokołu.

http służy do nieszyfrowanej komunikacji w postaci czystego tekstu, co oznacza, że ​​przesyłane dane mogą zostać przechwycone i odczytane przez człowieka. Pola nazwy użytkownika / hasła mogą na przykład zostać przechwycone i odczytane.

https odnosi się do szyfrowanej komunikacji SSL / TLS. Aby go odczytać, należy go odszyfrować. Zwykle / idealnie tylko punkty końcowe są zdolne do szyfrowania / deszyfrowania danych, chociaż jest to stwierdzenie z zastrzeżeniami ( patrz edycja poniżej ).

Dlatego https można uznać za bezpieczniejszy niż http.

: 80 i: 443 odnoszą się tylko do używanego portu serwera (tzn. Jest to „tylko liczba”) i nie ma żadnego znaczenia w odniesieniu do bezpieczeństwa.

Istnieje jednak silna konwencja wysyłania http przez port 80 i https przez port 443, co sprawia, że ​​kombinacje w pytaniu są nieco niekonwencjonalne. Są one technicznie doskonale użyteczne, o ile punkty końcowe są zgodne i nie ma żadnych obiektów filtrów pośrednich.

Aby odpowiedzieć, http://example.com:443 jest mniej bezpieczny niż https://example.com:80, a różnica jest praktyczna (nawet jeśli można to zrównoważyć na wiele sposobów), a nie tylko teoretyczna.

Możesz łatwo przetestować poprawność tych instrukcji za pomocą serwera WWW i klienta, w którym manipulujesz portem serwera i statusem szyfrowania, jednocześnie przechwytując i porównując każdą sesję z dekoderem protokołu, takim jak wireshark.

[ EDYCJA - zastrzeżenia dotyczące bezpieczeństwa ścieżki klient / serwer ]

To, co w gruncie rzeczy oznacza atak typu man-in-the-middle https, można wykonać w celu podsłuchiwania lub podszywania się. Można tego dokonać jako akt wrogości, życzliwości lub, jak się okazuje, nawet z powodu niewiedzy, w zależności od okoliczności.

Atak może zostać przeprowadzony poprzez wykorzystanie słabości protokołu, takiej jak błąd związany z sercem lub luka Poodle , lub poprzez utworzenie instancji proxy https między klientem a serwerem na ścieżce sieciowej lub bezpośrednio na kliencie .

Wydaje mi się, że wrogie stosowanie nie wymaga wielu wyjaśnień. Dobroczynnym zastosowaniem byłoby na przykład organizacja pośrednicząca w przychodzących połączeniach https do celów logowania / identyfikatorów lub wychodzących połączeniach https w celu filtrowania dozwolonych / odrzuconych aplikacji . Przykładem nieświadomego użycia może być przykład Lenovo Superfish, o którym mowa powyżej, lub ostatnia odmiana Dell tego samego wpadka.

EDYCJA 2

Czy zauważyłeś kiedyś, że świat niesie niespodzianki? W Szwecji wybuchł skandal, w którym trzy organizacje opieki zdrowotnej z powiatu korzystały z tego samego łańcucha dostaw do rejestrowania zdarzeń związanych z opieką zdrowotną za pośrednictwem rozmów telefonicznych pacjentów.

W pewnym sensie pytanie to daje odpowiedź na wielką skalę. Gdyby to był tylko żart, a nie faktyczne wydarzenie ...

Po prostu wkleję dwa fragmenty przetłumaczone z tekstu wiadomości w Computer Sweden :

„Computer Sweden może dziś ujawnić jedną z największych katastrof w historii, jeśli chodzi o bezpieczeństwo pacjentów opieki zdrowotnej i integralność osobistą. Na otwartym serwerze internetowym bez jakiejkolwiek formy ochrony hasłem lub innej metody bezpieczeństwa znaleźliśmy 2,7 ​​miliona nagranych połączeń od pacjentów do opieki zdrowotnej za pośrednictwem doradcy medycznego nr 1177. Połączenia te pochodzą z 2013 r. I zawierają 170 000 godzin wrażliwego głosu nazywaj pliki, które każdy może pobrać i słuchać.

[...]

Połączenia zostały zapisane na serwerze pamięci Voice Integrated Nordics pod adresem IP http://188.92.248.19:443/medicall/ . Port Tcp 443 wskazuje, że ruch został przekazany przez https, ale sesja nie jest szyfrowana.

Nie mogę zdecydować, czy to kolejny przykład ignorancji, czy też widzimy zupełnie nową kategorię. Proszę o radę.