Описание возможностей тестового сервера 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-режимов.

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.

()

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



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

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

Комментарии читателей блога: 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?

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

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

Преграда для ботов: *

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