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 mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
