routing szyfrowany

Routing szyfrowany zapewnia, że wiadomość jest przekazywana wyłącznie przez połączenia chronione TLS.

Na czym polega routing szyfrowany

Routing szyfrowany oznacza takie wyznaczanie i realizowanie trasy dla wiadomości, przy którym każdy wymagany odcinek transmisji między nadawcą, serwerem pośredniczącym i odbiorcą korzysta z połączenia zabezpieczonego protokołem TLS. W praktyce urządzenie lub usługa przekazująca wiadomość nie powinna wysłać jej dalej zwykłym, nieszyfrowanym kanałem, jeżeli polityka routingu wymaga ochrony TLS. Dotyczy to przede wszystkim komunikacji między serwerami pocztowymi, ale podobny mechanizm może występować także w innych usługach przekazujących dane przez kolejne węzły sieci.

TLS szyfruje transmisję pomiędzy konkretnymi punktami połączenia. Podczas ustanawiania sesji strony uzgadniają wersję protokołu i zestaw algorytmów, a serwer przedstawia certyfikat, który klient może zweryfikować względem zaufanego urzędu certyfikacji. Po zakończeniu uzgadniania dane przesyłane w ramach sesji są chronione przed odczytem i modyfikacją przez osoby mające dostęp do ruchu sieciowego. Routing szyfrowany nie zmienia samej treści wiadomości ani sposobu wyboru adresata; określa dodatkowy warunek, który musi spełnić połączenie użyte do jej przekazania.

TLS na kolejnych odcinkach trasy

W przypadku poczty elektronicznej wiadomość może być przekazywana przez kilka systemów: klient pocztowy łączy się z serwerem wysyłającym, ten wybiera serwer odbiorcy na podstawie rekordów DNS, a następnie nawiązuje połączenie SMTP z odpowiednim hostem. Szyfrowanie nie jest automatycznie ciągłą osłoną obejmującą całą drogę. Każdy serwer SMTP musi osobno ustanowić bezpieczną sesję z następnym serwerem. Jeżeli pierwszy odcinek używa TLS, a kolejny zostanie zestawiony bez TLS, ochrona obowiązuje tylko do pierwszego węzła.

W protokole SMTP szyfrowanie może zostać uruchomione przez rozszerzenie STARTTLS, które przełącza istniejące połączenie z trybu jawnego na TLS po komendzie STARTTLS. Możliwe jest także użycie osobnego portu przeznaczonego do połączeń szyfrowanych, zależnie od konfiguracji danej usługi. Samo ogłoszenie obsługi STARTTLS przez serwer nie gwarantuje jeszcze bezpiecznego routingu. Nadawca musi sprawdzić, czy drugi serwer rzeczywiście zaakceptował przejście do TLS, czy negocjacja zakończyła się powodzeniem oraz czy dalsza transmisja nie jest kontynuowana po niezaszyfrowanym kanale.

Weryfikacja połączenia i konsekwencje błędów

Tryb wymagający TLS powinien rozróżniać szyfrowanie od uwierzytelnienia serwera. Połączenie może być zaszyfrowane, ale nie zapewniać właściwej weryfikacji tożsamości, jeżeli klient nie sprawdzi certyfikatu, jego terminu ważności, nazwy hosta oraz łańcucha zaufania. Weryfikacja nazwy ma znaczenie, ponieważ certyfikat wystawiony dla jednego serwera nie potwierdza automatycznie tożsamości innego hosta. Błędy certyfikatu, niezgodność nazwy, brak zaufanego urzędu albo wyłączone szyfrowanie powinny być traktowane jako niespełnienie wymogu routingu szyfrowanego.

Jeżeli administrator skonfiguruje przekazywanie wyłącznie przez TLS, system może odrzucić wiadomość, opóźnić jej dostarczenie albo skierować ją do kolejki ponownych prób, zamiast użyć połączenia jawnego. Takie zachowanie jest celowe: rezygnacja z szyfrowania zwiększyłaby ryzyko przechwycenia treści podczas transmisji. Warto odróżnić błąd routingu od problemu z samą wiadomością. Niedostępny serwer, niepoprawny rekord DNS, wygasły certyfikat lub niezgodny port mogą uniemożliwić dostarczenie mimo poprawnego adresu odbiorcy. Informacji o przyczynie należy szukać w logach sesji TLS i SMTP, w tym w kodach odpowiedzi serwera oraz komunikatach dotyczących negocjacji certyfikatu.

Granice ochrony i kontrola konfiguracji

Routing szyfrowany chroni dane podczas przesyłania między uczestnikami sesji, ale nie jest tym samym co szyfrowanie end-to-end. Serwer pośredniczący może otrzymać wiadomość w postaci, w której jest w stanie ją przetworzyć, zapisać lub przekazać dalej. TLS zabezpiecza kanał transportowy, a niekoniecznie zawartość wiadomości po odebraniu jej przez serwer. Z tego powodu przy ocenie ochrony trzeba sprawdzić osobno połączenie klienta z serwerem, połączenia między serwerami oraz sposób przechowywania danych na urządzeniach uczestniczących w routingu.

Kontrola konfiguracji powinna obejmować dozwolone wersje TLS, walidację certyfikatów, reakcję na brak obsługi szyfrowania oraz faktyczne logi połączeń. TLS 1.2 i TLS 1.3 są współczesnymi wersjami protokołu, lecz używanie samej nazwy TLS w konfiguracji nie dowodzi, że każda wiadomość została przekazana szyfrowanym kanałem. Należy potwierdzić, że połączenie zakończyło negocjację TLS, wskazać host docelowy i sprawdzić, czy system nie zastosował awaryjnego przekazania bez szyfrowania. Dopiero taka weryfikacja pozwala stwierdzić, że wymóg przekazywania wiadomości wyłącznie przez połączenia chronione TLS jest rzeczywiście realizowany.