Описание возможностей тестового сервера TLS 1.3

(Записка с перечнем поддерживаемых элементов протокола TLS 1.3. Чтобы не потерялось.)

Тестовый сервер TLS 1.3 на tls13.1d.pw:

1. Версия протокола: 1.3 (0x0304), Draft-28 (совпадает с 1.3, кроме номера версии) и Draft-23 (в этой версии есть небольшие отличия в алгоритмах от 1.3, версия до сих пор встречается на практике). Вообще, draft-версии соответствуют черновикам RFC, протокол реализовывался (в статусе экспериментального) параллельно с разработкой RFC. Например, Draft-23 был очень распространён: его поддерживали и Firefox, и Chrome. Когда я запускал тестовый сервер, RFC ещё не было, и именно версия Draft-23 была основной.

2. Криптосистема подписи: сейчас используется ECDSA в группе P-384; раньше был вариант в группе P-256 (это названия кривых), можно сделать оба варианта (попеременно выбирать для каждого запроса), но тогда нужна обработка второго сертификата – возможно, добавлю. А вот поддержку RSA пока решил не добавлять.

3. Поддержка DH (при согласовании общего секрета в рамках установления соединения): P-256, P-384, x25519, а также “классический” FFDH с разрядностью 3072 бита (поддерживается, например, Firefox).

4. Шифры: AES-128-GCM-SHA256, AES-256-GCM-SHA384, ChaCha20Poly1305. Нет CCM-режимов. Update 12/01/20: добавлено динамическое изменение приоритетов шифров на стороне сервера; добавлена поддержка сообщений KeyUpdate и, соответственно, ротация симметричных сессионных ключей.

5. Поддержка HelloRetryRequest: сервер, с некоторой вероятностью, отвечает на ClientHello сообщением пересогласования параметров – HelloRetryRequest (HRR), запрашивая другую группу из поддерживаемых клиентом; это происходит только в том случае, если набор групп, заявленный клиентом, позволяет. Это довольно богатое для целей исследования реализаций TLS направление, потому что здесь, в том или ином виде, требуется сохранение состояния соединения. Пример: предположим, что клиент заявляет для DH поддержку x25519, P-256 и FFDHE-3072, но ключ передаёт только для x25519 (это обычная ситуация в TLS 1.3); в таком случае сервер может ответить HelloRetryRequest, запросив либо P-256, либо FFDHE-3072.

6. Поддержка TLS cookie: при ответе с HelloRetryRequest – сервер передаёт клиенту TLS cookie. Это специальное расширение ClientHello/HelloRetryRequest, в котором передаётся некоторое значение – клиент должен вернуть это же значение в новом запросе ClientHello; у TLS cookie две основных роли: 1) “выгрузить” клиенту представление состояния начинающейся сессии, чтобы сервер не хранил дополнительные записи на своей стороне; 2) проверить, что клиент действительно активен и отвечает на запросы по адресу, с которого получено сообщение ClientHello. (Тестовый сервер совпадение значений TLS cookie не проверяет.)

7. Поддержка ESNI: поддерживается два варианта криптосистем DH – P-384, x25519 (в ESNI используется протокол Диффи-Хеллмана со статическими ключами, которые публикуются в DNS); шифр для ESNI – один: AES-128-GCM.

Адрес записки: https://dxdt.ru/2019/05/23/8788/

Похожие записки:



Далее - мнения и дискуссии

(Сообщения ниже добавляются читателями сайта, через форму, расположенную в конце страницы.)

Комментарии читателей блога: 7

  • 1. 24th July 2019, 21:54 // Читатель Влад написал:

    А можно ли на тестовом сервере настроить проверку ESNI если я использую маршрутизатор на котором работает dnscrypt?

  • 2. 25th July 2019, 18:47 // Александр Венедюхин:

    В общем случае, если клиент может извлекать ESNI-записи из DNS, используя DNSCrypt, то да – будет ESNI. ESNI на стороне сервера – не зависит от того, какой метод доступа к DNS используется, главное, чтобы этот метод работал и находил TXT-записи. Другое дело, что из распространённых клиентов-браузеров – ESNI сейчас есть только в Firefox, и в этом браузере данная технология строго требует, чтобы к DNS доступ был через DNS-over-HTTPS. Это означает, что через резолвер DNSCrypt Firefox с ESNI работать не будет. Другие клиенты, если таковые вдруг найдутся, вполне могут работать.

  • 3. 3rd November 2019, 18:59 // Читатель ohotnik6o написал:

    Здравствуйте, Александр.
    Благодарю за “Доменные войны” и прекрасный (чудесный)во всех отношениях ресурс. Но есть серьёзная проблема. На Ваш сайт не пускают с российским айпи.
    С уважением, ohotnik6o

  • 4. 3rd November 2019, 20:04 // Александр Венедюхин:

    На стороне веб-сервера – подобных ограничений нет.

  • 5. 6th November 2019, 20:19 // Читатель ohotnik6O написал:

    Наверное, провайдер шалит. Он у меня, например, совсем безбашенный (я, например, у него одну башню отжал, пользуюсь, вот, полным безлимитом). А на Ваш ресурс только через Тор получается ходить. Может и потому комментариев моловато? Или удаляете? Темы хорошие буду читать. Хотя, если через Тор, то при чём здесь провайдер?

  • 6. 11th November 2019, 16:47 // Читатель ohotnik6O написал:

    а на сайт коллеги с русским айпи, таки, не пускают… и это не мой, например, оператор сотовой связи, а кто-то ещё (привет, медвед)… по-итогу, Александр, мечете Вы бисер перед буржуйскими свиньями, а русскую молодёжь маринуют в собственном соку с одноклассниками… ну, как говорится, хозяин-барин… у нас в интернете каждый делает, что пожелает… желаю скорейшего выздоровления, Александр… «нет домена – нет государства», лихо… ну тогда и меня, например, нет, и кто Вам тогда всё это тут понаписывал?… ладно, не плачьте, доктор поможет… попали Вы как-то на сценарий, прям, как тот поэт Бездомный… ну и кто из нас теперь бездоменный, шизофреник Вы наш всенародный?… кстати, тот Яша часом Вам не кореш?

  • 7. 15th November 2019, 17:04 // Читатель Parlixon написал:

    А что Вы думаете по поводу QUIC? Стоит ли сейчас переходить на HTTP/3?

Написать комментарий

Ваш комментарий:

Введите ключевое слово "QR734" латиницей СПРАВА НАЛЕВО (<--) без кавычек: (это необходимо для защиты от спама).

Если видите "капчу", то решите её. Это необходимо для отправки комментария ("капча" не применяется для зарегистрированных пользователей). Обычно, комментарии поступают на премодерацию, которая нередко занимает продолжительное время.