ssl_protocols

Maxim Dounin mdounin на mdounin.ru
Пн Июн 29 14:07:56 UTC 2020


Hello!

On Sun, Jun 28, 2020 at 09:26:46PM +0300, Gena Makhomed wrote:

> On 25.06.2020 22:27, Maxim Dounin wrote:
> 
> > А не разрешить ли TLSv1.3 по умолчанию.  Сейчас для этого как
> > минимум один блокер - в TLSv1.3 не настраиваются шифры и в
> > результате сломаются конфиги с "ssl_ciphers aNULL;", подробнее
> > тут:
> > 
> > http://mailman.nginx.org/pipermail/nginx/2018-November/057194.html
> 
> В ответе https://trac.nginx.org/nginx/ticket/195#comment:6 можно
> же дописать, что этот workaround не работает для протокола TLSv1.3,
> потому что протокол TLSv1.3 вообще не поддерживает ssl_ciphers aNULL;
> 
> Хотя, в этом тикете https://trac.nginx.org/nginx/ticket/195 просили
> совсем о другом - просили сделать возможность refuse_connections
> в том случае, если приходит HTTPS-запрос в nginx на HTTP-only сайт,
> то есть просят сделать "strict SNI should really be implemented. It's just a few if statements, is this too much for a long-standing issue?"
> 
> Не смотря на то, что этот тикет был создан 8 лет тому назад - такая
> проблема актуальна и сегодня, потому что, насколько мне известно,
> Google индексирует сайты по HTTPS не обращая внимания на ошибки
> несоответствия сертификата. В резхультате в его поисковой выдаче
> будет очень много страниц, которые дают ошибку TLS/SSL в браузере.

Проблем с гуглом при использовании "ssl_ciphers aNULL; return 
444;" - не обнаружено, да и быть не может: соединение так или 
иначе закрывается, даже если гугл вдруг готов общаться по шифрам 
aNULL.  Семантически эта конструкция делает именно то, что нужно: 
отказывается общаться, не предъявляя сертификата.

То есть в отсутствии TLSv1.3 этот workaround работает 
именно так, как надо.  Включение TLSv1.3 - его ломает.
Соответственно для включения TLSv1.3 по умолчанию надо решить две 
проблемы:

1. Сделать решение, которое бы позволило реализовать ту же 
семантику "отазаться общаться, не предъявляя сертификата" в 
условиях наличия TLSv1.3.

2. Придумать решение для существующих конфигураций с "ssl_ciphers 
aNULL; return 444;".

> > в TLSv1.3 не настраиваются шифры
> 
> И если быть уж совсем точным, шифры в TLSv1.3 настраиваются.
> Точнее в OpenSSL шифры для TLSv1.3 можно настроить. Проблема
> только в том, что вот разработчики nginx не могут договориться
> с разработчиками OpenSSL о том, как эти шифры необходимо настраивать.
> 
> В том же Apache можно без проблем настроить шифры для TLSv1.3:
> https://httpd.apache.org/docs/current/mod/mod_ssl.html#sslciphersuite
> 
> Если никак не получается договориться с разработчиками OpenSSL,
> может быть имеет сделать смысл форк OpenSSL иил написать с нуля
> свою собственную библиотеку? Ведь когда-то так и nginx появился,
> когда стало понятно, что apache не подходит для некоторых задач.
> 
> Или пойти по пути Apache, сделав возможность раздельной настройки
> шифров для TLSv1.2 и для TLSv1.3 ? Ведь по прошествии такого количества
> времени уже стало понятно, что разработчики OpenSSL свою точку зрения
> по этому вопросу менять не собираются и в OpenSSL все будет так же.

В тикете тут:

https://trac.nginx.org/nginx/ticket/1529

и связанных тикетах - достаточно подробно расписано, что 
настраивается, что не настраивается (в BoringSSL, например, для 
TLSv1.3 не настраивается вообще ничего), и что именно я думаю по 
этому поводу.  Не вижу смысла тут повторяться.

Сама по себе невозможность насраивать шифры - не является 
препятствием для включения TLSv1.3 по умолчанию, препятствием 
являются возникающие в результае проблемы в конфигурациях с 
"ssl_ciphers aNULL;".

-- 
Maxim Dounin
http://mdounin.ru/


Подробная информация о списке рассылки nginx-ru