Dlaczego niepodpisany certyfikat SSL jest traktowany gorzej niż brak certyfikatu SSL?


19

Jeśli przeglądam witrynę, która ma niepodpisany lub samopodpisany certyfikat SSL, moja przeglądarka wyświetla ostrzeżenie. Jednak ta sama przeglądarka nie ma problemu, umożliwiając wysyłanie poświadczeń między niezabezpieczonymi stronami.

Dlaczego certyfikat z podpisem własnym jest traktowany gorzej niż brak certyfikatu?

Odpowiedzi:


16

Wiele osób uważa, że ​​ten system jest zepsuty.

Oto logika, dlaczego przeglądarka wyświetla tak alarmujące ostrzeżenie, gdy certyfikat SSL jest nieważny:

Jednym z pierwotnych celów projektowych infrastruktury SSL było zapewnienie uwierzytelnienia serwerów internetowych. Zasadniczo, jeśli wejdziesz na stronę www.bank.com, SSL pozwala serwerowi, który odpowiada, udowodnić, że w rzeczywistości należy do twojego banku. To powstrzymuje oszusta przed manipulowaniem DNS lub użyciem innej metody, aby złośliwy serwer odpowiedział.

„Zaufanie” w protokole SSL jest zapewniane przez podpisanie certyfikatu przez zaufaną stronę trzecią (firmy takie jak VeriSign i Thawte Consulting), wskazując, że potwierdzono, że jest własnością tego, kto twierdzi, że jest (teoretycznie, odwiedzając administratora IT w osoba lub inna metoda, która tworzy bezpośrednie zaufanie, chociaż dowody wskazują, że w rzeczywistości są raczej rozluźnieni - wszystko, czego potrzeba, aby uzyskać podpisany certyfikat SSL, to często liczba 800 i trochę umiejętności aktorskie).

Tak więc, jeśli łączysz się z serwerem WWW, który zapewnia certyfikat SSL, ale nie jest podpisany przez zaufaną stronę trzecią, teoretycznie może to oznaczać, że komunikujesz się z oszustem, który udaje serwer należący do innej organizacji .


W praktyce samopodpisany certyfikat ogólnie oznacza po prostu, że organizacja zarządzająca serwerem nie zdecydowała się zapłacić za podpisany certyfikat (mogą być dość drogie, w zależności od potrzebnych funkcji) lub brakowało specjalistycznej wiedzy technicznej, aby je skonfigurować ( niektóre rozwiązania dla małych firm oferują mechanizm jednego kliknięcia dla certyfikatu z podpisem własnym, ale uzyskanie zaufanego certyfikatu wymaga więcej technicznych kroków).

Osobiście uważam, że ten system jest zepsuty, a komunikacja z serwerem nieobsługującym szyfrowania jest znacznie bardziej niebezpieczna niż komunikacja z serwerem oferującym SSL z certyfikatem z podpisem własnym. istnieją trzy powody, dla których przeglądarki tak się nie zachowują:

  1. Nieszyfrowana komunikacja to norma w Internecie, więc jeśli przeglądarki zmuszają użytkownika do kliknięcia ostrzeżenia w celu wyświetlenia stron internetowych nieobsługujących szyfrowania, szybko się zirytujesz i wyłączysz ostrzeżenie.
  2. Z powodu strasznych ostrzeżeń dla klientów, nienormalne jest wyświetlanie samopodpisanego certyfikatu na stronie produkcyjnej. Ustanawia to system samonapędzający się: certyfikaty z podpisem własnym są podejrzane, ponieważ są rzadkie, są rzadkie, ponieważ są podejrzane.
  3. Jest cyniczny brzmiące mnie, ale są firmy, które są gotowe do podjęcia dużo pieniędzy off podpisywania certyfikatów SSL ( kaszel Verisign kaszel ), więc używać whitepapers (o IT termin znaczenie „długi i nudny reklamy”) oraz inne publikacje w celu realizacji idei, że niepodpisane certyfikaty są niebezpieczne.

5
Bez łańcucha zaufania, który otrzymujesz dzięki certyfikatowi podpisanemu przez urząd certyfikacji, a nie samopodpisanemu, nie ma sposobu, aby sprawdzić, czy serwer, z którym się łączysz, jest tym, kto twierdzi, że jest. Certyfikaty z podpisem własnym są niebezpieczne w tym sensie, że nie zapewniają użytkownikom możliwości sprawdzenia, czy przesyłane dane docierają do miejsca docelowego, o którym mówią. Ludzie zaczynają uczyć się szukać „https” podczas wykonywania bezpiecznych transakcji, więc duże ostrzeżenie o nieważnym lub samopodpisanym certyfikacie jest w 100% uzasadnione, ponieważ tracą jedną z głównych zalet protokołu SSL.
MDMarra,

Nie powiedziałbym „zepsuty”. Myślę, że dodatek Firefox Patrol certyfikatu jest znacznie bliższy poprawnej implementacji certyfikatów i zarządzania zaufaniem niż domyślny. Mimo to wartość domyślna jest lepsza niż całkowite ignorowanie sieci zaufania.
Slartibartfast

