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