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
