Grupa robocza inżynieria internetowa (IETF), który odpowiada za rozwój protokołów i architektury Internetu, ukończył tworzenie RFC dla protokołu Network Time Security (NTS) i opublikował specyfikację związaną z identyfikatorem RFC 8915.
RFC otrzymał status „Propozycji standardowej”, po czym rozpoczną się prace nad nadaniem RFC statusu projektu standardu, co w rzeczywistości oznacza całkowitą stabilizację protokołu i uwzględnienie wszystkich zgłoszonych uwag.
Standaryzacja NTS to ważny krok w kierunku poprawy bezpieczeństwa usług synchronizacji czasu i chronią użytkowników przed atakami naśladującymi serwer NTP, z którym łączy się klient.
Manipulowanie atakującymi w celu ustawienia niewłaściwego czasu może posłużyć do naruszenia bezpieczeństwa innych protokołów wrażliwych na czas, takich jak TLS. Na przykład zmiana czasu może prowadzić do błędnej interpretacji danych dotyczących ważności certyfikatów TLS.
Do tej pory NTP i symetryczne szyfrowanie kanałów komunikacyjnych nie gwarantowały interakcji klienta z celem a nie ze sfałszowanym serwerem NTP, a uwierzytelnianie klucza nie przeszło do głównego nurtu, ponieważ jest zbyt skomplikowane w konfiguracji.
W ciągu ostatnich kilku miesięcy widzieliśmy wielu użytkowników naszej usługi czasu, ale bardzo niewielu korzysta z Network Time Security. Dzięki temu komputery są podatne na ataki naśladujące serwer, którego używają do uzyskiwania protokołu NTP. Częścią problemu był brak dostępnych demonów NTP obsługujących NTS. Ten problem został rozwiązany: chrony i ntpsec obsługują NTS.
NTS wykorzystuje elementy infrastruktury klucza publicznego (PKI) i umożliwia korzystanie z TLS i uwierzytelnionego szyfrowania z powiązanymi danymi (AEAD) do kryptograficznej ochrony komunikacji klient-serwer za pośrednictwem protokołu Network Time Protocol (NTP).
NTS zawiera dwa oddzielne protokoły: NTS-KES (Ustanowienie klucza NTS do obsługi wstępnego uwierzytelnienia i negocjacji kluczy przez TLS) i NTS-EF (Pola rozszerzeń NTS, odpowiedzialne za szyfrowanie i uwierzytelnianie sesji synchronizacji czasu).
NTS dodaj różne rozszerzone pola do pakietów NTP i przechowuje wszystkie informacje o stanie tylko po stronie klienta za pomocą mechanizmu transmisji plików cookie. Port sieciowy 4460 jest dedykowany do obsługi połączeń NTS.
Czas jest podstawą bezpieczeństwa dla wielu protokołów, takich jak TLS, na których polegamy, aby chronić nasze życie online. Bez dokładnego czasu nie ma możliwości ustalenia, czy poświadczenia wygasły. Brak łatwego do wdrożenia bezpiecznego protokołu czasu był problemem dla bezpieczeństwa w Internecie.
Pierwsze implementacje znormalizowanego NTS zostały zaproponowane w niedawno wydanych wersjach NTPsec 1.2.0 i Chrony 4.0.
Chrony zapewnia oddzielną implementację klienta i serwera NTP, która służy do synchronizacji dokładnego czasu w różnych dystrybucjach Linuksa, w tym Fedora, Ubuntu, SUSE / openSUSE i RHEL / CentOS.
NTPsec jest rozwijany pod kierownictwem Erica S. Raymonda i jest rozwidleniem referencyjnej implementacji protokołu NTPv4 (NTP Classic 4.3.34), skoncentrowanego na przeprojektowaniu bazy kodu w celu poprawy bezpieczeństwa (czyszczenie przestarzałego kodu, metody zapobiegania włamaniom i funkcje chronione) praca z pamięcią i łańcuchami).
Bez NTS lub uwierzytelniania za pomocą klucza symetrycznego nie ma gwarancji, że Twój komputer faktycznie komunikuje się przez protokół NTP z komputerem, o którym myślisz. Uwierzytelnianie za pomocą klucza symetrycznego jest trudne i bolesne w konfiguracji, ale do niedawna było to jedyny bezpieczny i ustandaryzowany mechanizm uwierzytelniania NTP. NTS wykorzystuje pracę, która trafia do internetowej infrastruktury klucza publicznego, do uwierzytelniania serwerów NTP i upewnienia się, że podczas konfigurowania komputera do komunikowania się z time.cloudflare.com, to jest serwer, z którego komputer pobiera czas.
Jeśli chcesz dowiedzieć się więcej na ten temat, możesz sprawdzić szczegóły W poniższym linku.