Кратко

  • NTS устанавливает личность узла NTS-KE и подтверждает, что ответ NTP относится к ожидающему запросу. Он не удостоверяет точность серверных часов, не устраняет асимметричную задержку, не выбирает между расходящимися источниками и не разрешает скачок системных часов.
  • Объяснимое решение хранит четыре разных доказательства: личность и установление ключей, приём пакета, пригодность и выбор источника, дисциплину часов и исполнение. Одна зелёная отметка «безопасно» скрывает реальную цепочку полномочий.

Два корректных ответа не создают приказ

Начальная сцена — мысленный эксперимент, а не реальный инцидент. Источники A и B показывают действительные сертификаты. Обе сессии NTS-KE завершаются успешно. Серверы передают cookie и ключевой материал. Затем ответы NTP проверяются ключом направления сервер-клиент, возвращают идентификатор незавершённого запроса и не считаются повторами. Однако A предлагает почти нулевую поправку, а B — 800 миллисекунд.

Криптография могла остаться полностью исправной. Один источник мог получить неверное время сверху. Один маршрут мог иметь асимметричную очередь. Корневая дистанция могла выйти за локальный предел. Кандидаты могли не образовать пересечение, поддержанное большинством других источников.

Клиенту всё ещё предстоит решение: выбрать A, принять B при независимом подтверждении, объединить согласованный набор или остаться несинхронизированным. Отказ двигать часы при противоречивых данных — корректный результат.

Точное утверждение NTS

RFC 8915 делит NTS на два протокола. Установление ключей NTS работает поверх TLS. Передача времени использует расширения NTS в пакетах NTP режима клиент-сервер. Личность и ключи определяются сначала, а частые измерения остаются лёгкими.

NTS-KE использует TCP-порт 4460, TLS 1.3 или новее и идентификатор ALPN ntske/1. Сервер может указать последующий узел NTP, согласовать алгоритм аутентифицированного шифрования и выдать набор непрозрачных cookie. Экспортёр TLS создаёт разные ключи для направлений клиент-сервер и сервер-клиент. После закрытия TLS серверу не нужно хранить состояние каждого клиента.

Клиент возвращает состояние в cookie, а также посылает уникальный идентификатор и аутентификатор. Допустимый ответ проверяется ключом сервер-клиент и отражает идентификатор ещё открытого запроса. Новые cookie приходят в защищённом поле, пополняя запас без постоянного состояния на сервере.

NTS доказывает ограниченное утверждение: ответ создала сторона, связанная с ключами, содержимое не изменилось и отвечает реальному запросу. Правильность генератора времени, верхних опор или значения UTC в это утверждение не входит.

IANA регистрирует общие типы Unique Identifier, NTS Cookie, Cookie Placeholder и Authenticator and Encrypted Extension Fields. Реестр обеспечивает общий синтаксис, а не сертифицирует часы.

Личность не равна точности

Сертификат подтверждает личность сервиса NTS-KE, но не проверяет его часы. Cookie восстанавливает параметры аутентификации, но не является свидетельством истинного времени. Уникальный идентификатор связывает запрос и ответ, но не измеряет симметрию пути.

Атака задержки из RFC 8915 показывает границу. Посредник может неодинаково задержать направления, не меняя содержимое и порядок. Все криптографические проверки проходят, а вычисленное смещение оказывается ложным. Манипулируется время прохождения, а не защищённые биты. Предел дистанции ограничивает ущерб; несколько источников или маршрутов помогают, если не имеют общей точки контроля.

Конфиденциальность тоже ограничена. Базовый заголовок NTP остаётся открытым; NTS может шифровать расширения. Доступность — отдельный слой: пакеты можно отбрасывать, а некоторые ответы Kiss-o’-Death не аутентифицированы.

Поэтому сбой NTS-KE не должен автоматически переводить клиента на незащищённый NTP. Иначе атакующий сможет вызвать сбой и снять защиту. Понижение уровня требует явного локального действия.

Уже время запуска содержит политику доверия

Сертификаты X.509 имеют срок действия. Машина обращается к сети из-за сомнений в своих часах, но ей всё равно нужна примерная дата для проверки сертификата службы. Универсального решения этого круга нет.

RFC 8915 упоминает часы с батареей, ручную оценку, последнее сохранённое время и сравнение нескольких источников. Ответ сразу после NTS-KE должен также укладываться в период сертификата. Это границы правдоподобия, а не точный UTC.

До первого аутентифицированного измерения оператор уже выбрал корни доверия, допустимый возраст сохранённого значения, условия исключения для проверки даты и число источников, нужное для коррекции. Если организация не отвечает, за неё отвечают настройки по умолчанию.

После аутентификации начинается выбор

RFC 5905 сохраняет локальную цепочку. Обработка пакетов создаёт измерения; фильтр снижает шум; алгоритм выбора ищет пересечение с поддержкой большинства; кластеризация удаляет выбросы; объединение выдаёт итоговое смещение; дисциплина часов управляет фазой и частотой.

NTS укрепляет вход: подделка и повтор отбрасываются до превращения в измерение. Последующие стадии не исчезают. Аутентифицированный источник может стать falseticker. Корректное криптографически измерение может нарушить предел задержки или дистанции. При нехватке выживших система остаётся несинхронизированной.

Актуальная документация chrony показывает разделение. authdata сообщает способ аутентификации, число установлений ключей, попытки, отрицательные ответы и cookie. Другие отчёты показывают достижимость, согласие и выбор. maxdelay и родственные проверки отбрасывают неподходящие задержки. minsources блокирует обновление до появления достаточного числа выбираемых источников. Опции доверия и обязательности управляют участием защищённых и открытых источников.

NTPsec предлагает собственные настройки сертификатов, клиента, сервера и хранения ключей cookie. Различия показывают, где заканчивается общая совместимость и начинается политика оператора.

Четыре доказательства вместо значка

Доказательство личности хранит имя NTS-KE, цепочку, служебную идентичность, набор доверия и время установления ключей.

Доказательство пакета хранит поколение ключа, идентификатор, состояние cookie, аутентификатор, соответствующий запрос и изменения после повтора или NTS NAK.

Доказательство измерения хранит смещение, задержку, дисперсию, корневую дистанцию, достижимость, историю, пересечение и статус выброса. Здесь подлинный ответ может оказаться непригодным.

Доказательство действия хранит выбранный источник или комбинацию, порог для плавной коррекции или скачка, процесс и прежнее состояние. Это запись власти над машиной.

Фраза «NTS включён» подтверждает применение механизма, но не объясняет, почему часы изменились.

Минимальное общее правило и локальное решение

Minimum Initial Specification Хэна Лу ограничивает общий слой детерминированными правилами совместимости, безопасности и локальной проверки. Поздние решения остаются у участников, запускающих код. Публикация не равна внедрению, а общий синтаксис не создаёт постоянного права командовать.

Так NTS остаётся узким. IETF определяет согласование, ключи, cookie и проверку. IANA регистрирует номера. Удостоверяющий центр участвует в идентификации узла. Никто из них не выбирает источники клиента, максимальную дистанцию, допустимое стартовое время или разрешение изменить системные часы.

Running-Code Primacy добавляет практический тест: независимые системы реализуют и локально проверяют одинаковые свойства. Клиент вправе принять пакет и отвергнуть измерение, доверять личности и запретить скачок. Это разделение — элемент безопасности.

Источники и границы

Разница 800 миллисекунд иллюстративна и не относится к поставщику, дефекту, инциденту или атаке. Зафиксированные источники: