Обновления на сервере tls13.1d.pw, который предназначен для тестирования реализаций TLS версии 1.3 и сопутствующих технологий:

1) появилась поддержка ротации (обновления) симметричных ключей сессии. Речь про механизм Key Update, который в TLS применяется для того, чтобы узлы могли перейти на новые ключи внутри уже установленной сессии. Новое поколение ключей вычисляется на основе данных предыдущего поколения. Есть два варианта схемы обновления: на новые ключи либо переходит только один узел, либо оба узла. Для управления обновлением служит TLS-сообщение KeyUpdate. Сервер tls13.1d.pw поддерживает инициированное клиентом обновление (в двух вариантах – с обновлением серверных ключей и без оного), а также, с вероятностью примерно 1/3, может сам передать сообщение KeyUpdate, соответствующее замене серверных ключей (и заменить ключи);

2) теперь сервер перемешивает на своей стороне приоритеты шифронаборов при каждом соединении. Это означает, что могут быть выбраны разные шифры для разных соединений, но для одних и тех же настроек на стороне клиента. В предыдущих версиях приоритеты были зафиксированы, а наивысшее значение имел шифронабор CHACHA20_POLY1305_SHA256. Поэтому, если в качестве клиента выступал, например, браузер Chrome со стандартными настройками, то всегда согласовывался шифронабор с CHACHA20. При этом сервер поддерживает ещё AES в вариантах с 128- и 256-битным ключом. Теперь AES тоже будет иногда выбираться и для клиентов, у которых есть CHACHA20 (естественно, клиент должен заявить поддержку AES);

3) в части, реализующей элементарный веб-сервер, появилась чуть более развитая поддержка URL и кодов статуса HTTP. Теперь сервер различает адреса документов и даже умеет отдавать разные файлы при обращении по разным адресам. Это последнее новшество позволило добавить передачу файла стилей (CSS) и сделать некоторое минимальное оформление страницы результатов (но, собственно, эта часть обновлений не имеет отношения к TLS).

Что касается KeyUpdate, то здесь поддержка браузерами имеет некоторые ограничения: инициировать ротацию ключей на стороне браузера пользователь не может, однако успешная замена серверных симметричных ключей будет отражена на странице результата – там дописывается сообщение о такой замене (интересно, что если браузер на своей стороне ключ не поменял, то расшифровать данные страницы окажется невозможно и пользователь так или иначе не увидит сообщения об успешной ротации ключей). При желании, посмотреть на то, как работает KeyUpdate, можно с помощью утилиты s_client из OpenSSL (нужна современная версия): в s_client есть специальные интерактивные команды ‘k’ и ‘K’ (строчная и заглавная буквы), которые позволяют отправить KeyUpdate с флагами двух видов – замена ключей только одним узлом (k) или обоими узлами (клиентом и сервером).

Описание возможностей сервера есть в отдельной записке.



Комментировать »

ESNI – это технология, предотвращающая утечку имени сервера при установлении TLS-соединения. Технология пока находится в фактическом статусе эксперимента, но ещё нет RFC, а только черновик (draft). Поддержка ESNI (в версии черновика) уже более года есть на веб-серверах Cloudflare и в браузере Firefox (в основной ветке). Также, около года назад, я реализовал ESNI на тестовом сервере TLS 1.3 – https://tls13.1d.pw/. (Кстати, мой тестовый сервер – один из очень немногих серверов, поддерживающих ESNI, но не принадлежащих при этом Cloudflare.)

За год RFC для ESNI не появилось, но прогресс в разработке есть. Например, ESNI, судя по всему, получит собственный тип ресурсной записи DNS – сейчас ESNI-данные публикуются в DNS-записях типа TXT. Размещение в TXT создаёт некоторые проблемы, поскольку нередко доменные зоны настроены таким образом, что отдают TXT-записи произвольного содержания на запросы для всех имён внутри этих зон (это неверная, но распространённая практика). Кроме того, у тех администраторов, которые управляют достаточно большими пулами доменов и веб-серверов, проблемы возникают из-за различных конфликтов между именами в ESNI, именами внутри TLS-сессий на стороне сервера, и именами (хостнеймами) логических узлов. Отдельный тип DNS-записи поможет бороться с этими проблемами.

Интересно, что из задачи публикации ESNI-параметров в DNS – выросло отдельное направление, в рамках которого предлагается добавить механизм, позволяющий размещать в DNS целый набор дополнительных параметров, описывающих доступ к веб-ресурсам по HTTP(S) (в том числе, указание на перечень протоколов, нестандартных номеров портов, веб-фронтендов и т.д.).

В рамках развития ESNI, появится комплект сигналов в TLS, которые позволят серверу и клиенту работать в конфигурации, где использование ESNI является обязательным (и, в частности, эффективно выбирать различные наборы криптографических ключей). То есть, работа ESNI становится более гибкой и удобной для провайдеров CDN.

Скорее всего, после выхода RFC – поддержка ESNI достаточно быстро появится в распространённых веб-серверах (например, Apache), что сделает эту технологию распространённой за пределами Cloudflare. Впрочем, для этого необходима ещё и поддержка в браузере Chrome, а она пока находится под вопросом: Google не очень-то охотно внедряет подобные технологии, позволяющие осуществлять децентрализованное управление криптографическими ключами в вебе.



Комментировать »
Навигация по запискам: