Urzędy certyfikacji są jednym z pojedynczych najważniejszych kamieni węgielnych dla bezpieczeństwa w Internecie. Władze certyfikatu to ktoś, kto jest zaufany przez wszystkich, na początku, gdy nikt nie ufa nikomu innemu. To jest wtedy zadanie tego urzędu certyfikacji (a.k.a CA), aby zapewnić, że zaufanie jest ustanowione między serwerami i klientami, zanim ustanowią komunikację przez Internet.CA jest ważne nie tylko dla HTTPS używane przez przeglądarki i aplikacje internetowe, ale także dla szyfrowanych wiadomości e-mail, podpisane aktualizacje oprogramowania, VPN, i wiele wiele więcej. Weźmiemy prototypowy przykład HTTPS i dowiemy się o CA, w tym konkretnym kontekście. Chociaż można ekstrapolować wynik do każdego innego pakietu oprogramowania.

Internet jest niezaufanym kanałem komunikacji. Kiedy wysyłasz lub odbierasz informacje ze starej strony HTTP http://www.example.com w swojej przeglądarce, wiele rzeczy może się zdarzyć w połowie drogi do twoich pakietów.

1. Zły aktor może przechwycić komunikację, skopiować dane dla siebie, przed ponownym wysłaniem ich na kanale w kierunku ciebie lub serwera, z którym rozmawiałeś. Bez wiedzy którejkolwiek ze stron, informacje są zagrożone. Musimy zapewnić, że komunikacja jest prywatna.
2. Zły aktor może modyfikować informacje w trakcie ich przesyłania przez kanał. Bob mógłby wysłać wiadomość „x”, ale Alice otrzymałaby „y” od Boba, ponieważ zły aktor przechwycił wiadomość i zmodyfikował ją. Innymi słowy, integralność wiadomości jest zagrożona.
3. Na koniec, i co najważniejsze, musimy zapewnić, że osoba, z którą rozmawiamy jest rzeczywiście tym, za kogo się podaje. Wracając do domeny example.com. Jak możemy się upewnić, że serwer, który nam odpowiedział, jest rzeczywiście prawowitym posiadaczem www.example.com? W każdym punkcie sieci, możesz zostać błędnie przekierowany na inny serwer. DNS gdzieś jest odpowiedzialny za konwersję nazwy domeny, takiej jak www.example.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 mogą być rozwiązane przez szyfrowanie wiadomości przed wysłaniem jej przez Internet do serwera. To znaczy, przechodząc na HTTPS. Jednak ostatni problem, problem tożsamości jest gdzie Urząd Certyfikacji wchodzi do gry.

Inicjowanie szyfrowanych sesji HTTP

Główny problem z szyfrowanej komunikacji przez niezabezpieczony kanał jest „Jak zacząć?”

Bardzo pierwszym krokiem będzie zaangażowanie dwóch stron, przeglądarki i serwera, do wymiany kluczy szyfrowania do wymiany przez niezabezpieczony kanał. Jeśli nie jesteś zaznajomiony z terminem klucze, myśleć o nich jako naprawdę długo losowo generowane hasło, z którym dane zostaną zaszyfrowane przed wysłaniem przez kanał insecure.

Well, jeśli klucze są wysyłane przez kanał insecure, każdy może słuchać na to i naruszyć bezpieczeństwo sesji HTTPS w przyszłości. Ponadto, jak możemy ufać, że klucz wysyłany przez serwer twierdząc, że jest www.example.com jest rzeczywiście rzeczywistym właścicielem tej nazwy domeny? Możemy mieć zaszyfrowaną komunikację ze złośliwą stroną maskującą się jako legalna strona i nie znać różnicy.

Więc, problem zapewnienia tożsamości jest ważny, jeśli chcemy zapewnić bezpieczną wymianę kluczy.

Urzędy certyfikacji

Możesz słyszeć o LetsEncrypt, DigiCert, Comodo i kilku innych usługach, które oferują certyfikaty TLS dla twojej nazwy domeny. Możesz wybrać ten, który pasuje do Twoich potrzeb. Teraz, osoba/organizacja, która jest właścicielem domeny musi w jakiś sposób udowodnić swojemu Urzędowi Certyfikacji, że rzeczywiście ma kontrolę nad domeną. Można to zrobić poprzez stworzenie rekordu DNS z unikalną wartością w nim, jak wymaga tego Urząd Certyfikacji, lub można dodać plik do swojego serwera internetowego, z zawartością określoną przez Urząd Certyfikacji, CA może następnie odczytać ten plik i potwierdzić, że jesteś ważnym właścicielem domeny.

Wtedy negocjujesz certyfikat TLS z CA, a to skutkuje kluczem prywatnym i publicznym certyfikatem TLS wydanym dla twojej domeny. Wiadomości zaszyfrowane przez Twój klucz prywatny mogą być następnie odszyfrowane przez publiczny certyfikat i vice versa. Jest to znane jako szyfrowanie asymetryczne

Przeglądarki klienckie, takie jak Firefox i Chrome (czasami nawet system operacyjny) posiadają wiedzę na temat urzędów certyfikacji. Ta informacja jest zapiekana w przeglądarce / urządzeniu od samego początku (to znaczy, kiedy są one zainstalowane), więc wiedzą, że mogą ufać pewnym CA. Teraz, kiedy próbują połączyć się z www.example.com przez HTTPS i widzą certyfikat wydany przez, powiedzmy DigiCert, przeglądarka może to zweryfikować używając kluczy przechowywanych lokalnie. Właściwie jest jeszcze kilka pośrednich kroków, ale to dobry uproszczony przegląd tego, co się dzieje.

Teraz, gdy certyfikat dostarczony przez www.example.com może być zaufany, jest on używany do negocjowania unikalnego klucza szyfrowania symetrycznego, który jest używany między klientem a serwerem przez pozostałą część ich sesji. W szyfrowaniu symetrycznym, jeden klucz jest używany do szyfrowania jak i deszyfrowania i jest zazwyczaj znacznie szybszy niż jego asymetryczny odpowiednik.

Nuances

Jeśli idea TLS i bezpieczeństwa internetowego przemawia do Ciebie, możesz spojrzeć dalej na ten temat kopiąc w LetsEncrypt i ich wolny TLS CA. Jest o wiele więcej minutiate do tego całego rigmarole niż stwierdzono powyżej.

.