4
@MarkM - Mam wrażenie, że uwierzytelnianie nie powinno być uważane za główną zaletę protokołu SSL. Nie mam danych, aby mnie poprzeć, ale myślę, że znacznie więcej incydentów związanych z bezpieczeństwem wynika z danych przesyłanych za pomocą niezaszyfrowanych połączeń (na przykład inżynier bezpieczeństwa na Facebooku, którego hasło zostało skradzione - wąchali hasło poza siecią Wi-Fi , ponieważ logowanie do Facebooka nie jest szyfrowane) niż za pośrednictwem MitM lub ataków oszustów, których wdrożenie jest stosunkowo dużo bardziej skomplikowane. Jak zauważyłem, nacisk na uwierzytelnianie zamiast szyfrowania w SSL jest dokładnie tym, co tworzy tę sytuację.
jcrawfordor,

1
@MarkM - chociaż na pewno jest narzut, co jest uzasadnioną obawą, użycie niepodpisanych certyfikatów nie będzie obciążać urzędów certyfikacji, szczególnie dlatego, że urząd certyfikacji nie byłby używany do certyfikatu z podpisem własnym. Ponadto w przypadku organizacji posiadających wystarczającą moc nie stanowi to problemu - weź pod uwagę, że Google domyślnie korzysta z https dla Gmaila i niektórych innych usług. Rozumiem twój punkt widzenia, że ​​bez uwierzytelnienia przydatność protokołu SSL ulega pogorszeniu. Obecny model nie jest dobrze zaprojektowany. To, czego naprawdę potrzebujemy, to standardowy zaszyfrowany protokół i uwierzytelniony protokół do bezpieczniejszych zastosowań.
nhinkle

5
Większe znaczenie mojego punktu, a NRHinkle bezpośrednio to powiedział, polega na tym, że musimy zacząć traktować szyfrowanie i uwierzytelnianie jako odrębne cele i pozwolić na ich realizację oddzielnie. Oto podstawowe wady systemu SSL: 1) Widzimy szyfrowanie i uwierzytelnianie jako nierozerwalnie związane - aby osiągnąć jedno, musisz osiągnąć drugie. Podanie tylko jednego jest „podejrzane”. 2) Uwierzytelnianie należy uzyskać od ograniczonej liczby urzędów certyfikacji głównie dla zysku. Ogólnie rzecz biorąc, CA są albo bardzo drogie (Verisign itp.) Albo bardzo podejrzane (NameCheap itp.)
jcrawfordor

6

Wysyłanie poświadczeń ze strony na stronę zasadniczo wykonuje HTTP POST. Nie ma nic specjalnego w wysyłaniu poświadczeń w porównaniu do wysyłania np. Wyszukiwanych haseł za pomocą POST. Jeśli jakikolwiek post na niezabezpieczonej stronie wywołałby ostrzeżenie, użytkownicy byliby bombardowani niepotrzebnymi ostrzeżeniami.

Korzystanie z bezpiecznego kanału oznacza, że ​​programista zamierza zabezpieczyć transfer. W takim przypadku użycie ostrzeżenia o certyfikacie z podpisem własnym jest bardzo słuszne.


W porządku dla mnie.
dag729,

W rzeczywistości, pragnę przypomnieć, że co najmniej starych wersjach Netscape Navigator nie pojawi się ostrzeżenie dla każdego niezaszyfrowanej POST. Oczywiście wszyscy wyłączyli je po pięciu minutach, więc chyba to
wyjęli

4

Nie mogę komentować, więc opublikuję te informacje, które uzupełniają prawidłowe informacje o użytkowniku 40350.

Jednak ta sama przeglądarka nie ma problemu, umożliwiając wysyłanie poświadczeń między niezabezpieczonymi stronami.

To w rzeczywistości nawet nie jest prawdą. Większość przeglądarek wyświetli ostrzeżenie , jakbyś miał zamiar przesłać dane przez niezabezpieczone połączenie, gdy spróbujesz po raz pierwszy, ale możesz je wyłączyć, aby nigdy się nie wyświetlał, i założę się, że właśnie to zrobiłeś ...

Miro A napisał:

Wysyłanie poświadczeń ze strony na stronę zasadniczo wykonuje HTTP POST. Nie ma nic specjalnego w wysyłaniu poświadczeń w porównaniu do wysyłania np. Wyszukiwanych haseł za pomocą POST

Jest to również niepoprawne, ponieważ pola hasła są na przykład specjalnymi tagami HTML. Ponadto etykiety takie jak „nazwa użytkownika” i „hasło” zdradzają wiele wrażliwości. Przeglądarki biorą pod uwagę tego rodzaju informacje.


3

Połączenia zabezpieczone protokołem https: // są wskazywane przez przeglądarkę jako „zabezpieczone”. Na przykład wyświetlana jest mała kłódka lub części adresu URL są zaznaczone na zielono.

Użytkownik powinien zatem ufać, że strony, które odwiedza, rzeczywiście pochodzą z wpisanego adresu URL i nie pochodzą od kogoś innego.

Jeśli nie używa https: //, użytkownik powinien wiedzieć, że wprowadzone dane nie są chronione, a witryna, na której surfuje, może zostać zaatakowana.

Samopodpisany certyfikat nie gwarantuje - po raz kolejny oczekuje, że strona, do której surfowano, nie jest oszukana, dlatego nie zapewnia dodatkowego bezpieczeństwa.


1

Należy dokonać rozróżnienia między zaufanym (podpisanym przez organ, któremu ufasz) a niezaufanym certyfikatem. W przeciwnym razie ktoś mógłby podszyć się pod Twój bank (na przykład) przy użyciu samopodpisanego certyfikatu ze względną bezkarnością.

W tym przypadku ostrzeżenie bezpośrednie jest lepsze niż subtelne, ponieważ potencjalne ryzyko jest stosunkowo wysokie. Ludzie mogą kliknąć link https i nawet nie myśleć, że ktoś może siedzieć w środku i monitorować połączenie. Jeśli wskazanie, że certyfikat jest niezaufany, jest subtelne (powiedzmy czerwoną zamiast zielonej ikony itp.), Można łatwo oszukać ludzi, usuwając zalety protokołu SSL.


Czy nie jest łatwo podszywać się pod bank, jeśli masz dostęp do komputera użytkownika i modyfikujesz jego certyfikaty? Jeśli komputer użytkownika nie zostanie zmieniony, przeglądarka internetowa nie będzie mogła zmodyfikować adresu URL strony, aby twierdzić, że jest bankiem; a jeśli otrzymają bardzo podobny adres URL, nadal będą mogli uzyskać certyfikat dla tej witryny, a użytkownik nie będzie dbał o to, kto jest stroną podpisaną, po prostu zobaczy, że to https, i mam nadzieję, że zauważy, że adres URL nie jest Adres URL ich banku ...
Dmitry

Zaletą protokołu SSL nie jest zaufanie, że witryna jest tym, za kogo się uważa (jest to niemożliwe, ponieważ aplikacja innej firmy może zmienić twoje certyfikaty lub bank może zostać zhakowany); ale raczej ufaj, że komunikacja między tobą a kimkolwiek w witrynie jest, jest tylko między wami dwojgiem i nikt inny nie może zrozumieć tej komunikacji. Brak certyfikatu jest gorszy niż certyfikat z podpisem własnym, ponieważ nie ma znaczenia, z kim rozmawiasz, ważne jest to, że nikt inny nie powinien być w stanie przechwycić tego, co mówisz.
Dmitry

Poza tym, jako użytkownik, czy naprawdę wiem, kim jest Verisign i dlaczego mam im ufać? Czy ich zainteresowanie sprzedażą certyfikatów nie jest większe niż pociąganie ich do odpowiedzialności za niewłaściwe wykorzystywanie przesyłanych do nich informacji?
Dmitry

0

Wymieniono wiele dobrych powodów. Oto jeszcze jeden:

Pomyśl o przypadkach, w których jedna bezpieczna strona internetowa osadza elementy z drugiej. Osoba atakująca może wykryć, które żądania dotyczą zewnętrznej strony internetowej (powiedzmy, patrząc na czas, musi to być pierwsze), a które dotyczą elementów wewnętrznych. Mógł wstrzykiwać się jako MITM tylko do wewnętrznych elementów, używać samopodpisanego certyfikatu i kontrolować części strony. Jeśli nie zostanie wyświetlone ostrzeżenie dla wewnętrznych elementów korzystających z protokołu SSL, ale nie korzystających z zaufanego certyfikatu, bezpieczeństwo strony zewnętrznej będzie zagrożone.

Oto realistyczny przykład. Powiedzmy, że jestem sprzedawcą i mam link „zapłać za pomocą PayPal”. Kliknij na to i ja wiem. Przekierowuję cię do PayPal i pozwalam ci uzyskać legalną, bezpieczną stronę PayPal. Jeśli obserwuję Twoją sieć, wiem, że będzie to Twoja pierwsza prośba od PayPal, a wkrótce potem prześlesz swoje hasło. Więc MITM submitzawiera Twój adres e-mail i hasło, zastępując mój samopodpisany certyfikat PayPal.

Widzisz, jak zagrożone jest bezpieczeństwo strony zewnętrznej, jeśli nie ostrzegasz, czy certyfikat strony wewnętrznej jest samopodpisany? Musi więc ostrzegać przed samopodpisanymi certyfikatami pochodzącymi z łączy.

I oczywiście, jeśli wprowadzisz httpsręcznie, musi cię ostrzec. Ponieważ oczekujesz, że będzie bezpieczny.


-1

Gdy atak typu man in the middle jest wykonywany na stronie https: //, ostrzeżenie oznacza jedynie coś złego przeciętnemu użytkownikowi. Dlatego jest to bardzo ważna część bezpieczeństwa HTTPS.

Dobrym pytaniem jest to, dlaczego częściowo niebezpieczne szyfrowanie nie jest możliwe w przypadku HTTP.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.