SSL Configuration Generator https://ssl-config.mozilla.org/

Evgeniy Berdnikov bgx на protva.ru
Ср Янв 22 19:16:02 UTC 2020


On Wed, Jan 22, 2020 at 08:13:48PM +0300, Maxim Dounin wrote:
> On Wed, Jan 22, 2020 at 05:04:33AM +0200, Gena Makhomed wrote:
[...]
> > И наоборот, если в default_server задано ssl_protocols TLSv1.3;
> > то в других server`ах директива ssl_protocols TLSv1.2; не работает.
> > 
> > Это где ошибка - в документации на сайте или в коде nginx 1.17.8?
> 
> Возможность задания какой-либо директивы в контексте server - не 
> означает, что она будет применяться для всех запросов, попадающих 
> в этот блок server.  В случае виртуальных серверов - могут быть 
> нюансы.
[...]
> Подробнее можно почитать тут и по ссылкам:
> 
> https://trac.nginx.org/nginx/ticket/844
> 
> Соответственно отвечая на заданный вопрос: ошибка - в понимании 
> написанного в документации.

 Как человек, наступавший на те же самые грабли, хочу выразить своё
 несогласие с посылом, что тупица здесь читатель. Документация вводит
 в заблуждение, а поведение nginx никак не способствует обходу этой
 ловушки.

 Если в доке написано "context: server", то читатель понимает это
 буквально: для заданного server будет действовать указанная директива.
 И поскольку её задача ограничить перечень протоколов, то именно это,
 с точки зрения пользователя, и должно происходить. Потребителю
 не до того, чтобы вспоминать, что бывают name-based виртуалхосты,
 sni-based, ip-based, процессы, нити, пространства имён и прочая лабуда,
 ему не до проблем их сплетения в разных версиях. Потребитель ожидает,
 что ему дадут простой и удобный интерфейс, где все нюансы продуманы,
 а возможность ошибиться и получить не то, что ожидал -- сведена к
 минимуму. Если же интерфейс позволяет сделать бессмысленные или даже
 противоречивые комбинации параметров -- это плохой интерфейс, и его
 следует по возможности выправлять в рантайме, например, предупреждениями
 вида "извините, в этой конфигурации есть разные версии ssl_protocols
 на одном ip-шнике, это работать не будет, см. подробности в <url>".

 Ну и в документации капканы тоже желательно упоминать, разумеется.
 
 Вероятно, хотелось сделать интерфейс простым и универсальным, чтобы
 пользователю было легче его освоить. С одной директривой "server".
 Но если идти этим путём, то стыковку разных гаек и болтов по их профилю,
 метрикам и шагам резьбы следует прятать под капот, а потребителю выводить
 такой набор педалей и ручек, чтобы он мог решить задачу "ехать" без
 головной боли и гаданий, где же включился тормоз... IMHO.
-- 
 Eugene Berdnikov


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