«Сверить часы»: что известно о новом протоколе синхронизации времени серверов

    Рассказываем о причинах появления Roughtime и особенностях его работы.



    / Unsplash / Djim Loic

    Зачем нужен новый протокол


    Работа сетей с переменной латентностью основана на протоколах, подобных NTP (Network Time Protocol). Он синхронизирует внутренние часы вычислительных систем. Но с работой NTP связан ряд проблем — последние версии протокола предусматривают возможность аутентификации запросов от сервера, но на практике эту функцию используют редко. Большинство компьютеров безоговорочно доверяет ответу сервера точного времени при настройке системных часов. В результате злоумышленник может провести MITM-атаку и контролировать часы жертвы, нарушив работу криптографических протоколов и получив возможность повлиять на «свежесть» ключей. Также NTP имеет ряд уязвимостей, которые злоумышленники используют для проведения DDoS-атак.

    Инженеры из Бостонского университета совместно с коллегами из Google и Cloudflare представили иной подход для «сверки часов» — Roughtime — протокол с криптографической защитой на базе UDP. В основу технологии легла система установки временных меток для блокчейна, которую еще в 2011 году описал криптограф Бен Лори (Ben Laurie) — основатель Apache Software Foundation и ведущий разработчик OpenSSL. К слову, сам Бен также участвовал в проектировании Roughtime.

    Как он устроен


    Ответ сервера по протоколу Roughtime состоит из трех частей. Первая представляет собой метку времени с числом микросекунд, прошедших с «эпохи Unix». Вторая называется радиус — это погрешность передаваемого значения. Третьей компонентой ответа является одноразовый код (nonce) с цифровой подписью. Значение nonce генерирует клиент при запросе временной метки. Такой подход позволяет убедиться, что передаваемая информация актуальна.


    О других протоколах из нашего блога на Хабре:


    Если по какой-то причине клиент не доверяет полученным данным, он может послать запрос другим серверам. Но в этом случае nonce генерируют путем хеширования ответа, полученного от предыдущего сервера. Так клиент запоминает последовательность, в которой поступают временные метки, и может убедиться в их правильности. При этом он получает возможность выявить скомпрометированные или неправильно настроенные машины — предоставленное ими значение времени будет серьезно отличаться.

    Перспективы протокола


    В марте прошлого года Инженерный совет интернета (IETF) представил черновик спецификации Roughtime. На этой неделе в сети появилась его обновленная версия. В перспективе Roughtime могут сделать полноценным интернет-стандартом и оформить в RFC. Но старший научный сотрудник и криптограф облачного провайдера Cloudflare Ник Салливан (Nick Sullivan) говорит, что Roughtime нельзя считать прямой заменой NTP. У него нет механизмов компенсации латентности в сети, что может создать проблемы при «сверке часов» между двумя удаленными узлами (погрешность будет очень высокой). Трудностей добавляет криптография — в частности, функция SHA512, на реализацию алгоритмов которой тратятся дополнительные вычислительные ресурсы.


    / PD / Free-Photos

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

    Также интерес к технологии выражает компания SpiderOak. Она разрабатывает одноименное программное обеспечение для резервного копирования данных. Roughtime планируют использовать для безопасной передачи сообщений в другом продукте компании — мессенджере Semaphor.

    О чем мы пишем в корпоративном блоге VAS Experts:

    VAS Experts
    Разработчик платформы глубокого анализа трафика

    Комментарии 12

      +3

      Т.е. как бы замена, но и не замена.
      Ясно, что проверить сертификат — точности ± пару секунд хватит, да и хэш посчитать не будет особой проблемы.
      А для точности и так PTP есть.

        +4
        У него нет механизмов компенсации латентности в сети

        А что, по-нормальному нельзя было сделать? Авторов нового стандарта кто-то торопит или они не знают, что скорость света конечна? Зачем выкатывать дефективный стандарт?

          +10

          Следите за руками:


          IETF представил черновик
          … в перспективе Roughtime могут сделать… интернет-стандартом…
          … Инженеры совместно с Google и Cloudflare представили…
          … компания SpiderOak… Roughtime планируют использовать...

          Это — не стандарт. И никто никуда не торопится.
          А вот SM-манагер VAS Experts торопится и очень (после получки в Птн).
          Поэтому легким движением мыша черновик идеи превращается… превращается… превращается…
          в "Что известно о новом протоколе".


          А Вы купились.


          А манагеру респект. С занесением в получку. Следующую. Может быть.

            +5

            Ну нет. Черновик IETF — это всё-таки не статья на хабре и не надпись на заборе. Ключевые вещи должны быть прописаны на этом этапе, хотя бы в главе о решаемых задачах.


            PS Хотя, признаю, что утратил бдительность. Это отсутствие упоминания JSON меня расслабило.

          0
          Интересно, спасибо! Даже не задумывался, что с помощью времени и ntp можно например составить сертификат :)

          Кстати, на головном оборудовании для тв-вещания почти всегда стоят GPS-часы, чтобы не зависеть от сети. Ну и заддосить или вещать неправильное время сложнее :)
            +1
            GPS тоже можно spoof-нуть, но гораздо труднее.
            +1
            Тот же OpenNTPd уже сейчас может получать дату для явной защиты от подмены с доверенных серверов через https man.openbsd.org/ntpd.conf
              +2

              Просто прикрутили бы к NTP цифровую подпись и гугелы пусть лесом идут со своими 'инновационными протоколами'.

                +2
                Она там есть — называется autokey, и хотя её сочли недостаточно безопасной, IETF уже ведется работа над следующей версией — NTS (Network Time Security), а некоторые (Cloudflare в частности) уже даже реализовали.

                В то же время, в корпоративных и сравнительно закрытых сетях вполне можно использовать NTP поверх IPSec (или других VPN), так что проблема несколько надумана, как мне кажется.
                  +2
                  В то же время, в корпоративных и сравнительно закрытых сетях вполне можно использовать NTP поверх IPSec

                  Если аутентификация в IPSec сделана на основе PKI или Kerberos, то получается замкнутый круг, т.к. для её прохождения уже надо иметь синхронизированное время.
                0
                :/ три раза посмотрел на заголовок и прочёл «сверлить часы».

                Наверно, надо отдохнуть.
                  +1
                  Если по какой-то причине клиент не доверяет полученным данным, он может послать запрос другим серверам.
                  И вот тут самое интересное. А где критерии по которым клиент вдруг станет не доверять полученным данным? По сути тот же NTP только в профиль и все зависит от клиента.

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                  Самое читаемое