вспомнил. мы проводили исследование на то, пользуются ли клиенты SNI.
в принципе, на вайлдкардовых сертах, как оказалось, можно работать и без
SNI.
некоторые случаи мы идентифицировали, это клиенты с определенными билдами
КриптоПро (как-то оно афектит даже RSA криптографию)
я к чему. в приведенном ниже условии, кажется, придется легитимизировать
пустой $ssl_server_name
но даже с учетом этого хак выглядит несложным. мы затестим.
if ($ssl_server_name != "example.com") {
return 421;
}
вт, 1 дек. 2020 г. в 18:43, Maxim Dounin <mdou...@mdounin.ru>:
> Hello!
>
> On Tue, Dec 01, 2020 at 06:18:32PM +0500, Илья Шипицин wrote:
>
> > вт, 1 дек. 2020 г. в 18:13, Maxim Dounin <mdou...@mdounin.ru>:
> >
> > > Hello!
> > >
> > > On Tue, Dec 01, 2020 at 10:52:48AM +0500, Илья Шипицин wrote:
> > >
> > > > вт, 1 дек. 2020 г. в 04:11, Maxim Dounin <mdou...@mdounin.ru>:
> > > >
> > > > > Hello!
> > > > >
> > > > > On Mon, Nov 30, 2020 at 11:58:59PM +0500, Илья Шипицин wrote:
> > > > >
> > > > > > привет!
> > > > > >
> > > > > > может кто сталкивался, и знает, что с этим можно сделать.
> > > > > > ситуация - хостинг высокой плотности, на одном IP много доменов.
> > > > > > домены разные, каждый со своей бизнес логикой.
> > > > > >
> > > > > > у Chrome включается какая-то оптимизация, и типа "ну раз IP
> один,
> > > то я
> > > > > > буду весь трафик гонять через одно tcp подключение". все бы
> ничего,
> > > но
> > > > > > некоторые сайты иногда рвут соединение. а Chrome в итоге рвет не
> > > > > > подключение до конкретного сайта, а вообще все, которые он
> умудрился
> > > > > > связать с этим tcp подключением.
> > > > > >
> > > > > > частный пример - сайт, который иногда формирует очень длинные
> URL, не
> > > > > > помещающиеся в дефолтный http2_max_field_fize, при возникновение
> > > такой
> > > > > > ситуации Chrome рвет всё до этого IP адреса.
> > > > > >
> > > > > > как-то не по христиански чтоли.
> > > > > >
> > > > > > подумалось, что аналогичных хостингов высокой плотности в
> рассылке
> > > может
> > > > > > быть достаточное количество. не первый же я с таким столкнулся?
> > > > >
> > > > > Это называется connection reuse, правила прописаны тут:
> > > > >
> > > > > https://tools.ietf.org/html/rfc7540#section-9.1.1
> > > > >
> > > > > В частности:
> > > > >
> > > > > For "https" resources, connection reuse additionally depends on
> > > > > having a certificate that is valid for the host in the URI. The
> > > > > certificate presented by the server MUST satisfy any checks
> that the
> > > > > client would perform when forming a new TLS connection for the
> host
> > > > > in the URI.
> > > > >
> > > > > То есть если хочется, чтобы соединения не reuse'ались, можно
> > > > > сконфигурировать разные сертификаты для разных серверов (или групп
> > > > > серверов).
> > > > >
> > > > > Ну либо руками возвращать 421 по необходимости, проверяя
> > > $ssl_server_name.
> > > > >
> > > >
> > > > в исходниках это вот так
> > > >
> > > > if ((size_t) len > h2scf->max_field_size) {
> > > > ngx_log_error(NGX_LOG_INFO, h2c->connection->log, 0,
> > > > "client exceeded http2_max_field_size limit");
> > > >
> > > > return ngx_http_v2_connection_error(h2c,
> > > > NGX_HTTP_V2_ENHANCE_YOUR_CALM);
> > > > }
> > > >
> > > >
> > > > как можно в этом месте вернуть "по необходимости" 421 ?
> > >
> > > Нет, это фатальная ошибка для соединения, дальнейшая работа с этим
> > > соединением невозможна. Возвращать 421 надо заранее, до того, как
> > > придёт кривой запрос.
> > >
> > >
> > пардон. я не понимаю, что вы предлагаете.
> > можете привести пример, как сделать ?
>
> Если добавить что-нибудь вроде:
>
> if ($ssl_server_name != "example.com") {
> return 421;
> }
>
> во все релевантные блоки server{}, это предотвратит reuse
> соединений, кроме первых запросов. Соответственно соединения
> будут отдельными, и при необходимости закрыть соединение - будет
> закрываться только соединение с одним сервером, а не со всеми
> серверами на данном IP.
>
> Ну и обращаю внимание на озвученный выше и проигнорированный
> вариант разных сертификатов. Он позволяет контроллировать
> поведение на стороне браузера и соответственно более эффективен,
> т.к. нет проблемы первых запросов.
>
> --
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
