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

[Илья Шипицин]

чт, 23 янв. 2020 г. в 00:16, Evgeniy Berdnikov <bgx на protva.ru>:

> 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 никак не способствует обходу этой
>  ловушки.
>
>
SSL-ная часть nginx обложена граблями примерно полностью.

как вы думаете, в приведенной ниже конфигурации stapling включится ? не
торопитесь с ответом ))

server {
    listen 443 ssl http2;
    ssl_stapling on;

   location / {
     proxy_pass http://upstream;
   }
}

server {
     listen 443 ssl http2 default;
     return 404;
}


>  Если в доке написано "context: server", то читатель понимает это
>  буквально: для заданного server будет действовать указанная директива.
>  И поскольку её задача ограничить перечень протоколов, то именно это,
>  с точки зрения пользователя, и должно происходить. Потребителю
>  не до того, чтобы вспоминать, что бывают name-based виртуалхосты,
>  sni-based, ip-based, процессы, нити, пространства имён и прочая лабуда,
>  ему не до проблем их сплетения в разных версиях. Потребитель ожидает,
>  что ему дадут простой и удобный интерфейс, где все нюансы продуманы,
>  а возможность ошибиться и получить не то, что ожидал -- сведена к
>  минимуму. Если же интерфейс позволяет сделать бессмысленные или даже
>  противоречивые комбинации параметров -- это плохой интерфейс, и его
>  следует по возможности выправлять в рантайме, например, предупреждениями
>  вида "извините, в этой конфигурации есть разные версии ssl_protocols
>  на одном ip-шнике, это работать не будет, см. подробности в <url>".
>
>  Ну и в документации капканы тоже желательно упоминать, разумеется.
>
>  Вероятно, хотелось сделать интерфейс простым и универсальным, чтобы
>  пользователю было легче его освоить. С одной директривой "server".
>  Но если идти этим путём, то стыковку разных гаек и болтов по их профилю,
>  метрикам и шагам резьбы следует прятать под капот, а потребителю выводить
>  такой набор педалей и ручек, чтобы он мог решить задачу "ехать" без
>  головной боли и гаданий, где же включился тормоз... IMHO.
> --
>  Eugene Berdnikov
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20200123/992720c8/attachment-0001.htm>