Робоча група Інженерна інженерія (IETF), яка відповідає за розробку Інтернет-протоколів та архітектури, завершив формування RFC для протоколу Network Time Security (NTS) та опублікувала специфікацію, пов’язану з ідентифікатором RFC 8915.
RFC отримав статус "Стандартна пропозиція", після чого розпочнеться робота щодо надання RFC статусу проекту проекту, що фактично означає повну стабілізацію протоколу та врахування всіх зроблених зауважень.
Стандартизація NTS є важливим кроком для підвищення безпеки служб синхронізації часу і захистити користувачів від атак, що імітують сервер NTP, до якого підключається клієнт.
Маніпуляції зловмисниками з встановленням неправильного часу можуть бути використані для порушення безпеки інших чутливих до часу протоколів, таких як TLS. Наприклад, зміна часу може призвести до неправильної інтерпретації даних про дію сертифікатів TLS.
До цього часу NTP і симетричне шифрування каналів зв'язку не гарантували взаємодії клієнта з цільовим пристроєм а не з підробленим сервером NTP, а автентифікація ключів не стала загальнодоступною, оскільки її занадто складно налаштовувати.
Протягом останніх кількох місяців ми бачили багато користувачів нашої служби часу, але дуже мало хто використовує Network Time Security. Це робить комп’ютери вразливими до атак, що імітують сервер, який вони використовують для отримання NTP. Частковою проблемою була відсутність доступних демонів NTP, які підтримували NTS. Ця проблема тепер вирішена: і chrony, і ntpsec підтримують NTS.
НТС використовує елементи інфраструктури з відкритим ключем (PKI) і дозволяє використовувати TLS та автентифіковане шифрування з асоційованими даними (AEAD) для криптографічного захисту зв'язку клієнт-сервер через мережевий протокол часу (NTP).
НТС включає два окремі протоколи: НТС-КЕ (Встановлення ключа NTS для обробки початкової автентифікації та узгодження ключів через TLS) та NTS-EF (Поля розширення NTS, відповідальні за шифрування та автентифікацію сеансу синхронізації часу).
НТС додати різні розширені поля до пакетів NTP і він зберігає всю інформацію про стан лише на стороні клієнта за допомогою механізму передачі файлів cookie. Мережевий порт 4460 призначений для обробки з'єднань NTS.
Час є основою безпеки для багатьох протоколів, таких як TLS, на які ми покладаємось, щоб захистити своє життя в Інтернеті. Без точного часу неможливо визначити, чи закінчився термін дії повноважень чи ні. Відсутність простого у реалізації протоколу безпечного часу стала проблемою для Інтернет-безпеки.
Перші реалізації стандартизованого NTS були запропоновані в нещодавно випущених версіях NTPsec 1.2.0 та Chrony 4.0.
Chrony пропонує окрему реалізацію клієнта та сервера NTP, яка використовується для синхронізації точного часу на різних дистрибутивах Linux, включаючи Fedora, Ubuntu, SUSE / openSUSE та RHEL / CentOS.
NTPsec розробляється під керівництвом Еріка С. Раймонда і є форкою еталонної реалізації протоколу NTPv4 (NTP Classic 4.3.34), орієнтованої на перепроектування кодової бази для підвищення безпеки (очищення застарілого коду, методи запобігання вторгненню та захищені функції) роботи з пам'яттю та ланцюгами).
Без NTS або симетричної автентифікації ключів немає жодних гарантій того, що ваш комп’ютер насправді розмовляє NTP із комп’ютером, яким ви думаєте. Симетричну автентифікацію ключа важко та болісно налаштовувати, але донедавна це був єдиний безпечний та стандартизований механізм автентифікації NTP. NTS використовує роботу, яка надходить у веб-інфраструктуру відкритих ключів, для автентифікації серверів NTP та переконуються, що коли ви налаштовуєте свій комп’ютер на розмову з time.cloudflare.com, це сервер, з якого ваш комп’ютер отримує час.
Якщо ви хочете дізнатися більше про це, ви можете перевірити деталі У наступному посиланні.