Dlaczego certyfikat klucza publicznego serwera WWW musi być podpisany przez urząd certyfikacji?


9

Innymi słowy, jakie byłoby ryzyko bezpieczeństwa związane z niepodpisywaniem certyfikatów kluczy publicznych przez podmioty certyfikujące (z perspektywy użytkownika)? Mam na myśli, że dane są nadal szyfrowane ... Co mężczyzna w środku mógłby zrobić z niepodpisanym certyfikatem?


Mogą wygenerować własny certyfikat z dokładnie tymi samymi informacjami. Jak użytkownik rozpoznaje różnicę?
pjc50,

@ pjc50: patrząc na ścieżkę certyfikatu. Nie podpisany certyfikat będzie miał ścieżkę certyfikatu. Jeśli ta ścieżka prowadzi do zaufanego katalogu głównego, certyfikat jest zaufany, w przeciwnym razie nie jest. Możesz oczywiście dodać dodatkowe zaufane katalogi główne (zrobiłem to dla własnego urzędu certyfikacji, dzięki czemu mogę łatwo tworzyć certyfikaty do użytku lokalnego).
Richard

Odpowiedzi:


13

Celem protokołu SSL w połączeniu z HTTP jest nie tylko szyfrowanie ruchu, ale także uwierzytelnianie, kto jest właścicielem strony internetowej, oraz że ktoś był gotów zainwestować czas i pieniądze w udowodnienie autentyczności i własności swojej domeny.

To jak kupowanie relacji, a nie tylko szyfrowanie, a relacja ta buduje lub zakłada pewien poziom zaufania.

Powiedziałem, że zadałem podobne pytanie kilka miesięcy temu, a podstawowa odpowiedź, która wróciła, brzmiała: „SSL to trochę oszustwo”


Myślałem, że certyfikaty SSL zostały wydane dla adresów IP, a nie domen. Dlaczego potrzebujesz różnych certyfikatów dla domen hostowanych pod tym samym adresem IP? Ponadto strona Wikipedii na temat HTTPS wspomina, że ​​można uzyskać certyfikaty za darmo ... Firma CA naprawdę brzmi dla mnie jak oszustwo.
Olivier Lalonde

2
Certyfikaty są wydawane dla domen. Nic nie stoi na przeszkodzie, aby wygenerować samopodpisany certyfikat, po prostu wyświetli się przerażające ostrzeżenie (że ludzie nie będą czytać), ponieważ przeglądarka nie ufa wystawiającemu CA. Problem „wielokrotnego SSL na jednym adresie IP” był wielokrotnie omawiany tutaj. Oto wątek z dobrą odpowiedzią serverfault.com/questions/73162
Zypher 15.01.2010

Dzięki Zypher, wyjąłeś mi słowa z ust :) I certyfikaty dla domen, a nie adresów IP. Mamy trzy adresy IP dla trzech serwerów, które obsługują naszą najcięższą stronę internetową i wszystkie mają załadowany ten sam certyfikat.
Mark Henderson

8

Wyobraź sobie sytuację, w której masz dostarczyć 1 000 000 $ osobie o imieniu John Smith, z którą nigdy się nie spotkałeś lub z którą się nie komunikowałeś. Mówi się, że możesz go spotkać w zatłoczonym miejscu publicznym. Kiedy idziesz się z nim spotkać, musisz mieć sposób, aby upewnić się, że jest on rzeczywiście osobą, której szukasz, a nie jakąś inną przypadkową osobą, która twierdzi, że jest Johnem Smithem. Możesz poprosić o jakiś rządowy dokument tożsamości, wizytówkę. Możesz poprosić osobę, której ufasz, która faktycznie poznała Johna Smitha, o pomoc w zidentyfikowaniu go.

Samopodpisany certyfikat jednoznacznie identyfikuje system, ale nie robi nic, aby udowodnić, że system jest tym, za kogo się podaje. Mogę z łatwością samopodpisać certyfikat i zgłosić się do serverfault.com, google.com lub yourbank.com. Urzędy certyfikacji działają w zasadzie jako strona trzecia, której klient ufa zaufaniu w celu sprawdzenia, czy certyfikat jest rzeczywiście ważny dla nazwy, którą twierdzi witryna.


2

Działalność związana z SSL jest w rzeczywistości trochę oszustwem. Więcej niż trochę, gdy płacisz około 20 pensów za bajt za niektóre interesujące kryptograficznie dane. To, za co płacisz, to za to, z którego urzędu certyfikacji korzystasz do podpisania certyfikatu jednym z ich kluczy prywatnych po udowodnieniu sobie, że rzeczywiście masz prawo do używania nazwy domeny / hosta, dla którego certyfikat jest przeznaczony. Jak mówi Farseeker, jest to relacja zaufania - urząd certyfikacji ufa tobie (po tym, jak cię sprawdził), przeglądarki internetowe na całym świecie ufają urząd certyfikacji (zwykle), a zatem przeglądarki internetowe zaufają twojemu certyfikatowi. I nie zaczynaj mi o rozszerzonej walidacji ...

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.