Władze certyfikatów są jedną z najważniejszych kamieni węgielnych bezpieczeństwa Internetu. Urząd certyfikatu to ktoś, kto jest zaufany przez wszystkich, na początku, gdy nikt nie ufa nikomu. Jest to zatem zadanie tego organu certyfikatów (a.k.CA) w celu zapewnienia, że ​​zaufanie zostanie ustanowione między serwerami a klientami przed ustanowieniem komunikacji przez Internet.CA jest ważna nie tylko dla HTTPS używanych przez przeglądarki i aplikacje internetowe, ale także dla zaszyfrowanych wiadomości e -mail, podpisanych aktualizacji oprogramowania, VPN i wiele więcej. W tym konkretnym kontekście weźmiemy prototypowy przykład HTTPS i dowiemy się o CA. Chociaż możesz ekstrapolować wynik do dowolnego innego pakietu oprogramowania.

Problemy z HTTP i prostym tekstem

Internet jest niezaufanym kanałem komunikacji. Po wysyłaniu lub odbieraniu informacji ze starej witryny HTTP http: //www.przykład.com W Twojej przeglądarce wiele rzeczy może się zdarzyć w połowie twoich pakietów.

1. Zły aktor może przechwycić komunikację, skopiować dane dla siebie, zanim ponownie wyznaczy je na kanale w kierunku ciebie lub serwerze, z którym rozmawiałeś. Bez znajomości żadnej ze stron informacje są zagrożone. Musimy upewnić się, że komunikacja jest prywatny.
2. Zły aktor może zmodyfikować informacje, ponieważ są wysyłane przez kanał. Bob mógł wysłać wiadomość "X" Ale Alice otrzymałaby „Y” od Boba, ponieważ zły aktor przechwycił wiadomość i zmodyfikował go. Innymi słowy, uczciwość wiadomości jest zagrożone.
3. Wreszcie, a co najważniejsze, musimy upewnić się, że osoba, z którą rozmawiamy. Wracając do przykład.com domena. Jak możemy upewnić się, że serwer, który nam odpowiedział, jest rzeczywiście prawowitym posiadaczem www.przykład.com? W dowolnym momencie swojej sieci możesz być błędnie skierowany do innego serwera. Gdzieś DNS jest odpowiedzialny za przekształcenie nazwy domeny, takiej jak www.przykład.com, na adres IP w publicznym Internecie. Ale Twoja przeglądarka nie ma możliwości sprawdzenia, czy DNS przetłumaczył adres IP.

Pierwsze dwa problemy można rozwiązać poprzez szyfrowanie wiadomości, zanim zostanie wysłana przez Internet na serwer. To znaczy, przechodząc na HTTPS. Jednak ostatnim problemem, problem tożsamości jest miejsce, w którym wchodzi władza certyfikatów.

Inicjowanie zaszyfrowanych sesji HTTP

Głównym problemem związanym z zaszyfrowaną komunikacją przez niepewny kanał brzmi: „Jak go zacząć?"

Pierwszy krok dotyczyłby dwóch stron, Twojej przeglądarki i serwera, aby wymienić klucze szyfrowania, które mają być wymieniane przez kanał niepewny. Jeśli nie znasz terminu klawisze, pomyśl o nich jak o naprawdę długim losowo generowanym hasło, z którymi dane będą szyfrowane przed wysłaniem kanału niepewnego.

Cóż, jeśli klucze są wysyłane przez niepewny kanał, każdy może tego słuchać i zagrozić bezpieczeństwu sesji HTTPS w przyszłości. Ponadto, w jaki sposób możemy ufać, że klucz wysyłany przez serwer, który twierdzi, że jest www.przykład.com jest rzeczywiście właścicielem tej nazwy domeny? Możemy mieć zaszyfrowaną komunikację z złośliwą imprezą udającą jako legalną stronę i nie znać różnicy.

Problem zapewnienia tożsamości jest ważny, jeśli chcemy zapewnić bezpieczną wymianę kluczów.

Władze certyfikatów

Być może słyszałeś o LetsEncrypt, DigiCert, Comodo i kilku innych usługach, które oferują certyfikaty TLS dla nazwy domeny. Możesz wybrać ten, który pasuje do Twojej potrzeby. Teraz osoba/organizacja, która jest właścicielem domeny, musi w jakiś sposób udowodnić swoją władzę certyfikacyjną, że rzeczywiście mają kontrolę nad domeną. Można tego dokonać przez utworzenie rekordu DNS z unikalną wartością, zgodnie z żądaniem Urzędu Świadectwa, lub możesz dodać plik do swojego serwera WWW, z zawartością określoną przez Urząd Certyfikatu, CA może następnie odczytać ten plik i potwierdź, że jesteś ważnym właścicielem domeny.

Następnie negocjujesz certyfikat TLS z CA, a to skutkuje kluczowym kluczem i publicznym certyfikatem TLS wydanym dla Twojej domeny. Wiadomości szyfrowane przez Twój klucz prywatny mogą być następnie odszyfrowane przez Public Cert i odwrotnie. Jest to znane jako asymetryczne szyfrowanie

Przeglądarki klientów, takie jak Firefox i Chrome (czasem nawet system operacyjny) mają wiedzę o organach certyfikatów. Ta informacja jest od samego początku upieczona w przeglądarce/urządzeniu (to znaczy, gdy są zainstalowane), aby wiedzieli, że mogą zaufać niektórym CAS. Teraz, kiedy próbują połączyć się z www.przykład.com przez HTTPS i zobacz certyfikat wydany przez, powiedzmy DigiCert, przeglądarka może faktycznie sprawdzić, czy za pomocą klawiszy przechowywanych lokalnie. W rzeczywistości jest do tego kilka kolejnych kroków, ale jest to dobry uproszczony przegląd tego, co się dzieje.

Teraz, gdy certyfikat dostarczany przez www.przykład.Com można zaufać, służy to do negocjacji unikalnego symetrycznego klucza szyfrowania, który jest używany między klientem a serwerem na pozostałą sesję. W szyfrowaniu symetrycznym jeden klucz służy do szyfrowania, a także deszyfrowania i jest zwykle znacznie szybszy niż jego asymetryczny odpowiednik.

Niuanse

Jeśli pomysł TLS i Bezpieczeństwo Internetu przemówi do Ciebie, możesz przyjrzeć się temu tematowi, kopiąc w LetsEncrypt i ich bezpłatne TLS CA. W całej prążceniu jest o wiele bardziej drobiazg.

Inne zasoby, które mogę polecić, aby dowiedzieć się więcej o TLS, to blog Troy Hunt i praca wykonana przez EFF jak HTTPS na całym świecie i certyfikat. Wszystkie zasoby są bezpłatne do dostępu i naprawdę tanie do wdrożenia (wystarczy zapłacić za rejestrację nazwy domeny i opłaty godzinowe VPS) i zdobyć doświadczenie.