From chipitsine на gmail.com Sun Sep 2 18:12:31 2018 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Sun, 2 Sep 2018 23:12:31 +0500 Subject: =?UTF-8?B?0LrQsNC6INC/0YDQsNCy0LjQu9GM0L3QviDQt9Cw0LrRgNGL0LLQsNGC0Ywg0YE=?= =?UTF-8?B?0L7QtdC00LjQvdC10L3QuNGPINC/0YDQuCDQvdCw0YHRgtGD0L/Qu9C10L0=?= =?UTF-8?B?0LjQuCBrZWVwYWxpdmVfcmVxdWVzdHM6INC+0LHRgdGD0LTQuNC8ID8=?= Message-ID: привет! есть такое наблюдение. если проксировать на апстрим БЕЗ киэлайв, то на стороне nginx удивительным образом все хорошо (потому что соединение закрывается по инициативе бекенда) если проксировать с включенным кипэлайвом, то в случаях, когда соединение закрывается по инициативе nginx, на стороне nginx порт уходит в TIME_WAIT. с одной стороны - несмертельно. все с этим живут. с другой стороны - например, в случае, когда запрос последний (100-й при дефолтном значении keepalive_requests), можно ведь явно добавить "Connection: Close" ? тем самым помочь бекенду закрыть соединение, и сэкономить один порт на nginx ? Илья Шипицин ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Mon Sep 3 11:11:12 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 3 Sep 2018 14:11:12 +0300 Subject: =?UTF-8?B?UmU6INC60LDQuiDQv9GA0LDQstC40LvRjNC90L4g0LfQsNC60YDRi9Cy0LDRgtGM?= =?UTF-8?B?INGB0L7QtdC00LjQvdC10L3QuNGPINC/0YDQuCDQvdCw0YHRgtGD0L/Qu9C1?= =?UTF-8?B?0L3QuNC4IGtlZXBhbGl2ZV9yZXF1ZXN0czog0L7QsdGB0YPQtNC40LwgPw==?= In-Reply-To: References: Message-ID: <20180903111112.GE56558@mdounin.ru> Hello! On Sun, Sep 02, 2018 at 11:12:31PM +0500, Илья Шипицин wrote: > привет! > > есть такое наблюдение. если проксировать на апстрим БЕЗ киэлайв, то на > стороне nginx удивительным образом все хорошо (потому что соединение > закрывается по инициативе бекенда) > > если проксировать с включенным кипэлайвом, то в случаях, когда соединение > закрывается по инициативе nginx, на стороне nginx порт уходит в > TIME_WAIT. > > с одной стороны - несмертельно. все с этим живут. > с другой стороны - например, в случае, когда запрос последний (100-й при > дефолтном значении keepalive_requests), можно ведь явно добавить > "Connection: Close" ? тем самым помочь бекенду закрыть соединение, и > сэкономить один порт на nginx ? Теоретически - можно. Практически - формирование запроса на бэкенд происходит до того, как бэкенд выбран и/или установлено или извлечено из кэша соединение, которое будет использоваться для отправки запроса. Кроме того, один и тот же запрос может быть отправлен на несколько разных бэкендов и/или в несколько разных соединений. Соответственно выставление "Connection: close" по достижении keepalive_requests для конкретного соединения к бэкенду - потребует достаточно серьёзных переделок в логике работы с бэкендами. Не говоря уже о том, что сейчас при использовании keepalive-соединений заголовок Connection выставляется из конфига через proxy_set_header, и это тоже понадобится переделывать. Так что если порты очень жмут - то проще поднять keepalive_requests. Или выставить на бэкенде аналогичное ограничение в значение, которое бы было такое же или меньше, чему у nginx'а, и тогда бэкенд будет закрывать соединение сам. Собственно, текущее значение по умолчанию keepalive_requests к клиентам совпадает с keepalive_requests к бэкендам, так что если в роли бэкенда тоже nginx - то при настройках по умолчанию он будет закрывать соединение сам. -- Maxim Dounin http://mdounin.ru/ From chipitsine на gmail.com Mon Sep 3 11:45:31 2018 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Mon, 3 Sep 2018 16:45:31 +0500 Subject: =?UTF-8?B?UmU6INC60LDQuiDQv9GA0LDQstC40LvRjNC90L4g0LfQsNC60YDRi9Cy0LDRgtGM?= =?UTF-8?B?INGB0L7QtdC00LjQvdC10L3QuNGPINC/0YDQuCDQvdCw0YHRgtGD0L/Qu9C1?= =?UTF-8?B?0L3QuNC4IGtlZXBhbGl2ZV9yZXF1ZXN0czog0L7QsdGB0YPQtNC40LwgPw==?= In-Reply-To: <20180903111112.GE56558@mdounin.ru> References: <20180903111112.GE56558@mdounin.ru> Message-ID: пн, 3 сент. 2018 г. в 16:11, Maxim Dounin : > Hello! > > On Sun, Sep 02, 2018 at 11:12:31PM +0500, Илья Шипицин wrote: > > > привет! > > > > есть такое наблюдение. если проксировать на апстрим БЕЗ киэлайв, то на > > стороне nginx удивительным образом все хорошо (потому что соединение > > закрывается по инициативе бекенда) > > > > если проксировать с включенным кипэлайвом, то в случаях, когда соединение > > закрывается по инициативе nginx, на стороне nginx порт уходит в > > TIME_WAIT. > > > > с одной стороны - несмертельно. все с этим живут. > > с другой стороны - например, в случае, когда запрос последний (100-й при > > дефолтном значении keepalive_requests), можно ведь явно добавить > > "Connection: Close" ? тем самым помочь бекенду закрыть соединение, и > > сэкономить один порт на nginx ? > > Теоретически - можно. > > Практически - формирование запроса на бэкенд происходит до того, > как бэкенд выбран и/или установлено или извлечено из кэша > соединение, которое будет использоваться для отправки запроса. > Кроме того, один и тот же запрос может быть отправлен на несколько > разных бэкендов и/или в несколько разных соединений. > > Соответственно выставление "Connection: close" по достижении > keepalive_requests для конкретного соединения к бэкенду - > потребует достаточно серьёзных переделок в логике работы с > бэкендами. Не говоря уже о том, что сейчас при использовании > keepalive-соединений заголовок Connection выставляется из конфига > через proxy_set_header, и это тоже понадобится переделывать. > да, я про эту магию и говорил. в некоторых случаях можно сделать более умно > > Так что если порты очень жмут - то проще поднять > не жмут. мы научились с этим жить. просто в процессе исследований пришла мысль, про которую я и написал. было бы круто в какие-нибудь планы разработки ее включить > keepalive_requests. Или выставить на бэкенде аналогичное > на бекенде iis, там нет такой крутилки > ограничение в значение, которое бы было такое же или меньше, чему > у nginx'а, и тогда бэкенд будет закрывать соединение сам. > Собственно, текущее значение по умолчанию keepalive_requests к > поднимать keepalive_requests в потолок - была такая ошибка. мы налетели на примерно такой сценарий по умолчанию keepalive_requests равен 100. и ... при релоаде старые воркеры довольно быстро завершаются. подняли до 4 миллиардов, и на каждый релоад получили плюсом еще 40 воркеров. и потом память закончилась keepalive_requests - это ОЧЕНЬ удобный способ завершать http- воркеры :)) > клиентам совпадает с keepalive_requests к бэкендам, так что если в > роли бэкенда тоже nginx - то при настройках по умолчанию он будет > закрывать соединение сам. > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Mon Sep 3 12:30:30 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 3 Sep 2018 15:30:30 +0300 Subject: =?UTF-8?B?UmU6INC60LDQuiDQv9GA0LDQstC40LvRjNC90L4g0LfQsNC60YDRi9Cy0LDRgtGM?= =?UTF-8?B?INGB0L7QtdC00LjQvdC10L3QuNGPINC/0YDQuCDQvdCw0YHRgtGD0L/Qu9C1?= =?UTF-8?B?0L3QuNC4IGtlZXBhbGl2ZV9yZXF1ZXN0czog0L7QsdGB0YPQtNC40LwgPw==?= In-Reply-To: References: <20180903111112.GE56558@mdounin.ru> Message-ID: <20180903123029.GF56558@mdounin.ru> Hello! On Mon, Sep 03, 2018 at 04:45:31PM +0500, Илья Шипицин wrote: > пн, 3 сент. 2018 г. в 16:11, Maxim Dounin : > > > On Sun, Sep 02, 2018 at 11:12:31PM +0500, Илья Шипицин wrote: > > > > > есть такое наблюдение. если проксировать на апстрим БЕЗ киэлайв, то на > > > стороне nginx удивительным образом все хорошо (потому что соединение > > > закрывается по инициативе бекенда) > > > > > > если проксировать с включенным кипэлайвом, то в случаях, когда соединение > > > закрывается по инициативе nginx, на стороне nginx порт уходит в > > > TIME_WAIT. > > > > > > с одной стороны - несмертельно. все с этим живут. > > > с другой стороны - например, в случае, когда запрос последний (100-й при > > > дефолтном значении keepalive_requests), можно ведь явно добавить > > > "Connection: Close" ? тем самым помочь бекенду закрыть соединение, и > > > сэкономить один порт на nginx ? > > > > Теоретически - можно. > > > > Практически - формирование запроса на бэкенд происходит до того, > > как бэкенд выбран и/или установлено или извлечено из кэша > > соединение, которое будет использоваться для отправки запроса. > > Кроме того, один и тот же запрос может быть отправлен на несколько > > разных бэкендов и/или в несколько разных соединений. > > > > Соответственно выставление "Connection: close" по достижении > > keepalive_requests для конкретного соединения к бэкенду - > > потребует достаточно серьёзных переделок в логике работы с > > бэкендами. Не говоря уже о том, что сейчас при использовании > > keepalive-соединений заголовок Connection выставляется из конфига > > через proxy_set_header, и это тоже понадобится переделывать. > > да, я про эту магию и говорил. в некоторых случаях можно сделать более умно > > > Так что если порты очень жмут - то проще поднять > > не жмут. мы научились с этим жить. > просто в процессе исследований пришла мысль, про которую я и написал. > было бы круто в какие-нибудь планы разработки ее включить Ну вот я изложил выше - там много всего переделывать, причём - с деградацией производительности в некоторых краевых случаях. При этом сама проблема, скажем так, представляется не то чтобы критичной. Так что шансов, что мы решим-таки это место переделывать - не очень много. > > keepalive_requests. Или выставить на бэкенде аналогичное > > на бекенде iis, там нет такой крутилки > > > ограничение в значение, которое бы было такое же или меньше, чему > > у nginx'а, и тогда бэкенд будет закрывать соединение сам. > > Собственно, текущее значение по умолчанию keepalive_requests к > > > > поднимать keepalive_requests в потолок - была такая ошибка. > мы налетели на примерно такой сценарий > > по умолчанию keepalive_requests равен 100. и ... при релоаде старые воркеры > довольно быстро завершаются. > подняли до 4 миллиардов, и на каждый релоад получили плюсом еще 40 > воркеров. и потом память закончилась > > keepalive_requests - это ОЧЕНЬ удобный способ завершать http- воркеры :)) Соединения в keepalive'е - что клиентские, что к бэкендам - никак не должны влиять на завершение рабочих процессов при reload'е. Они просто закрываются при получении сигнала о перезагрузке конфигурации и/или если соединение переходит в keepalive, когда рабочий процесс завершается. Если влияют - приносите подробности, будем разбираться. -- Maxim Dounin http://mdounin.ru/ From chipitsine на gmail.com Mon Sep 3 12:43:17 2018 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Mon, 3 Sep 2018 17:43:17 +0500 Subject: =?UTF-8?B?UmU6INC60LDQuiDQv9GA0LDQstC40LvRjNC90L4g0LfQsNC60YDRi9Cy0LDRgtGM?= =?UTF-8?B?INGB0L7QtdC00LjQvdC10L3QuNGPINC/0YDQuCDQvdCw0YHRgtGD0L/Qu9C1?= =?UTF-8?B?0L3QuNC4IGtlZXBhbGl2ZV9yZXF1ZXN0czog0L7QsdGB0YPQtNC40LwgPw==?= In-Reply-To: <20180903123029.GF56558@mdounin.ru> References: <20180903111112.GE56558@mdounin.ru> <20180903123029.GF56558@mdounin.ru> Message-ID: пн, 3 сент. 2018 г. в 17:30, Maxim Dounin : > Hello! > > On Mon, Sep 03, 2018 at 04:45:31PM +0500, Илья Шипицин wrote: > > > пн, 3 сент. 2018 г. в 16:11, Maxim Dounin : > > > > > On Sun, Sep 02, 2018 at 11:12:31PM +0500, Илья Шипицин wrote: > > > > > > > есть такое наблюдение. если проксировать на апстрим БЕЗ киэлайв, то > на > > > > стороне nginx удивительным образом все хорошо (потому что соединение > > > > закрывается по инициативе бекенда) > > > > > > > > если проксировать с включенным кипэлайвом, то в случаях, когда > соединение > > > > закрывается по инициативе nginx, на стороне nginx порт уходит в > > > > TIME_WAIT. > > > > > > > > с одной стороны - несмертельно. все с этим живут. > > > > с другой стороны - например, в случае, когда запрос последний (100-й > при > > > > дефолтном значении keepalive_requests), можно ведь явно добавить > > > > "Connection: Close" ? тем самым помочь бекенду закрыть соединение, и > > > > сэкономить один порт на nginx ? > > > > > > Теоретически - можно. > > > > > > Практически - формирование запроса на бэкенд происходит до того, > > > как бэкенд выбран и/или установлено или извлечено из кэша > > > соединение, которое будет использоваться для отправки запроса. > > > Кроме того, один и тот же запрос может быть отправлен на несколько > > > разных бэкендов и/или в несколько разных соединений. > > > > > > Соответственно выставление "Connection: close" по достижении > > > keepalive_requests для конкретного соединения к бэкенду - > > > потребует достаточно серьёзных переделок в логике работы с > > > бэкендами. Не говоря уже о том, что сейчас при использовании > > > keepalive-соединений заголовок Connection выставляется из конфига > > > через proxy_set_header, и это тоже понадобится переделывать. > > > > да, я про эту магию и говорил. в некоторых случаях можно сделать более > умно > > > > > Так что если порты очень жмут - то проще поднять > > > > не жмут. мы научились с этим жить. > > просто в процессе исследований пришла мысль, про которую я и написал. > > было бы круто в какие-нибудь планы разработки ее включить > > Ну вот я изложил выше - там много всего переделывать, причём - с > деградацией производительности в некоторых краевых случаях. При > этом сама проблема, скажем так, представляется не то чтобы > критичной. Так что шансов, что мы решим-таки это место > переделывать - не очень много. > с деградацией не надо, конечно. из того, что вы изложили - непонятно, каким именно бекендом обработается запрос - кажется, что можно предположить "если к первому бекенду это последний запрос - принудительно пишем Connection: close" другое дело, что в момент, когда выставляется хедер, непонятно про бекенд вообще ничего - это да. > > > > keepalive_requests. Или выставить на бэкенде аналогичное > > > > на бекенде iis, там нет такой крутилки > > > > > ограничение в значение, которое бы было такое же или меньше, чему > > > у nginx'а, и тогда бэкенд будет закрывать соединение сам. > > > Собственно, текущее значение по умолчанию keepalive_requests к > > > > > > > поднимать keepalive_requests в потолок - была такая ошибка. > > мы налетели на примерно такой сценарий > > > > по умолчанию keepalive_requests равен 100. и ... при релоаде старые > воркеры > > довольно быстро завершаются. > > подняли до 4 миллиардов, и на каждый релоад получили плюсом еще 40 > > воркеров. и потом память закончилась > > > > keepalive_requests - это ОЧЕНЬ удобный способ завершать http- воркеры :)) > > Соединения в keepalive'е - что клиентские, что к бэкендам - никак > не должны влиять на завершение рабочих процессов при reload'е. > Они просто закрываются при получении сигнала о перезагрузке > конфигурации и/или если соединение переходит в keepalive, когда > рабочий процесс завершается. Если влияют - приносите подробности, > будем разбираться. > воркер же будет обрабатывать запросы по уже установленным соединениям, пока либо клиент не отключится, либо пока воркер сам не закроет (при исчерпании keepalive_requests) ? а новый релоад приводит к запуску кучи новых воркеров. но не приводит к завершению старых воркеров ? > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Mon Sep 3 13:15:19 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 3 Sep 2018 16:15:19 +0300 Subject: =?UTF-8?B?UmU6INC60LDQuiDQv9GA0LDQstC40LvRjNC90L4g0LfQsNC60YDRi9Cy0LDRgtGM?= =?UTF-8?B?INGB0L7QtdC00LjQvdC10L3QuNGPINC/0YDQuCDQvdCw0YHRgtGD0L/Qu9C1?= =?UTF-8?B?0L3QuNC4IGtlZXBhbGl2ZV9yZXF1ZXN0czog0L7QsdGB0YPQtNC40LwgPw==?= In-Reply-To: References: <20180903111112.GE56558@mdounin.ru> <20180903123029.GF56558@mdounin.ru> Message-ID: <20180903131518.GH56558@mdounin.ru> Hello! On Mon, Sep 03, 2018 at 05:43:17PM +0500, Илья Шипицин wrote: > пн, 3 сент. 2018 г. в 17:30, Maxim Dounin : > > > Hello! > > > > On Mon, Sep 03, 2018 at 04:45:31PM +0500, Илья Шипицин wrote: > > > > > пн, 3 сент. 2018 г. в 16:11, Maxim Dounin : > > > > > > > On Sun, Sep 02, 2018 at 11:12:31PM +0500, Илья Шипицин wrote: > > > > > > > > > есть такое наблюдение. если проксировать на апстрим БЕЗ киэлайв, то > > на > > > > > стороне nginx удивительным образом все хорошо (потому что соединение > > > > > закрывается по инициативе бекенда) > > > > > > > > > > если проксировать с включенным кипэлайвом, то в случаях, когда > > соединение > > > > > закрывается по инициативе nginx, на стороне nginx порт уходит в > > > > > TIME_WAIT. > > > > > > > > > > с одной стороны - несмертельно. все с этим живут. > > > > > с другой стороны - например, в случае, когда запрос последний (100-й > > при > > > > > дефолтном значении keepalive_requests), можно ведь явно добавить > > > > > "Connection: Close" ? тем самым помочь бекенду закрыть соединение, и > > > > > сэкономить один порт на nginx ? > > > > > > > > Теоретически - можно. > > > > > > > > Практически - формирование запроса на бэкенд происходит до того, > > > > как бэкенд выбран и/или установлено или извлечено из кэша > > > > соединение, которое будет использоваться для отправки запроса. > > > > Кроме того, один и тот же запрос может быть отправлен на несколько > > > > разных бэкендов и/или в несколько разных соединений. > > > > > > > > Соответственно выставление "Connection: close" по достижении > > > > keepalive_requests для конкретного соединения к бэкенду - > > > > потребует достаточно серьёзных переделок в логике работы с > > > > бэкендами. Не говоря уже о том, что сейчас при использовании > > > > keepalive-соединений заголовок Connection выставляется из конфига > > > > через proxy_set_header, и это тоже понадобится переделывать. > > > > > > да, я про эту магию и говорил. в некоторых случаях можно сделать более > > умно > > > > > > > Так что если порты очень жмут - то проще поднять > > > > > > не жмут. мы научились с этим жить. > > > просто в процессе исследований пришла мысль, про которую я и написал. > > > было бы круто в какие-нибудь планы разработки ее включить > > > > Ну вот я изложил выше - там много всего переделывать, причём - с > > деградацией производительности в некоторых краевых случаях. При > > этом сама проблема, скажем так, представляется не то чтобы > > критичной. Так что шансов, что мы решим-таки это место > > переделывать - не очень много. > > > > с деградацией не надо, конечно. > из того, что вы изложили - непонятно, каким именно бекендом обработается > запрос - кажется, что > можно предположить "если к первому бекенду это последний запрос - > принудительно пишем Connection: close" > > другое дело, что в момент, когда выставляется хедер, непонятно про бекенд > вообще ничего - это да. Сейчас запрос создаётся до того, как что-либо становится известно про бэкенды. И используется этот единожды созданный запрос - для всех последующих обращений к любым бэкендам. Таких обращений может быть много, в соответствии с proxy_next_upstream. Более того, иногда "много" - это штатное поведение, скажем при "proxy_next_upstream http_404" предполагается, что nginx перебирает бэкенды, пока не найдёт тот, на котором есть соответствующий ресурс. Чтобы выставить "Connection: close" - надо менять логику так, чтобы запрос создавался уже в процессе обращения к бэкенду, когда соединение с бэкендом уже установлено или получено из кэша. И соответственно делать так, чтобы запрос для каждого обращения на бэкенд в рамках proxy_next_upstream - создавался заново. > > > > keepalive_requests. Или выставить на бэкенде аналогичное > > > > > > на бекенде iis, там нет такой крутилки > > > > > > > ограничение в значение, которое бы было такое же или меньше, чему > > > > у nginx'а, и тогда бэкенд будет закрывать соединение сам. > > > > Собственно, текущее значение по умолчанию keepalive_requests к > > > > > > > > > > поднимать keepalive_requests в потолок - была такая ошибка. > > > мы налетели на примерно такой сценарий > > > > > > по умолчанию keepalive_requests равен 100. и ... при релоаде старые > > воркеры > > > довольно быстро завершаются. > > > подняли до 4 миллиардов, и на каждый релоад получили плюсом еще 40 > > > воркеров. и потом память закончилась > > > > > > keepalive_requests - это ОЧЕНЬ удобный способ завершать http- воркеры :)) > > > > Соединения в keepalive'е - что клиентские, что к бэкендам - никак > > не должны влиять на завершение рабочих процессов при reload'е. > > Они просто закрываются при получении сигнала о перезагрузке > > конфигурации и/или если соединение переходит в keepalive, когда > > рабочий процесс завершается. Если влияют - приносите подробности, > > будем разбираться. > > > > воркер же будет обрабатывать запросы по уже установленным соединениям, пока > либо клиент не отключится, > либо пока воркер сам не закроет (при исчерпании keepalive_requests) ? Keepalive-соединения nginx впрове закрывать в любой момент, и именно это он и делает - в любой момент времени, когда бы рабочий процесс не попросили завершиться. Поэтому в случае http - время завершения старых рабочих процессов определяется длительностью запросов, и не зависит от того, используется ли keepalive или нет. > а новый релоад приводит к запуску кучи новых воркеров. но не приводит к > завершению старых воркеров ? Reload приводит к запуску новых рабочих процессов, а также к команде на плавное завершение старым рабочим процессам. Плавное завершение - подразумевает закрытие всех keepalive-соединений, и выход в тот момент, когда открытых соединений (точнее - работающих таймеров) не останется, то есть тогда, когда доработают все существующие запросы. -- Maxim Dounin http://mdounin.ru/ From chipitsine на gmail.com Mon Sep 3 13:20:43 2018 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Mon, 3 Sep 2018 18:20:43 +0500 Subject: =?UTF-8?B?UmU6INC60LDQuiDQv9GA0LDQstC40LvRjNC90L4g0LfQsNC60YDRi9Cy0LDRgtGM?= =?UTF-8?B?INGB0L7QtdC00LjQvdC10L3QuNGPINC/0YDQuCDQvdCw0YHRgtGD0L/Qu9C1?= =?UTF-8?B?0L3QuNC4IGtlZXBhbGl2ZV9yZXF1ZXN0czog0L7QsdGB0YPQtNC40LwgPw==?= In-Reply-To: <20180903131518.GH56558@mdounin.ru> References: <20180903111112.GE56558@mdounin.ru> <20180903123029.GF56558@mdounin.ru> <20180903131518.GH56558@mdounin.ru> Message-ID: пн, 3 сент. 2018 г. в 18:15, Maxim Dounin : > Hello! > > On Mon, Sep 03, 2018 at 05:43:17PM +0500, Илья Шипицин wrote: > > > пн, 3 сент. 2018 г. в 17:30, Maxim Dounin : > > > > > Hello! > > > > > > On Mon, Sep 03, 2018 at 04:45:31PM +0500, Илья Шипицин wrote: > > > > > > > пн, 3 сент. 2018 г. в 16:11, Maxim Dounin : > > > > > > > > > On Sun, Sep 02, 2018 at 11:12:31PM +0500, Илья Шипицин wrote: > > > > > > > > > > > есть такое наблюдение. если проксировать на апстрим БЕЗ киэлайв, > то > > > на > > > > > > стороне nginx удивительным образом все хорошо (потому что > соединение > > > > > > закрывается по инициативе бекенда) > > > > > > > > > > > > если проксировать с включенным кипэлайвом, то в случаях, когда > > > соединение > > > > > > закрывается по инициативе nginx, на стороне nginx порт уходит в > > > > > > TIME_WAIT. > > > > > > > > > > > > с одной стороны - несмертельно. все с этим живут. > > > > > > с другой стороны - например, в случае, когда запрос последний > (100-й > > > при > > > > > > дефолтном значении keepalive_requests), можно ведь явно добавить > > > > > > "Connection: Close" ? тем самым помочь бекенду закрыть > соединение, и > > > > > > сэкономить один порт на nginx ? > > > > > > > > > > Теоретически - можно. > > > > > > > > > > Практически - формирование запроса на бэкенд происходит до того, > > > > > как бэкенд выбран и/или установлено или извлечено из кэша > > > > > соединение, которое будет использоваться для отправки запроса. > > > > > Кроме того, один и тот же запрос может быть отправлен на несколько > > > > > разных бэкендов и/или в несколько разных соединений. > > > > > > > > > > Соответственно выставление "Connection: close" по достижении > > > > > keepalive_requests для конкретного соединения к бэкенду - > > > > > потребует достаточно серьёзных переделок в логике работы с > > > > > бэкендами. Не говоря уже о том, что сейчас при использовании > > > > > keepalive-соединений заголовок Connection выставляется из конфига > > > > > через proxy_set_header, и это тоже понадобится переделывать. > > > > > > > > да, я про эту магию и говорил. в некоторых случаях можно сделать > более > > > умно > > > > > > > > > Так что если порты очень жмут - то проще поднять > > > > > > > > не жмут. мы научились с этим жить. > > > > просто в процессе исследований пришла мысль, про которую я и написал. > > > > было бы круто в какие-нибудь планы разработки ее включить > > > > > > Ну вот я изложил выше - там много всего переделывать, причём - с > > > деградацией производительности в некоторых краевых случаях. При > > > этом сама проблема, скажем так, представляется не то чтобы > > > критичной. Так что шансов, что мы решим-таки это место > > > переделывать - не очень много. > > > > > > > с деградацией не надо, конечно. > > из того, что вы изложили - непонятно, каким именно бекендом обработается > > запрос - кажется, что > > можно предположить "если к первому бекенду это последний запрос - > > принудительно пишем Connection: close" > > > > другое дело, что в момент, когда выставляется хедер, непонятно про бекенд > > вообще ничего - это да. > > Сейчас запрос создаётся до того, как что-либо становится известно > про бэкенды. И используется этот единожды созданный запрос - для > всех последующих обращений к любым бэкендам. Таких обращений > может быть много, в соответствии с proxy_next_upstream. Более > того, иногда "много" - это штатное поведение, скажем при > "proxy_next_upstream http_404" предполагается, что nginx > перебирает бэкенды, пока не найдёт тот, на котором есть > соответствующий ресурс. > > Чтобы выставить "Connection: close" - надо менять логику так, > чтобы запрос создавался уже в процессе обращения к бэкенду, когда > соединение с бэкендом уже установлено или получено из кэша. И > соответственно делать так, чтобы запрос для каждого обращения на > бэкенд в рамках proxy_next_upstream - создавался заново. > с точки зрения протокола http (кроме 2-й версии), в рамках каждого запроса (на каждый бекенд) отправляется свой заголовок "Connection: Close" (или Keep-Alive) кажется, что поменять его во время запроса - не поздно. то, что на http_404 будет отправляться Connection: close - не криминал, пусть отправляется > > > > > keepalive_requests. Или выставить на бэкенде аналогичное > > > > > > > > на бекенде iis, там нет такой крутилки > > > > > > > > > ограничение в значение, которое бы было такое же или меньше, чему > > > > > у nginx'а, и тогда бэкенд будет закрывать соединение сам. > > > > > Собственно, текущее значение по умолчанию keepalive_requests к > > > > > > > > > > > > > поднимать keepalive_requests в потолок - была такая ошибка. > > > > мы налетели на примерно такой сценарий > > > > > > > > по умолчанию keepalive_requests равен 100. и ... при релоаде старые > > > воркеры > > > > довольно быстро завершаются. > > > > подняли до 4 миллиардов, и на каждый релоад получили плюсом еще 40 > > > > воркеров. и потом память закончилась > > > > > > > > keepalive_requests - это ОЧЕНЬ удобный способ завершать http- > воркеры :)) > > > > > > Соединения в keepalive'е - что клиентские, что к бэкендам - никак > > > не должны влиять на завершение рабочих процессов при reload'е. > > > Они просто закрываются при получении сигнала о перезагрузке > > > конфигурации и/или если соединение переходит в keepalive, когда > > > рабочий процесс завершается. Если влияют - приносите подробности, > > > будем разбираться. > > > > > > > воркер же будет обрабатывать запросы по уже установленным соединениям, > пока > > либо клиент не отключится, > > либо пока воркер сам не закроет (при исчерпании keepalive_requests) ? > > Keepalive-соединения nginx впрове закрывать в любой момент, и > именно это он и делает - в любой момент времени, когда бы рабочий > процесс не попросили завершиться. > > Поэтому в случае http - время завершения старых рабочих процессов > определяется длительностью запросов, и не зависит от того, > используется ли keepalive или нет. > > > а новый релоад приводит к запуску кучи новых воркеров. но не приводит к > > завершению старых воркеров ? > > Reload приводит к запуску новых рабочих процессов, а также к > команде на плавное завершение старым рабочим процессам. Плавное > завершение - подразумевает закрытие всех keepalive-соединений, и > выход в тот момент, когда открытых соединений (точнее - работающих > таймеров) не останется, то есть тогда, когда доработают все > существующие запросы. > понаблюдаем > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Mon Sep 3 18:15:57 2018 From: nginx-forum на forum.nginx.org (Dmitry WD) Date: Mon, 03 Sep 2018 14:15:57 -0400 Subject: =?UTF-8?B?UmU6IE5naW54INC+0YLQtNCw0LXRgiDQutC70LjQtdC90YLRgyA1MDIsINC90L4g?= =?UTF-8?B?0L/QvtC70YPRh9Cw0LXRgiDQvtGCIGJhY2tlbmQgNDAx?= In-Reply-To: <20180828152309.GQ56558@mdounin.ru> References: <20180828152309.GQ56558@mdounin.ru> Message-ID: <7f5adf172124a7118d0b0018fb97f59a.NginxMailingListRussian@forum.nginx.org> Максим, спасибо за информацию! Учтем это в работе бекэнда. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,280939,281085#msg-281085 From thresh на nginx.com Thu Sep 6 14:04:59 2018 From: thresh на nginx.com (Konstantin Pavlov) Date: Thu, 6 Sep 2018 17:04:59 +0300 Subject: SLES 15 nginx repo In-Reply-To: References: Message-ID: <41f0508a-6bed-37c6-8051-18c9ea337389@nginx.com> Здравствуйте, 20.08.2018 11:50, Vadim Lazovskiy wrote: > Здравствуйте. > > Можно вас попросить добавить сборку для SLES 15? Добавил и для stable и для mainline. Было бы отлично, если бы Вы протестировали и сообщили, ежели что не так. (Как подключать в https://nginx.org/ru/linux_packages.html) -- Konstantin Pavlov Join us at NGINX Conf 2018, Oct 8-11, Atlanta, GA, USA https://www.nginx.com/nginxconf/2018/ From nginx-forum на forum.nginx.org Thu Sep 6 14:58:15 2018 From: nginx-forum на forum.nginx.org (tikhoa) Date: Thu, 06 Sep 2018 10:58:15 -0400 Subject: =?UTF-8?B?0JjRgdC/0L7Qu9GM0LfQvtCy0LDQvdC40LUg0LrQtdGI0LAg0LXRgdC70Lgg0LA=?= =?UTF-8?B?0L/RgdGC0YDQuNC8INC90LUg0L7RgtCy0LXRh9Cw0LXRgiDQutC+0YDRgNC1?= =?UTF-8?B?0LrRgtC90L4sINCyINC+0YHRgtCw0LvRjNC90YvRhSDRgdC70YPRh9Cw0Y8=?= =?UTF-8?B?0YUgLSDQv9GA0L7QutGB0LjRgNC+0LLQsNGC0Ywg0LHQtdC3INC60LXRiNCw?= Message-ID: Подскажите, где я не прав и вообще возможно ли это. Задача такая: использовать кеш если апстрим не работает, иначе кеш не использовать. Для этого я решил использовать proxy_cache_use_stale директиву и max-age=1: proxy_cache_path /app/cache/ui levels=1:2 keys_zone=ui:10m max_size=1g inactive=30d; server { ... location /app/ui/config.json { proxy_cache ui; proxy_cache_valid 1d; proxy_ignore_headers Expires; proxy_hide_header Expires; proxy_hide_header Cache-Control; add_header Cache-Control "max-age=1, public"; proxy_cache_use_stale error timeout http_500 http_502 http_503 http_504; add_header X-Cache-Status $upstream_cache_status; add_header X-Cache-Date $upstream_http_date; proxy_pass http://app/config.json; } } Но во время выключения бекенда, кеш не используется. Где подвох? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,281118,281118#msg-281118 From gmm на csdoc.com Thu Sep 6 15:26:25 2018 From: gmm на csdoc.com (Gena Makhomed) Date: Thu, 6 Sep 2018 18:26:25 +0300 Subject: OCSP stapling in Nginx >=1.3.7 Message-ID: <1240491d-0262-b7de-b4cf-a8e29f7274f9@csdoc.com> Здравствуйте, All! Если с помощью Let's Encrypt сделать SSL-сертификат для домена,например, example.com то в файле /etc/letsencrypt/live/example.com/README будет такая информация: `chain.pem` : used for OCSP stapling in Nginx >=1.3.7. Чтобы nginx использовал файл chain.pem для OCSP stapling необходимо прописать в конфиге ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem; ssl_stapling on; ssl_stapling_verify on; resolver 8.8.8.8 1.1.1.1 9.9.9.9 ipv6=off; я правильно понимаю? Смущает тот факт, что если закомментировать в конфиге директиву ssl_trusted_certificate - никаких предупреждений не выводится во время тестирования конфигурации и никаких сообщений не пишется в лог во время systemctl reload nginx Насколько я понимаю, ssl_stapling_verify on следует включать всегда, потому что общение с OCSP сервером происходит по протоколу HTTP? По крайней мере, в самом сертификате написано: OCSP: URI: http://ocsp.int-x3.letsencrypt.org -- Best regards, Gena From mdounin на mdounin.ru Mon Sep 10 13:04:19 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 10 Sep 2018 16:04:19 +0300 Subject: OCSP stapling in Nginx >=1.3.7 In-Reply-To: <1240491d-0262-b7de-b4cf-a8e29f7274f9@csdoc.com> References: <1240491d-0262-b7de-b4cf-a8e29f7274f9@csdoc.com> Message-ID: <20180910130419.GC56558@mdounin.ru> Hello! On Thu, Sep 06, 2018 at 06:26:25PM +0300, Gena Makhomed wrote: > Здравствуйте, All! > > Если с помощью Let's Encrypt сделать SSL-сертификат > для домена,например, example.com то в файле > /etc/letsencrypt/live/example.com/README > будет такая информация: > > `chain.pem` : used for OCSP stapling in Nginx >=1.3.7. > > Чтобы nginx использовал файл chain.pem для OCSP stapling > необходимо прописать в конфиге > > ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; > ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; > ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem; > > ssl_stapling on; > ssl_stapling_verify on; > resolver 8.8.8.8 1.1.1.1 9.9.9.9 ipv6=off; > > я правильно понимаю? Just a side note: использование сторонних DNS-серверов - это плохое решение. Цитируя документацию: : Для предотвращения DNS-спуфинга рекомендуется использовать : DNS-серверы в защищённой доверенной локальной сети. > Смущает тот факт, что если закомментировать > в конфиге директиву ssl_trusted_certificate > - никаких предупреждений не выводится во время > тестирования конфигурации и никаких сообщений > не пишется в лог во время systemctl reload nginx Верификация OCSP-ответов - происходит только в момент собственно получения этих ответов. Соответственно каких-либо ошибок в логе стоит ожидать только после того, как к соответствующему server'у будет установлено первое соединение с запросом stapling'а. Кроме того, в некоторых случаях для проверки может хватить сертификатов, уже присутствующих в цепочке сертификата (по идее должно хватать issuer cert, которые есть в цепочке почти всегда, но, к сожалению, соответствующие функции в OpenSSL, cкажем так, оставляют желать - и это, собственно, основная причина, почему ssl_stapling_verify не используется по умолчанию). > Насколько я понимаю, ssl_stapling_verify on > следует включать всегда, потому что общение > с OCSP сервером происходит по протоколу HTTP? > По крайней мере, в самом сертификате написано: > OCSP: URI: http://ocsp.int-x3.letsencrypt.org Да, общение с OCSP-сервером происходит по HTTP. Но на самом деле это мало влияет на то, следует ли использовать ssl_stapling_verify или нет - самому nginx'у всё равно, что написано в OCSP-ответе. Вопрос в первую очередь в поведении браузеров. Когда я последний углублялся в тему - Firefox остро реагировал на некорректные OCSP-ответы в стаплинге, не пытаясь самостоятельно перезапросить OCSP-ответ с OCSP-сервера, и это естественным образом приводило к тому, что подсунув серверу некорректный OCSP-ответ - можно было выключить его для всех пользователей Firefox'а[1]. Что, впрочем, не мешало Apache не иметь даже возможности для верификации OCSP-ответов. Не в курсе, изменилось ли с тех пор что-нибудь. [1] https://trac.nginx.org/nginx/ticket/425#comment:2 -- Maxim Dounin http://mdounin.ru/ From gmm на csdoc.com Mon Sep 10 19:38:25 2018 From: gmm на csdoc.com (Gena Makhomed) Date: Mon, 10 Sep 2018 22:38:25 +0300 Subject: OCSP stapling in Nginx >=1.3.7 In-Reply-To: <20180910130419.GC56558@mdounin.ru> References: <1240491d-0262-b7de-b4cf-a8e29f7274f9@csdoc.com> <20180910130419.GC56558@mdounin.ru> Message-ID: On 10.09.2018 16:04, Maxim Dounin wrote: >> Если с помощью Let's Encrypt сделать SSL-сертификат >> для домена,например, example.com то в файле >> /etc/letsencrypt/live/example.com/README >> будет такая информация: >> >> `chain.pem` : used for OCSP stapling in Nginx >=1.3.7. >> >> Чтобы nginx использовал файл chain.pem для OCSP stapling >> необходимо прописать в конфиге >> >> ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; >> ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; >> ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem; >> >> ssl_stapling on; >> ssl_stapling_verify on; >> resolver 8.8.8.8 1.1.1.1 9.9.9.9 ipv6=off; >> >> я правильно понимаю? > Just a side note: использование сторонних DNS-серверов - это > плохое решение. Цитируя документацию: > : Для предотвращения DNS-спуфинга рекомендуется использовать > : DNS-серверы в защищённой доверенной локальной сети. Разве сервера 8.8.8.8, 1.1.1.1 и 9.9.9.9 подвержены атаке DNS spoofing? https://en.wikipedia.org/wiki/DNS_spoofing >> Смущает тот факт, что если закомментировать >> в конфиге директиву ssl_trusted_certificate >> - никаких предупреждений не выводится во время >> тестирования конфигурации и никаких сообщений >> не пишется в лог во время systemctl reload nginx > Верификация OCSP-ответов - происходит только в момент собственно > получения этих ответов. Соответственно каких-либо ошибок в логе > стоит ожидать только после того, как к соответствующему server'у > будет установлено первое соединение с запросом stapling'а. Но если в конфиге нет директивы ssl_trusted_certificate то директива ssl_stapling_verify on; сейчас работать не сможет в 100% случаев? > Кроме того, в некоторых случаях для проверки может хватить > сертификатов, уже присутствующих в цепочке сертификата (по идее > должно хватать issuer cert, которые есть в цепочке почти всегда, > но, к сожалению, соответствующие функции в OpenSSL, cкажем так, > оставляют желать - и это, собственно, основная причина, почему > ssl_stapling_verify не используется по умолчанию). Но ведь SSL сертификаты - это обычные текстовые файлы. Например, если для сайта example.com сравнить два файла /etc/letsencrypt/live/example.com/fullchain.pem /etc/letsencrypt/live/example.com/chain.pem то видно что файл chain.pem равен файлу fullchain.pem плюс дополнительный сертификат сайта на самом верху. Можно ли сделать для директивы ssl_trusted_certificate параметр auto который будет означать автоматическое получение файла chain.pem путем вырезания самого первого сертификата из файла fullchain.pem? В таком случае можно было бы сделать значением по-умолчанию ssl_trusted_certificate auto; и ssl_stapling_verify on; И веб-сервер nginx тогда будет "Secure by default". Хотя, проверка клиентских сертификатов и проверка ответов OCSP - это две совсем разные задачи, странно что для них используется в nginx одна и та же директива ssl_trusted_certificate. Не лучше ли было бы для этих двух разных задач иметь и две разные директивы? Например, ssl_trusted_certificate - только для проверки клиентских сертификатов и ssl_stapling_trusted_certificate - только для проверки ответов OCSP и уже для директивы ssl_stapling_trusted_certificate сделать значение по-умолчанию равное auto? IMHO это был бы практически идеальный вариант, поскольку будет работать предсказуемым образом вне зависимости от имени и версии используемой при сборке nginx SSL-библиотеки. >> Насколько я понимаю, ssl_stapling_verify on >> следует включать всегда, потому что общение >> с OCSP сервером происходит по протоколу HTTP? >> По крайней мере, в самом сертификате написано: >> OCSP: URI: http://ocsp.int-x3.letsencrypt.org > Да, общение с OCSP-сервером происходит по HTTP. Но на самом деле > это мало влияет на то, следует ли использовать ssl_stapling_verify > или нет - самому nginx'у всё равно, что написано в OCSP-ответе. > Вопрос в первую очередь в поведении браузеров. > Когда я последний углублялся в тему - Firefox остро реагировал на > некорректные OCSP-ответы в стаплинге, не пытаясь самостоятельно > перезапросить OCSP-ответ с OCSP-сервера, и это естественным > образом приводило к тому, что подсунув серверу некорректный > OCSP-ответ - можно было выключить его для всех пользователей > Firefox'а[1]. Что, впрочем, не мешало Apache не иметь даже > возможности для верификации OCSP-ответов. Не в курсе, изменилось > ли с тех пор что-нибудь. > > [1] https://trac.nginx.org/nginx/ticket/425#comment:2 То есть, ssl_stapling_verify on; в nginx следует включать всегда и нет никаких разумных причин, почему системный администратор может захотеть сделать ssl_stapling_verify off; для своего сайта? -- Best regards, Gena From chipitsine на gmail.com Mon Sep 10 20:22:33 2018 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 11 Sep 2018 01:22:33 +0500 Subject: OCSP stapling in Nginx >=1.3.7 In-Reply-To: References: <1240491d-0262-b7de-b4cf-a8e29f7274f9@csdoc.com> <20180910130419.GC56558@mdounin.ru> Message-ID: вт, 11 сент. 2018 г. в 0:38, Gena Makhomed : > On 10.09.2018 16:04, Maxim Dounin wrote: > > >> Если с помощью Let's Encrypt сделать SSL-сертификат > >> для домена,например, example.com то в файле > >> /etc/letsencrypt/live/example.com/README > >> будет такая информация: > >> > >> `chain.pem` : used for OCSP stapling in Nginx >=1.3.7. > >> > >> Чтобы nginx использовал файл chain.pem для OCSP stapling > >> необходимо прописать в конфиге > >> > >> ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; > >> ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; > >> ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem; > >> > >> ssl_stapling on; > >> ssl_stapling_verify on; > >> resolver 8.8.8.8 1.1.1.1 9.9.9.9 ipv6=off; > >> > >> я правильно понимаю? > > > Just a side note: использование сторонних DNS-серверов - это > > плохое решение. Цитируя документацию: > > > : Для предотвращения DNS-спуфинга рекомендуется использовать > > : DNS-серверы в защищённой доверенной локальной сети. > > Разве сервера 8.8.8.8, 1.1.1.1 и 9.9.9.9 подвержены атаке DNS spoofing? > https://en.wikipedia.org/wiki/DNS_spoofing > > >> Смущает тот факт, что если закомментировать > >> в конфиге директиву ssl_trusted_certificate > >> - никаких предупреждений не выводится во время > >> тестирования конфигурации и никаких сообщений > >> не пишется в лог во время systemctl reload nginx > > > Верификация OCSP-ответов - происходит только в момент собственно > > получения этих ответов. Соответственно каких-либо ошибок в логе > > стоит ожидать только после того, как к соответствующему server'у > > будет установлено первое соединение с запросом stapling'а. > > Но если в конфиге нет директивы ssl_trusted_certificate то директива > ssl_stapling_verify on; сейчас работать не сможет в 100% случаев? > > > Кроме того, в некоторых случаях для проверки может хватить > > сертификатов, уже присутствующих в цепочке сертификата (по идее > > должно хватать issuer cert, которые есть в цепочке почти всегда, > > но, к сожалению, соответствующие функции в OpenSSL, cкажем так, > > оставляют желать - и это, собственно, основная причина, почему > > ssl_stapling_verify не используется по умолчанию). > > Но ведь SSL сертификаты - это обычные текстовые файлы. > Например, если для сайта example.com сравнить два файла > > /etc/letsencrypt/live/example.com/fullchain.pem > /etc/letsencrypt/live/example.com/chain.pem > > то видно что файл chain.pem равен файлу fullchain.pem > плюс дополнительный сертификат сайта на самом верху. > > Можно ли сделать для директивы ssl_trusted_certificate параметр auto > который будет означать автоматическое получение файла chain.pem путем > вырезания самого первого сертификата из файла fullchain.pem? > > В таком случае можно было бы сделать значением по-умолчанию > ssl_trusted_certificate auto; и ssl_stapling_verify on; > И веб-сервер nginx тогда будет "Secure by default". > > Хотя, проверка клиентских сертификатов и проверка ответов OCSP > - это две совсем разные задачи, странно что для них используется > в nginx одна и та же директива ssl_trusted_certificate. > > Не лучше ли было бы для этих двух разных задач > иметь и две разные директивы? > > Например, > ssl_trusted_certificate - только для проверки клиентских сертификатов > и ssl_stapling_trusted_certificate - только для проверки ответов OCSP > > и уже для директивы ssl_stapling_trusted_certificate > сделать значение по-умолчанию равное auto? > > IMHO это был бы практически идеальный вариант, > поскольку будет работать предсказуемым образом > вне зависимости от имени и версии используемой > при сборке nginx SSL-библиотеки. > > >> Насколько я понимаю, ssl_stapling_verify on > >> следует включать всегда, потому что общение > >> с OCSP сервером происходит по протоколу HTTP? > >> По крайней мере, в самом сертификате написано: > >> OCSP: URI: http://ocsp.int-x3.letsencrypt.org > > > Да, общение с OCSP-сервером происходит по HTTP. Но на самом деле > > это мало влияет на то, следует ли использовать ssl_stapling_verify > > или нет - самому nginx'у всё равно, что написано в OCSP-ответе. > > Вопрос в первую очередь в поведении браузеров. > > > Когда я последний углублялся в тему - Firefox остро реагировал на > > некорректные OCSP-ответы в стаплинге, не пытаясь самостоятельно > > перезапросить OCSP-ответ с OCSP-сервера, и это естественным > > образом приводило к тому, что подсунув серверу некорректный > > OCSP-ответ - можно было выключить его для всех пользователей > > Firefox'а[1]. Что, впрочем, не мешало Apache не иметь даже > > возможности для верификации OCSP-ответов. Не в курсе, изменилось > > ли с тех пор что-нибудь. > > > > [1] https://trac.nginx.org/nginx/ticket/425#comment:2 > > То есть, ssl_stapling_verify on; в nginx следует включать всегда > и нет никаких разумных причин, почему системный администратор > может захотеть сделать ssl_stapling_verify off; для своего сайта? > у клиентов может быть неправильное время (например, они так могут делать при вводе документов в 1С) если вы им отдадите ocsp stapling, то с точки зрения браузера сертификат невалиден, и почему-то браузеры так запрограммированы, что кнопки "игнорировать, покажите мне уже сайт" у клиента не будет. > > -- > Best regards, > Gena > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Mon Sep 10 20:52:08 2018 From: nginx-forum на forum.nginx.org (ngnx8810773a83) Date: Mon, 10 Sep 2018 16:52:08 -0400 Subject: OCSP stapling in Nginx >=1.3.7 In-Reply-To: References: Message-ID: <4779fa97a80e48fdd5dc158260a34f67.NginxMailingListRussian@forum.nginx.org> Укажите в ssl_trusted_certificate и в ssl_certificate один и тот же файл, который fullchain. и будет Вам счастье. :) Posted at Nginx Forum: https://forum.nginx.org/read.php?21,281119,281146#msg-281146 From nginx-forum на forum.nginx.org Mon Sep 10 21:01:18 2018 From: nginx-forum на forum.nginx.org (ngnx8810773a83) Date: Mon, 10 Sep 2018 17:01:18 -0400 Subject: OCSP stapling in Nginx >=1.3.7 In-Reply-To: References: Message-ID: <866bd03cc42474c195e1fddca4df67b9.NginxMailingListRussian@forum.nginx.org> > у клиентов может быть неправильное время (например, они так могут делать > при вводе документов в 1С) > если вы им отдадите ocsp stapling, то с точки зрения браузера сертификат > невалиден, и почему-то > браузеры так запрограммированы, что кнопки "игнорировать, покажите мне уже > сайт" у клиента не будет. Я думаю они уже в курсе, что если они время сдвинули больше чем на несколько дней, то пол интернета у них не работает., не пускает в АД, да и не совсем понятно, пускает ли в mssql если там доменная аваторизация... Кажется сейчас проводки задним числом без проблем бьются в бухгалтерии, которая не имеет вообще прав менять время на компе .. вот уж не знаю как они это делают. . если на сайте секртифкат Letsencrypt, то у него раз в пару месяцев новый сертификат, в котором написано что он выдан вот только что, и все браузеры с открученным назад временем бутут на него точно также вопить. (он ставится роботом,и появляется на сайте не позднее пары минут после выдачи. даже есди это происходит в 3 часа ночи, то на сайт все одно ктото может заходить. Кажется это не проблема сейчас. Ни разу не слышал чтобы на это жаловались.) Posted at Nginx Forum: https://forum.nginx.org/read.php?21,281119,281148#msg-281148 From mdounin на mdounin.ru Tue Sep 11 03:21:09 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 11 Sep 2018 06:21:09 +0300 Subject: OCSP stapling in Nginx >=1.3.7 In-Reply-To: References: <1240491d-0262-b7de-b4cf-a8e29f7274f9@csdoc.com> <20180910130419.GC56558@mdounin.ru> Message-ID: <20180911032109.GK56558@mdounin.ru> Hello! On Mon, Sep 10, 2018 at 10:38:25PM +0300, Gena Makhomed wrote: > On 10.09.2018 16:04, Maxim Dounin wrote: > > >> Если с помощью Let's Encrypt сделать SSL-сертификат > >> для домена,например, example.com то в файле > >> /etc/letsencrypt/live/example.com/README > >> будет такая информация: > >> > >> `chain.pem` : used for OCSP stapling in Nginx >=1.3.7. > >> > >> Чтобы nginx использовал файл chain.pem для OCSP stapling > >> необходимо прописать в конфиге > >> > >> ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; > >> ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; > >> ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem; > >> > >> ssl_stapling on; > >> ssl_stapling_verify on; > >> resolver 8.8.8.8 1.1.1.1 9.9.9.9 ipv6=off; > >> > >> я правильно понимаю? > > > Just a side note: использование сторонних DNS-серверов - это > > плохое решение. Цитируя документацию: > > > : Для предотвращения DNS-спуфинга рекомендуется использовать > > : DNS-серверы в защищённой доверенной локальной сети. > > Разве сервера 8.8.8.8, 1.1.1.1 и 9.9.9.9 подвержены атаке DNS spoofing? > https://en.wikipedia.org/wiki/DNS_spoofing Речь не о том, подвержены ли эти сервера атакам. Речь о том, что при использовании не-локальных DNS-серверов в некотороых случаях становятся возможны атаки на resolver nginx'а, так как он общается с удалённым DNS-сервером - то есть, фактически, открыт для всего мира с точностью до номера порта и 16-битного query id, ибо spoofing IP-адреса в UDP-пакетах проблемы не представляет. > >> Смущает тот факт, что если закомментировать > >> в конфиге директиву ssl_trusted_certificate > >> - никаких предупреждений не выводится во время > >> тестирования конфигурации и никаких сообщений > >> не пишется в лог во время systemctl reload nginx > > > Верификация OCSP-ответов - происходит только в момент собственно > > получения этих ответов. Соответственно каких-либо ошибок в логе > > стоит ожидать только после того, как к соответствующему server'у > > будет установлено первое соединение с запросом stapling'а. > > Но если в конфиге нет директивы ssl_trusted_certificate то директива > ssl_stapling_verify on; сейчас работать не сможет в 100% случаев? Зависит от того, каким сертификатом подписан OCSP-ответ, и какие именно сертификаты лежал в цепочке в ssl_certificate. > > Кроме того, в некоторых случаях для проверки может хватить > > сертификатов, уже присутствующих в цепочке сертификата (по идее > > должно хватать issuer cert, которые есть в цепочке почти всегда, > > но, к сожалению, соответствующие функции в OpenSSL, cкажем так, > > оставляют желать - и это, собственно, основная причина, почему > > ssl_stapling_verify не используется по умолчанию). > > Но ведь SSL сертификаты - это обычные текстовые файлы. > Например, если для сайта example.com сравнить два файла > > /etc/letsencrypt/live/example.com/fullchain.pem > /etc/letsencrypt/live/example.com/chain.pem > > то видно что файл chain.pem равен файлу fullchain.pem > плюс дополнительный сертификат сайта на самом верху. > > Можно ли сделать для директивы ssl_trusted_certificate параметр auto > который будет означать автоматическое получение файла chain.pem путем > вырезания самого первого сертификата из файла fullchain.pem? > > В таком случае можно было бы сделать значением по-умолчанию > ssl_trusted_certificate auto; и ssl_stapling_verify on; > И веб-сервер nginx тогда будет "Secure by default". > > Хотя, проверка клиентских сертификатов и проверка ответов OCSP > - это две совсем разные задачи, странно что для них используется > в nginx одна и та же директива ssl_trusted_certificate. > > Не лучше ли было бы для этих двух разных задач > иметь и две разные директивы? Лучше всего - сделать так, чтобы OpenSSL научился проверять OCSP-ответы не полной цепочкой сертификатов вплоть до доверенного root'а, а ровно так, как и должно быть по стандарту - с помощью одного только сертификата issuer'а. Тогда проблема исчезнет. Пытаться же изобретать костыли, чтобы решить проблему кривых интерфейсов OpenSSL - это бессмысленная деятельность, на выходе которой ничего кроме костылей получиться не может. Просто по определению. [...] -- Maxim Dounin http://mdounin.ru/ From fe на hamilton.rinet.ru Tue Sep 11 04:41:57 2018 From: fe на hamilton.rinet.ru (Fedor Dikarev) Date: Tue, 11 Sep 2018 07:41:57 +0300 Subject: =?UTF-8?B?U1NJINC00LvRjyDQsdC40L3QsNGA0L3Ri9GFINC00LDQvdC90YvRhSDQuNC70Lgg?= =?UTF-8?B?0LDQvdCw0LvQvtCz?= Message-ID: Привет! Столкнулся с задачей: хотим чтобы nginx собирал бинарный ответ из частей. Пример задачи: клиент скачивает из личного кабинета установщик (exe файл), а мы в конец этого exe файла дописываем json с конфигурацией для этого клиента. И собственно при первом запуске пользователю не надо вбивать адреса серверов и другие базовые настройки, все уже на месте. Собственно можно ли через SSI собирать бинарные ответы? Или можно ли как-то из своего скрипта сделать chunked ответ, где через X-Accel-Redirect отдать первую бинарную часть ответа, а потом выдать контент с конфигурацией? -- Fedor Dikarev From xeioex на nginx.com Tue Sep 11 06:32:00 2018 From: xeioex на nginx.com (Dmitry Volyntsev) Date: Tue, 11 Sep 2018 09:32:00 +0300 Subject: =?UTF-8?B?UmU6IFNTSSDQtNC70Y8g0LHQuNC90LDRgNC90YvRhSDQtNCw0L3QvdGL0YUg0Lg=?= =?UTF-8?B?0LvQuCDQsNC90LDQu9C+0LM=?= In-Reply-To: References: Message-ID: > On 11 Sep 2018, at 07:41, Fedor Dikarev wrote: > > Привет! > > Столкнулся с задачей: хотим чтобы nginx собирал бинарный ответ из > частей. Пример задачи: клиент скачивает из личного кабинета установщик > (exe файл), а мы в конец этого exe файла дописываем json с конфигурацией > для этого клиента. Собирать ответ по кусочкам из подзапросов можно используя njs. http://nginx.org/en/docs/njs/njs_api.html#example function content(r) { r.subrequest(‘/exec-path', r.variables.args, function(reply) { r.return(res.status, res.responseBody + ‘'); }); } дополнительно надо подкрутить http://nginx.org/en/docs/http/ngx_http_core_module.html#subrequest_output_buffer_size что бы весь файл влез в тело подзапроса. > И собственно при первом запуске пользователю не надо > вбивать адреса серверов и другие базовые настройки, все уже на месте. > > Собственно можно ли через SSI собирать бинарные ответы? > > Или можно ли как-то из своего скрипта сделать chunked ответ, где через > X-Accel-Redirect отдать первую бинарную часть ответа, а потом выдать > контент с конфигурацией? > -- > Fedor Dikarev > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Tue Sep 11 07:05:52 2018 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 11 Sep 2018 12:05:52 +0500 Subject: OCSP stapling in Nginx >=1.3.7 In-Reply-To: <866bd03cc42474c195e1fddca4df67b9.NginxMailingListRussian@forum.nginx.org> References: <866bd03cc42474c195e1fddca4df67b9.NginxMailingListRussian@forum.nginx.org> Message-ID: вт, 11 сент. 2018 г. в 2:01, ngnx8810773a83 : > > у клиентов может быть неправильное время (например, они так могут делать > > при вводе документов в 1С) > > если вы им отдадите ocsp stapling, то с точки зрения браузера сертификат > > невалиден, и почему-то > > браузеры так запрограммированы, что кнопки "игнорировать, покажите мне > уже > > > сайт" у клиента не будет. > > Я думаю они уже в курсе, что если они время сдвинули больше чем на > несколько > дней, то пол интернета у них не работает., не пускает в АД, да и не совсем > понятно, пускает ли в mssql если там доменная аваторизация... Кажется > сейчас > проводки задним числом без проблем бьются в бухгалтерии, которая не имеет > вообще прав менять время на компе .. вот уж не знаю как они это делают. . > если на сайте секртифкат Letsencrypt, то у него раз в пару месяцев новый > сертификат, в котором написано что он выдан вот только что, и все браузеры > с > открученным назад временем бутут на него точно также вопить. (он ставится > роботом,и появляется на сайте не позднее пары минут после выдачи. даже есди > это происходит в 3 часа ночи, то на сайт все одно ктото может заходить. > Кажется это не проблема сейчас. Ни разу не слышал чтобы на это жаловались.) > вы правы, это явление экзотическое. на практике можно заметить, если у вас пользователей 10^5 и выше > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,281119,281148#msg-281148 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Tue Sep 11 07:08:47 2018 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 11 Sep 2018 12:08:47 +0500 Subject: =?UTF-8?B?UmU6IFNTSSDQtNC70Y8g0LHQuNC90LDRgNC90YvRhSDQtNCw0L3QvdGL0YUg0Lg=?= =?UTF-8?B?0LvQuCDQsNC90LDQu9C+0LM=?= In-Reply-To: References: Message-ID: вт, 11 сент. 2018 г. в 9:42, Fedor Dikarev : > Привет! > > Столкнулся с задачей: хотим чтобы nginx собирал бинарный ответ из > частей. Пример задачи: клиент скачивает из личного кабинета установщик > (exe файл), а мы в конец этого exe файла дописываем json с конфигурацией > установщики в виде exe считаются небезопасными из-за dll hijacking (например, вот тут разобрано: https://portableapps.com/node/54917 ) если у вас exe с цифровой подписью, то дописать в конец не получится. если без подписи - вас пользователи замучают "у меня виндовс ругается на недоверенный файл" кажется, лучшим вариантом было бы привязка программы к некому feed, откуда бы программа скачивала настройки > для этого клиента. И собственно при первом запуске пользователю не надо > вбивать адреса серверов и другие базовые настройки, все уже на месте. > > Собственно можно ли через SSI собирать бинарные ответы? > > Или можно ли как-то из своего скрипта сделать chunked ответ, где через > X-Accel-Redirect отдать первую бинарную часть ответа, а потом выдать > контент с конфигурацией? > -- > Fedor Dikarev > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From gmm на csdoc.com Tue Sep 11 08:10:09 2018 From: gmm на csdoc.com (Gena Makhomed) Date: Tue, 11 Sep 2018 11:10:09 +0300 Subject: OCSP stapling in Nginx >=1.3.7 In-Reply-To: <20180911032109.GK56558@mdounin.ru> References: <1240491d-0262-b7de-b4cf-a8e29f7274f9@csdoc.com> <20180910130419.GC56558@mdounin.ru> <20180911032109.GK56558@mdounin.ru> Message-ID: On 11.09.2018 6:21, Maxim Dounin wrote: >>> Кроме того, в некоторых случаях для проверки может хватить >>> сертификатов, уже присутствующих в цепочке сертификата (по идее >>> должно хватать issuer cert, которые есть в цепочке почти всегда, >>> но, к сожалению, соответствующие функции в OpenSSL, cкажем так, >>> оставляют желать - и это, собственно, основная причина, почему >>> ssl_stapling_verify не используется по умолчанию). >> >> Но ведь SSL сертификаты - это обычные текстовые файлы. >> Например, если для сайта example.com сравнить два файла >> >> /etc/letsencrypt/live/example.com/fullchain.pem >> /etc/letsencrypt/live/example.com/chain.pem >> >> то видно что файл chain.pem равен файлу fullchain.pem >> плюс дополнительный сертификат сайта на самом верху. >> >> Можно ли сделать для директивы ssl_trusted_certificate параметр auto >> который будет означать автоматическое получение файла chain.pem путем >> вырезания самого первого сертификата из файла fullchain.pem? >> >> В таком случае можно было бы сделать значением по-умолчанию >> ssl_trusted_certificate auto; и ssl_stapling_verify on; >> И веб-сервер nginx тогда будет "Secure by default". >> >> Хотя, проверка клиентских сертификатов и проверка ответов OCSP >> - это две совсем разные задачи, странно что для них используется >> в nginx одна и та же директива ssl_trusted_certificate. >> >> Не лучше ли было бы для этих двух разных задач >> иметь и две разные директивы? > Лучше всего - сделать так, чтобы OpenSSL научился проверять > OCSP-ответы не полной цепочкой сертификатов вплоть до доверенного > root'а, а ровно так, как и должно быть по стандарту - с помощью > одного только сертификата issuer'а. Тогда проблема исчезнет. А разработчики OpenSSL разве знают об этой проблеме? На гитхабе https://github.com/openssl/openssl/issues я не нашел issue в которой бы описывалась эта проблема. Но даже если вдруг новые версии OpenSSL научатся проверять OCSP-ответы с помощью одного только сертификата issuer'а - проблема не исчезнет. Потому что останется огромное количество операционных систем, в которых будет установлена старая версия OpenSSL, например, CentOS/RHEL. Новые версии этой системы выходят очень редко. И потребуется как минимум 5-10 лет, прежде чем новые версии OpenSSL вытеснят старые версии OpenSSL из всех дистрибутивов. > Пытаться же изобретать костыли, чтобы решить проблему кривых > интерфейсов OpenSSL - это бессмысленная деятельность, на выходе > которой ничего кроме костылей получиться не может. Просто по > определению. Кроме OpenSSL есть и другие библиотеки, например, BoringSSL - там эта проблема тоже присутствует, насколько я понимаю? И разработчики BoringSSL тоже ничего не знают об этом? -- Best regards, Gena From chipitsine на gmail.com Tue Sep 11 08:15:12 2018 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 11 Sep 2018 13:15:12 +0500 Subject: OCSP stapling in Nginx >=1.3.7 In-Reply-To: References: <1240491d-0262-b7de-b4cf-a8e29f7274f9@csdoc.com> <20180910130419.GC56558@mdounin.ru> <20180911032109.GK56558@mdounin.ru> Message-ID: вт, 11 сент. 2018 г. в 13:10, Gena Makhomed : > On 11.09.2018 6:21, Maxim Dounin wrote: > > >>> Кроме того, в некоторых случаях для проверки может хватить > >>> сертификатов, уже присутствующих в цепочке сертификата (по идее > >>> должно хватать issuer cert, которые есть в цепочке почти всегда, > >>> но, к сожалению, соответствующие функции в OpenSSL, cкажем так, > >>> оставляют желать - и это, собственно, основная причина, почему > >>> ssl_stapling_verify не используется по умолчанию). > >> > >> Но ведь SSL сертификаты - это обычные текстовые файлы. > >> Например, если для сайта example.com сравнить два файла > >> > >> /etc/letsencrypt/live/example.com/fullchain.pem > >> /etc/letsencrypt/live/example.com/chain.pem > >> > >> то видно что файл chain.pem равен файлу fullchain.pem > >> плюс дополнительный сертификат сайта на самом верху. > >> > >> Можно ли сделать для директивы ssl_trusted_certificate параметр auto > >> который будет означать автоматическое получение файла chain.pem путем > >> вырезания самого первого сертификата из файла fullchain.pem? > >> > >> В таком случае можно было бы сделать значением по-умолчанию > >> ssl_trusted_certificate auto; и ssl_stapling_verify on; > >> И веб-сервер nginx тогда будет "Secure by default". > >> > >> Хотя, проверка клиентских сертификатов и проверка ответов OCSP > >> - это две совсем разные задачи, странно что для них используется > >> в nginx одна и та же директива ssl_trusted_certificate. > >> > >> Не лучше ли было бы для этих двух разных задач > >> иметь и две разные директивы? > > > Лучше всего - сделать так, чтобы OpenSSL научился проверять > > OCSP-ответы не полной цепочкой сертификатов вплоть до доверенного > > root'а, а ровно так, как и должно быть по стандарту - с помощью > > одного только сертификата issuer'а. Тогда проблема исчезнет. > > А разработчики OpenSSL разве знают об этой проблеме? > На гитхабе https://github.com/openssl/openssl/issues > я не нашел issue в которой бы описывалась эта проблема. > а вы напишите им. я проверял, это работает > > Но даже если вдруг новые версии OpenSSL научатся проверять OCSP-ответы > с помощью одного только сертификата issuer'а - проблема не исчезнет. > > Потому что останется огромное количество операционных систем, > в которых будет установлена старая версия OpenSSL, например, > CentOS/RHEL. Новые версии этой системы выходят очень редко. > > И потребуется как минимум 5-10 лет, прежде чем новые версии > OpenSSL вытеснят старые версии OpenSSL из всех дистрибутивов. > > > Пытаться же изобретать костыли, чтобы решить проблему кривых > > интерфейсов OpenSSL - это бессмысленная деятельность, на выходе > > которой ничего кроме костылей получиться не может. Просто по > > определению. > > Кроме OpenSSL есть и другие библиотеки, например, BoringSSL > - там эта проблема тоже присутствует, насколько я понимаю? > И разработчики BoringSSL тоже ничего не знают об этом? > > -- > Best regards, > Gena > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From fe на hamilton.rinet.ru Tue Sep 11 09:02:20 2018 From: fe на hamilton.rinet.ru (Fedor Dikarev) Date: Tue, 11 Sep 2018 12:02:20 +0300 Subject: =?UTF-8?B?UmU6IFNTSSDQtNC70Y8g0LHQuNC90LDRgNC90YvRhSDQtNCw0L3QvdGL0YUg0Lg=?= =?UTF-8?B?0LvQuCDQsNC90LDQu9C+0LM=?= In-Reply-To: References: Message-ID: <6a10834a-c887-fde1-be23-c9b439f37907@hamilton.rinet.ru> 11.09.2018 10:08, Илья Шипицин пишет: > > > вт, 11 сент. 2018 г. в 9:42, Fedor Dikarev >: > > Привет! > > Столкнулся с задачей: хотим чтобы nginx собирал бинарный ответ из > частей. Пример задачи: клиент скачивает из личного кабинета установщик > (exe файл), а мы в конец этого exe файла дописываем json с > конфигурацией > > > установщики в виде exe считаются небезопасными из-за dll hijacking > (например, вот тут разобрано: https://portableapps.com/node/54917 ) > > > если у вас exe с цифровой подписью, то дописать в конец не получится. > если без подписи - вас пользователи замучают "у меня виндовс ругается > на недоверенный файл" Файл с подписью. И разработчики утверждают, что подписывается не весь файл целиком, а только ключевые части, которые меняться не будут. И вот тут утверждают тоже самое: > https://stackoverflow.com/questions/47646135/where-is-the-digital-signature-stored-when-code-signing-a-exe-file-in-windows А здесь это подтверждают: > http://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/Authenticode_PE.docx но в любом случае проверю что все ок. Если нет, то придется выносить логику в отдельную программу и переподписывать. > > кажется, лучшим вариантом было бы привязка программы к некому feed, > откуда бы программа > скачивала настройки ну там не только настройки, хотя даже в случае настроек доступ к feed-у, в общем случае, надо как-то авторизовать, да и доступа к интернету может не быть в момент установки. И плюс там не только настройки, но еще брэндирование: в зависимости то того, из какого раздела пользователь скачал установщик, надо подкладывать разные иконки и background-ы. > >   > > для этого клиента. И собственно при первом запуске пользователю не > надо > вбивать адреса серверов и другие базовые настройки, все уже на месте. > > Собственно можно ли через SSI собирать бинарные ответы? > > Или можно ли как-то из своего скрипта сделать chunked ответ, где через > X-Accel-Redirect отдать первую бинарную часть ответа, а потом выдать > контент с конфигурацией? > -- > Fedor Dikarev > _______________________________________________ > 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 ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Tue Sep 11 11:19:21 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 11 Sep 2018 14:19:21 +0300 Subject: =?UTF-8?B?UmU6IFNTSSDQtNC70Y8g0LHQuNC90LDRgNC90YvRhSDQtNCw0L3QvdGL0YUg0Lg=?= =?UTF-8?B?0LvQuCDQsNC90LDQu9C+0LM=?= In-Reply-To: References: Message-ID: <20180911111921.GL56558@mdounin.ru> Hello! On Tue, Sep 11, 2018 at 07:41:57AM +0300, Fedor Dikarev wrote: > Столкнулся с задачей: хотим чтобы nginx собирал бинарный ответ из > частей. Пример задачи: клиент скачивает из личного кабинета установщик > (exe файл), а мы в конец этого exe файла дописываем json с конфигурацией > для этого клиента. И собственно при первом запуске пользователю не надо > вбивать адреса серверов и другие базовые настройки, все уже на месте. > > Собственно можно ли через SSI собирать бинарные ответы? > > Или можно ли как-то из своего скрипта сделать chunked ответ, где через > X-Accel-Redirect отдать первую бинарную часть ответа, а потом выдать > контент с конфигурацией? ЕМНИП, в SSI проблем с бинарными данными нет, и кто-то даже использовал его для сборки бинарных данных. Главное - не вставлять лишних переводов строк между SSI-командами. Ну и плюс есть всякие другие способы создавать подзапросы, включая наиболее простой add_after_body (http://nginx.org/r/add_after_body), там точно никаких проблем с бинарными данными не будет. Основная проблема, которая тут возникает - это неработоспособность range-запросов и соответственно докачки, так как размер ответа заранее неизвестен, да и range-фильтр не очень расчитан на то, чтобы работать с подзапросами. Если отсутствие докачки не пугает - то и хорошо. -- Maxim Dounin http://mdounin.ru/ From mdounin на mdounin.ru Tue Sep 11 12:38:10 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 11 Sep 2018 15:38:10 +0300 Subject: OCSP stapling in Nginx >=1.3.7 In-Reply-To: References: <1240491d-0262-b7de-b4cf-a8e29f7274f9@csdoc.com> <20180910130419.GC56558@mdounin.ru> <20180911032109.GK56558@mdounin.ru> Message-ID: <20180911123810.GM56558@mdounin.ru> Hello! On Tue, Sep 11, 2018 at 11:10:09AM +0300, Gena Makhomed wrote: > > Лучше всего - сделать так, чтобы OpenSSL научился проверять > > OCSP-ответы не полной цепочкой сертификатов вплоть до доверенного > > root'а, а ровно так, как и должно быть по стандарту - с помощью > > одного только сертификата issuer'а. Тогда проблема исчезнет. > > А разработчики OpenSSL разве знают об этой проблеме? > На гитхабе https://github.com/openssl/openssl/issues > я не нашел issue в которой бы описывалась эта проблема. О проблеме писалось ещё до того, как OpenSSL переехал на github, и вроде бы даже был тикет на rt.openssl.org про это. Но я не следил, и не планирую. Этим летом в кои-то веки документировали саму функцию OCSP_basic_verify(), используемую для проверки OCSP-ответов. И если самого факта недостаточно для понимания проблемы, то стоит прочитать эту самую документацию, она доставляет. > Но даже если вдруг новые версии OpenSSL научатся проверять OCSP-ответы > с помощью одного только сертификата issuer'а - проблема не исчезнет. > > Потому что останется огромное количество операционных систем, > в которых будет установлена старая версия OpenSSL, например, > CentOS/RHEL. Новые версии этой системы выходят очень редко. > > И потребуется как минимум 5-10 лет, прежде чем новые версии > OpenSSL вытеснят старые версии OpenSSL из всех дистрибутивов. Никто не мешает не использовать OCSP stapling. Либо же не использовать ocsp_stapling_verify. При разумном поведении браузеров - от отсутствия проверки на стороне nginx'а проблем быть не должно. Если же браузеры по какой-то причине предпочитают вести себя неразумно - что ж, это их выбор. > > Пытаться же изобретать костыли, чтобы решить проблему кривых > > интерфейсов OpenSSL - это бессмысленная деятельность, на выходе > > которой ничего кроме костылей получиться не может. Просто по > > определению. > > Кроме OpenSSL есть и другие библиотеки, например, BoringSSL > - там эта проблема тоже присутствует, насколько я понимаю? > И разработчики BoringSSL тоже ничего не знают об этом? В BoringSSL поддержики OCSP нет вообще. -- Maxim Dounin http://mdounin.ru/ From chipitsine на gmail.com Tue Sep 11 12:45:37 2018 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 11 Sep 2018 17:45:37 +0500 Subject: =?UTF-8?B?UmU6IFNTSSDQtNC70Y8g0LHQuNC90LDRgNC90YvRhSDQtNCw0L3QvdGL0YUg0Lg=?= =?UTF-8?B?0LvQuCDQsNC90LDQu9C+0LM=?= In-Reply-To: <6a10834a-c887-fde1-be23-c9b439f37907@hamilton.rinet.ru> References: <6a10834a-c887-fde1-be23-c9b439f37907@hamilton.rinet.ru> Message-ID: вт, 11 сент. 2018 г. в 14:02, Fedor Dikarev : > 11.09.2018 10:08, Илья Шипицин пишет: > > > > вт, 11 сент. 2018 г. в 9:42, Fedor Dikarev : > >> Привет! >> >> Столкнулся с задачей: хотим чтобы nginx собирал бинарный ответ из >> частей. Пример задачи: клиент скачивает из личного кабинета установщик >> (exe файл), а мы в конец этого exe файла дописываем json с конфигурацией >> > > установщики в виде exe считаются небезопасными из-за dll hijacking > (например, вот тут разобрано: https://portableapps.com/node/54917 ) > > > если у вас exe с цифровой подписью, то дописать в конец не получится. > если без подписи - вас пользователи замучают "у меня виндовс ругается на > недоверенный файл" > > Файл с подписью. И разработчики утверждают, что подписывается не весь файл > целиком, а только ключевые части, которые меняться не будут. > > И вот тут утверждают тоже самое: > > > https://stackoverflow.com/questions/47646135/where-is-the-digital-signature-stored-when-code-signing-a-exe-file-in-windows > > А здесь это подтверждают: > > > http://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/Authenticode_PE.docx > > но в любом случае проверю что все ок. Если нет, то придется выносить > логику в отдельную программу и переподписывать. > > > кажется, лучшим вариантом было бы привязка программы к некому feed, откуда > бы программа > скачивала настройки > > ну там не только настройки, хотя даже в случае настроек доступ к feed-у, в > общем случае, надо как-то авторизовать, да и доступа к интернету может не > быть в момент установки. > > И плюс там не только настройки, но еще брэндирование: в зависимости то > того, из какого раздела пользователь скачал установщик, надо подкладывать > разные иконки и background-ы. > а после того, как вы зарелизите, к вам придут разработчики с просьбой "придумай, как сделать, чтобы клиенты обновились" имхо, можно смотреть в сторону ClickOnce или аналогов > > > >> для этого клиента. И собственно при первом запуске пользователю не надо >> вбивать адреса серверов и другие базовые настройки, все уже на месте. >> >> Собственно можно ли через SSI собирать бинарные ответы? >> >> Или можно ли как-то из своего скрипта сделать chunked ответ, где через >> X-Accel-Redirect отдать первую бинарную часть ответа, а потом выдать >> контент с конфигурацией? >> -- >> Fedor Dikarev >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > _______________________________________________ > nginx-ru mailing listnginx-ru на nginx.orghttp://mailman.nginx.org/mailman/listinfo/nginx-ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From vlad.shabanov на gmail.com Tue Sep 11 12:52:06 2018 From: vlad.shabanov на gmail.com (Vladislav Shabanov) Date: Tue, 11 Sep 2018 15:52:06 +0300 Subject: =?UTF-8?B?UmU6IFNTSSDQtNC70Y8g0LHQuNC90LDRgNC90YvRhSDQtNCw0L3QvdGL0YUg0Lg=?= =?UTF-8?B?0LvQuCDQsNC90LDQu9C+0LM=?= In-Reply-To: References: <6a10834a-c887-fde1-be23-c9b439f37907@hamilton.rinet.ru> Message-ID: <03CF300E-9076-4FB0-9BAE-F6A60EC7E918@gmail.com> Проще всего передавать параметры в имени exe-файла. Браузеры его не портят, сохраняют так, как сервер сказал. Поэтому можно закатать в хвост имени 10-20 байт закодированные в base36. А файл пусть посмотрит, как он называется, и решит, он сегодня gcc или clang :) И докачает остальную инфу по этим 10-20 байтам с сервера. > 11 сент. 2018 г., в 15:45, Илья Шипицин написал(а): > > > > вт, 11 сент. 2018 г. в 14:02, Fedor Dikarev >: > 11.09.2018 10:08, Илья Шипицин пишет: >> >> >> вт, 11 сент. 2018 г. в 9:42, Fedor Dikarev >: >> Привет! >> >> Столкнулся с задачей: хотим чтобы nginx собирал бинарный ответ из >> частей. Пример задачи: клиент скачивает из личного кабинета установщик >> (exe файл), а мы в конец этого exe файла дописываем json с конфигурацией >> >> установщики в виде exe считаются небезопасными из-за dll hijacking >> (например, вот тут разобрано: https://portableapps.com/node/54917 ) >> >> >> если у вас exe с цифровой подписью, то дописать в конец не получится. >> если без подписи - вас пользователи замучают "у меня виндовс ругается на недоверенный файл" ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From fe на hamilton.rinet.ru Tue Sep 11 13:00:12 2018 From: fe на hamilton.rinet.ru (Fedor Dikarev) Date: Tue, 11 Sep 2018 16:00:12 +0300 Subject: =?UTF-8?B?UmU6IFNTSSDQtNC70Y8g0LHQuNC90LDRgNC90YvRhSDQtNCw0L3QvdGL0YUg0Lg=?= =?UTF-8?B?0LvQuCDQsNC90LDQu9C+0LM=?= In-Reply-To: References: <6a10834a-c887-fde1-be23-c9b439f37907@hamilton.rinet.ru> Message-ID: <967991ab-a8cd-2faf-7d1e-3c530e4f7405@hamilton.rinet.ru> 11.09.2018 15:45, Илья Шипицин пишет: > ... > > И плюс там не только настройки, но еще брэндирование: в > зависимости то того, из какого раздела пользователь скачал > установщик, надо подкладывать разные иконки и background-ы. > > > а после того, как вы зарелизите, к вам придут разработчики с просьбой > "придумай, как сделать, чтобы клиенты обновились" > > имхо, можно смотреть в сторону ClickOnce или аналогов Вопрос автообновления клиентов проработан и с ним пока сложностей нет, насколько я знаю. А за ClickOnce спасибо, закину разработчикам: я сам не очень хорошо разбираюсь в теме деплоя windows приложений, мне сложно сказать какие у нас требования и сценарии в этой части. > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From fe на hamilton.rinet.ru Tue Sep 11 13:07:57 2018 From: fe на hamilton.rinet.ru (Fedor Dikarev) Date: Tue, 11 Sep 2018 16:07:57 +0300 Subject: =?UTF-8?B?UmU6IFNTSSDQtNC70Y8g0LHQuNC90LDRgNC90YvRhSDQtNCw0L3QvdGL0YUg0Lg=?= =?UTF-8?B?0LvQuCDQsNC90LDQu9C+0LM=?= In-Reply-To: <03CF300E-9076-4FB0-9BAE-F6A60EC7E918@gmail.com> References: <6a10834a-c887-fde1-be23-c9b439f37907@hamilton.rinet.ru> <03CF300E-9076-4FB0-9BAE-F6A60EC7E918@gmail.com> Message-ID: <4f89525d-6c10-3718-4dfb-b4419eb05c7f@hamilton.rinet.ru> Сейчас примерно так и сделали: > add_header Content-Disposition $header_content_disposition; > set $header_content_disposition 'attachment; > filename="$request_basename.$cnf_map.exe"'; Но маркетинг жалуется, что пользователей пугают такие имена. Плюс брэндирование таким методом не запихнешь: картинки слишком большие :-( 11.09.2018 15:52, Vladislav Shabanov пишет: > Проще всего передавать параметры в имени exe-файла. Браузеры его не > портят, сохраняют так, как сервер сказал.  > Поэтому можно закатать в хвост имени 10-20 байт закодированные в base36. > А файл пусть посмотрит, как он называется, и решит, он сегодня gcc или > clang :) > И докачает остальную инфу по этим 10-20 байтам с сервера. > > >> 11 сент. 2018 г., в 15:45, Илья Шипицин > > написал(а): >> >> >> >> вт, 11 сент. 2018 г. в 14:02, Fedor Dikarev > >: >> >> 11.09.2018 10:08, Илья Шипицин пишет: >>> >>> >>> вт, 11 сент. 2018 г. в 9:42, Fedor Dikarev >> >: >>> >>> Привет! >>> >>> Столкнулся с задачей: хотим чтобы nginx собирал бинарный >>> ответ из >>> частей. Пример задачи: клиент скачивает из личного кабинета >>> установщик >>> (exe файл), а мы в конец этого exe файла дописываем json с >>> конфигурацией >>> >>> >>> установщики в виде exe считаются небезопасными из-за dll hijacking >>> (например, вот тут разобрано: https://portableapps.com/node/54917 ) >>> >>> >>> если у вас exe с цифровой подписью, то дописать в конец не >>> получится. >>> если без подписи - вас пользователи замучают "у меня виндовс >>> ругается на недоверенный файл" >> > > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From gmm на csdoc.com Tue Sep 11 14:40:19 2018 From: gmm на csdoc.com (Gena Makhomed) Date: Tue, 11 Sep 2018 17:40:19 +0300 Subject: OCSP stapling in Nginx >=1.3.7 In-Reply-To: <20180911123810.GM56558@mdounin.ru> References: <1240491d-0262-b7de-b4cf-a8e29f7274f9@csdoc.com> <20180910130419.GC56558@mdounin.ru> <20180911032109.GK56558@mdounin.ru> <20180911123810.GM56558@mdounin.ru> Message-ID: <1d4bed82-2b3d-b6a4-ba6d-16e8872134ad@csdoc.com> On 11.09.2018 15:38, Maxim Dounin wrote: >>> Лучше всего - сделать так, чтобы OpenSSL научился проверять >>> OCSP-ответы не полной цепочкой сертификатов вплоть до доверенного >>> root'а, а ровно так, как и должно быть по стандарту - с помощью >>> одного только сертификата issuer'а. Тогда проблема исчезнет. >> А разработчики OpenSSL разве знают об этой проблеме? >> На гитхабе https://github.com/openssl/openssl/issues >> я не нашел issue в которой бы описывалась эта проблема. > О проблеме писалось ещё до того, как OpenSSL переехал на github, > и вроде бы даже был тикет на rt.openssl.org про это. > Но я не следил, и не планирую. > Этим летом в кои-то веки документировали саму функцию > OCSP_basic_verify(), используемую для проверки OCSP-ответов. И > если самого факта недостаточно для понимания проблемы, то стоит > прочитать эту самую документацию, она доставляет. Почитал документацию https://www.openssl.org/docs/manmaster/man3/OCSP_basic_verify.html там говорится о флаге OCSP_TRUSTOTHER, смысл примерно такой: : ... or if the signer certificate was found in certs and : the flags contain OCSP_TRUSTOTHER. Otherwise the function : continues by validating the signer certificate. О том же написано и в CHANGELOG: *) New OCSP verify flag OCSP_TRUSTOTHER. When set the "other" certificates passed by the function are trusted implicitly. If any of them signed the response then it is assumed to be valid and is not verified. Насколько я понимаю, это и есть та самая проверка с помощью одного только сертификата issuer'а, о которой Вы говорите? Если это то, что надо, то сейчас уже ничто не мешает сделать в nginx директиву ocsp_stapling_verify включенной по-умолчанию? И для ее работы не нужно будет прописывать ssl_trusted_certificate? >> Но даже если вдруг новые версии OpenSSL научатся проверять OCSP-ответы >> с помощью одного только сертификата issuer'а - проблема не исчезнет. >> Потому что останется огромное количество операционных систем, >> в которых будет установлена старая версия OpenSSL, например, >> CentOS/RHEL. Новые версии этой системы выходят очень редко. >> И потребуется как минимум 5-10 лет, прежде чем новые версии >> OpenSSL вытеснят старые версии OpenSSL из всех дистрибутивов. > Никто не мешает не использовать OCSP stapling. Либо же не > использовать ocsp_stapling_verify. При разумном поведении > браузеров - от отсутствия проверки на стороне nginx'а проблем быть > не должно. Если же браузеры по какой-то причине предпочитают > вести себя неразумно - что ж, это их выбор. ocsp_stapling_verify в nginx можно без проблем использовать и прямо сейчас, только для этого надо прописать дополнительно ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem; Насколько я понял из предыдущего обсуждения, нет разумных причин, чтобы выключать использование OCSP stapling и ocsp_stapling_verify. И вместе с тем, есть причины, чтобы их включать: OCSP stapling - сайт у клиентов будет открываться быстрее. ocsp_stapling_verify - не будет проблем с неразумными браузерами. -- Best regards, Gena From chipitsine на gmail.com Tue Sep 11 15:04:52 2018 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 11 Sep 2018 20:04:52 +0500 Subject: OCSP stapling in Nginx >=1.3.7 In-Reply-To: <1d4bed82-2b3d-b6a4-ba6d-16e8872134ad@csdoc.com> References: <1240491d-0262-b7de-b4cf-a8e29f7274f9@csdoc.com> <20180910130419.GC56558@mdounin.ru> <20180911032109.GK56558@mdounin.ru> <20180911123810.GM56558@mdounin.ru> <1d4bed82-2b3d-b6a4-ba6d-16e8872134ad@csdoc.com> Message-ID: вт, 11 сент. 2018 г. в 19:40, Gena Makhomed : > On 11.09.2018 15:38, Maxim Dounin wrote: > > >>> Лучше всего - сделать так, чтобы OpenSSL научился проверять > >>> OCSP-ответы не полной цепочкой сертификатов вплоть до доверенного > >>> root'а, а ровно так, как и должно быть по стандарту - с помощью > >>> одного только сертификата issuer'а. Тогда проблема исчезнет. > > >> А разработчики OpenSSL разве знают об этой проблеме? > >> На гитхабе https://github.com/openssl/openssl/issues > >> я не нашел issue в которой бы описывалась эта проблема. > > > О проблеме писалось ещё до того, как OpenSSL переехал на github, > > и вроде бы даже был тикет на rt.openssl.org про это. > > Но я не следил, и не планирую. > > > Этим летом в кои-то веки документировали саму функцию > > OCSP_basic_verify(), используемую для проверки OCSP-ответов. И > > если самого факта недостаточно для понимания проблемы, то стоит > > прочитать эту самую документацию, она доставляет. > > Почитал документацию > https://www.openssl.org/docs/manmaster/man3/OCSP_basic_verify.html > там говорится о флаге OCSP_TRUSTOTHER, смысл примерно такой: > > : ... or if the signer certificate was found in certs and > : the flags contain OCSP_TRUSTOTHER. Otherwise the function > : continues by validating the signer certificate. > > О том же написано и в CHANGELOG: > > *) New OCSP verify flag OCSP_TRUSTOTHER. When set the "other" > certificates passed by the function are trusted implicitly. > If any of them signed the response then it is assumed > to be valid and is not verified. > > Насколько я понимаю, это и есть та самая проверка с помощью > одного только сертификата issuer'а, о которой Вы говорите? > > Если это то, что надо, то сейчас уже ничто не мешает сделать > в nginx директиву ocsp_stapling_verify включенной по-умолчанию? > И для ее работы не нужно будет прописывать ssl_trusted_certificate? > > >> Но даже если вдруг новые версии OpenSSL научатся проверять OCSP-ответы > >> с помощью одного только сертификата issuer'а - проблема не исчезнет. > > >> Потому что останется огромное количество операционных систем, > >> в которых будет установлена старая версия OpenSSL, например, > >> CentOS/RHEL. Новые версии этой системы выходят очень редко. > > >> И потребуется как минимум 5-10 лет, прежде чем новые версии > >> OpenSSL вытеснят старые версии OpenSSL из всех дистрибутивов. > > > Никто не мешает не использовать OCSP stapling. Либо же не > > использовать ocsp_stapling_verify. При разумном поведении > > браузеров - от отсутствия проверки на стороне nginx'а проблем быть > > не должно. Если же браузеры по какой-то причине предпочитают > > вести себя неразумно - что ж, это их выбор. > > ocsp_stapling_verify в nginx можно без проблем использовать > и прямо сейчас, только для этого надо прописать дополнительно > ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem; > > Насколько я понял из предыдущего обсуждения, нет разумных причин, > чтобы выключать использование OCSP stapling и ocsp_stapling_verify. > > И вместе с тем, есть причины, чтобы их включать: > OCSP stapling - сайт у клиентов будет открываться быстрее. > ocsp_stapling_verify - не будет проблем с неразумными браузерами. > когда OCSP сломался у Lets Encrypt, помнится, проблемы были у тех, у кого они не должны были быть https://community.letsencrypt.org/t/what-if-lets-encrypt-goes-down-ocsp-stapling/22369/2 > > -- > Best regards, > Gena > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Tue Sep 11 15:59:20 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 11 Sep 2018 18:59:20 +0300 Subject: OCSP stapling in Nginx >=1.3.7 In-Reply-To: <1d4bed82-2b3d-b6a4-ba6d-16e8872134ad@csdoc.com> References: <1240491d-0262-b7de-b4cf-a8e29f7274f9@csdoc.com> <20180910130419.GC56558@mdounin.ru> <20180911032109.GK56558@mdounin.ru> <20180911123810.GM56558@mdounin.ru> <1d4bed82-2b3d-b6a4-ba6d-16e8872134ad@csdoc.com> Message-ID: <20180911155920.GP56558@mdounin.ru> Hello! On Tue, Sep 11, 2018 at 05:40:19PM +0300, Gena Makhomed wrote: > On 11.09.2018 15:38, Maxim Dounin wrote: > > >>> Лучше всего - сделать так, чтобы OpenSSL научился проверять > >>> OCSP-ответы не полной цепочкой сертификатов вплоть до доверенного > >>> root'а, а ровно так, как и должно быть по стандарту - с помощью > >>> одного только сертификата issuer'а. Тогда проблема исчезнет. > > >> А разработчики OpenSSL разве знают об этой проблеме? > >> На гитхабе https://github.com/openssl/openssl/issues > >> я не нашел issue в которой бы описывалась эта проблема. > > > О проблеме писалось ещё до того, как OpenSSL переехал на github, > > и вроде бы даже был тикет на rt.openssl.org про это. > > Но я не следил, и не планирую. > > > Этим летом в кои-то веки документировали саму функцию > > OCSP_basic_verify(), используемую для проверки OCSP-ответов. И > > если самого факта недостаточно для понимания проблемы, то стоит > > прочитать эту самую документацию, она доставляет. > > Почитал документацию > https://www.openssl.org/docs/manmaster/man3/OCSP_basic_verify.html > там говорится о флаге OCSP_TRUSTOTHER, смысл примерно такой: > > : ... or if the signer certificate was found in certs and > : the flags contain OCSP_TRUSTOTHER. Otherwise the function > : continues by validating the signer certificate. > > О том же написано и в CHANGELOG: > > *) New OCSP verify flag OCSP_TRUSTOTHER. When set the "other" > certificates passed by the function are trusted implicitly. > If any of them signed the response then it is assumed > to be valid and is not verified. > > Насколько я понимаю, это и есть та самая проверка с помощью > одного только сертификата issuer'а, о которой Вы говорите? > > Если это то, что надо, то сейчас уже ничто не мешает сделать > в nginx директиву ocsp_stapling_verify включенной по-умолчанию? > И для ее работы не нужно будет прописывать ssl_trusted_certificate? В зависимости от того, каким сертификатом подписан OCSP-ответ - этого может быть достаточно или нет. RFC 6960 допускает два варианта подписи в OCSP-ответах: - issuer подписывает OCSP-ответ сам; или - issuer выпускает сертификат, которым подписываются OCSP-ответы (и этот сертификат включается в OCSP-ответ). В обоих случаях для проверки OCSP-ответа достаточно знать issuer'а, однако второй случай в OpenSSL не работает (впрочем, я давно не порверял; но если верить "документации", в этом месте ничего не зименилось). При этом по понятным причинам мало кто использует собственно CA для подписи OCSP-ответов, соответственно не работает это приблизительно всегда. > >> Но даже если вдруг новые версии OpenSSL научатся проверять OCSP-ответы > >> с помощью одного только сертификата issuer'а - проблема не исчезнет. > > >> Потому что останется огромное количество операционных систем, > >> в которых будет установлена старая версия OpenSSL, например, > >> CentOS/RHEL. Новые версии этой системы выходят очень редко. > > >> И потребуется как минимум 5-10 лет, прежде чем новые версии > >> OpenSSL вытеснят старые версии OpenSSL из всех дистрибутивов. > > > Никто не мешает не использовать OCSP stapling. Либо же не > > использовать ocsp_stapling_verify. При разумном поведении > > браузеров - от отсутствия проверки на стороне nginx'а проблем быть > > не должно. Если же браузеры по какой-то причине предпочитают > > вести себя неразумно - что ж, это их выбор. > > ocsp_stapling_verify в nginx можно без проблем использовать > и прямо сейчас, только для этого надо прописать дополнительно > ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem; > > Насколько я понял из предыдущего обсуждения, нет разумных причин, > чтобы выключать использование OCSP stapling и ocsp_stapling_verify. > > И вместе с тем, есть причины, чтобы их включать: > OCSP stapling - сайт у клиентов будет открываться быстрее. > ocsp_stapling_verify - не будет проблем с неразумными браузерами. Про "быстрее" - есть нюансы. В частности, OCSP-ответ отправляется клиенту, пытающемуся использовать OCSP stapling, в каждом SSL handshake'е (а это местами может быть больно с точки зрения latency, не говоря уже про трафик), в то время как в значительной части случаев он клиенту на самом деле не нужен (например, уже есть в кэше). Про verify - тоже есть нюансы. Дискуссия, если я её правильно понял, как раз о том, что включать verify обходится дороже с административной точки зрения, чем хотелось бы. При этом плюсы - призрачны, ибо защищают от атак, которых на практике не бывает (а если бы они были - браузеры бы давно исправились). Единственное несомненное преимущество OCSP stapling'а - это меньшая нагрузка на инфраструктуру CA. -- Maxim Dounin http://mdounin.ru/ From gmm на csdoc.com Tue Sep 11 19:00:05 2018 From: gmm на csdoc.com (Gena Makhomed) Date: Tue, 11 Sep 2018 22:00:05 +0300 Subject: OCSP stapling in Nginx >=1.3.7 In-Reply-To: <20180911155920.GP56558@mdounin.ru> References: <1240491d-0262-b7de-b4cf-a8e29f7274f9@csdoc.com> <20180910130419.GC56558@mdounin.ru> <20180911032109.GK56558@mdounin.ru> <20180911123810.GM56558@mdounin.ru> <1d4bed82-2b3d-b6a4-ba6d-16e8872134ad@csdoc.com> <20180911155920.GP56558@mdounin.ru> Message-ID: <01c41dde-d08a-df21-e423-63659c6dd7ad@csdoc.com> On 11.09.2018 18:59, Maxim Dounin wrote: >>>>> Лучше всего - сделать так, чтобы OpenSSL научился проверять >>>>> OCSP-ответы не полной цепочкой сертификатов вплоть до доверенного >>>>> root'а, а ровно так, как и должно быть по стандарту - с помощью >>>>> одного только сертификата issuer'а. Тогда проблема исчезнет. [...] >> https://www.openssl.org/docs/manmaster/man3/OCSP_basic_verify.html >> там говорится о флаге OCSP_TRUSTOTHER, смысл примерно такой: >> >> : ... or if the signer certificate was found in certs and >> : the flags contain OCSP_TRUSTOTHER. Otherwise the function >> : continues by validating the signer certificate. >> >> О том же написано и в CHANGELOG: >> >> *) New OCSP verify flag OCSP_TRUSTOTHER. When set the "other" >> certificates passed by the function are trusted implicitly. >> If any of them signed the response then it is assumed >> to be valid and is not verified. >> >> Насколько я понимаю, это и есть та самая проверка с помощью >> одного только сертификата issuer'а, о которой Вы говорите? >> >> Если это то, что надо, то сейчас уже ничто не мешает сделать >> в nginx директиву ocsp_stapling_verify включенной по-умолчанию? >> И для ее работы не нужно будет прописывать ssl_trusted_certificate? > В зависимости от того, каким сертификатом подписан OCSP-ответ - > этого может быть достаточно или нет. RFC 6960 допускает два > варианта подписи в OCSP-ответах: > - issuer подписывает OCSP-ответ сам; или > - issuer выпускает сертификат, которым подписываются OCSP-ответы > (и этот сертификат включается в OCSP-ответ). На самом деле - там три варианта, вот еще третий: - a Trusted Responder whose public key is trusted by the requestor Подробности здесь: https://tools.ietf.org/html/rfc6960#section-2.2 > В обоих случаях для проверки OCSP-ответа достаточно знать > issuer'а, однако второй случай в OpenSSL не работает (впрочем, я > давно не порверял; но если верить "документации", в этом месте > ничего не зименилось). При этом по понятным причинам мало кто > использует собственно CA для подписи OCSP-ответов, соответственно > не работает это приблизительно всегда. В RFC 6960 написано по поводу сертификата из второго случая: : This certificate MUST be issued directly : by the CA that is identified in the request. https://tools.ietf.org/html/rfc6960#section-4.2.2.2 Как это может не работать в OpenSSL, если сертификат, которым подписываются OCSP-ответы является валидным и проверка идет полной цепочкой сертификатов вплоть до доверенного root'а? Кстати, мне так и не удалось найти в стандарте RFC 6960 требования проверять OCSP-ответ с помощью одного только сертификата issuer'а. >> ocsp_stapling_verify в nginx можно без проблем использовать >> и прямо сейчас, только для этого надо прописать дополнительно >> ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem; >> >> Насколько я понял из предыдущего обсуждения, нет разумных причин, >> чтобы выключать использование OCSP stapling и ocsp_stapling_verify. >> >> И вместе с тем, есть причины, чтобы их включать: >> OCSP stapling - сайт у клиентов будет открываться быстрее. >> ocsp_stapling_verify - не будет проблем с неразумными браузерами. > Про "быстрее" - есть нюансы. В частности, OCSP-ответ отправляется > клиенту, пытающемуся использовать OCSP stapling, в каждом > SSL handshake'е (а это местами может быть больно с точки зрения latency, не > говоря уже про трафик), в то время как в значительной части > случаев он клиенту на самом деле не нужен (например, уже есть в > кэше). Открытие сайта по HTTPS без OCSP Stapling подразумевает, что браузер сам будет проверять не отозван ли сертификат сервера. Клиент в это время будет сидеть перед монитором и ждать открытия сайта. https://blog.cloudflare.com/ocsp-stapling-how-cloudflare-just-made-ssl-30/ OCSP Stapling: How CloudFlare Just Made SSL 30% Faster > Про verify - тоже есть нюансы. Дискуссия, если я её правильно > понял, как раз о том, что включать verify обходится дороже с > административной точки зрения, чем хотелось бы. При этом плюсы - > призрачны, ибо защищают от атак, которых на практике не бывает > (а если бы они были - браузеры бы давно исправились). В начале дискуссии вопрос был о том, почему для того чтобы директива ssl_stapling_verify on; нормально работала необходимо также прописывать ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem; если содержимое файла chain.pem можно получить из файла fullchain.pem выбросив оттуда первый сертификат, который является сертификатом сайта? Кроме необходимости прописывать совсем лишние директивы в конфиге есть и более серьезная проблема - директива ssl_trusted_certificate сейчас исполняет две совершенно различные роли вместо одной, как раньше. > Единственное несомненное преимущество OCSP stapling'а - это > меньшая нагрузка на инфраструктуру CA И на 30% более быстрое открытие сайта клиентом, если на сервере используется OCSP stapling. P.S. Сегодня вышел релиз OpenSSL 1.1.1 с поддержкой TLSv1.3 https://www.openssl.org/blog/blog/2018/09/11/release111/ -- Best regards, Gena From mdounin на mdounin.ru Wed Sep 12 14:36:06 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 12 Sep 2018 17:36:06 +0300 Subject: OCSP stapling in Nginx >=1.3.7 In-Reply-To: <01c41dde-d08a-df21-e423-63659c6dd7ad@csdoc.com> References: <1240491d-0262-b7de-b4cf-a8e29f7274f9@csdoc.com> <20180910130419.GC56558@mdounin.ru> <20180911032109.GK56558@mdounin.ru> <20180911123810.GM56558@mdounin.ru> <1d4bed82-2b3d-b6a4-ba6d-16e8872134ad@csdoc.com> <20180911155920.GP56558@mdounin.ru> <01c41dde-d08a-df21-e423-63659c6dd7ad@csdoc.com> Message-ID: <20180912143606.GQ56558@mdounin.ru> Hello! On Tue, Sep 11, 2018 at 10:00:05PM +0300, Gena Makhomed wrote: > On 11.09.2018 18:59, Maxim Dounin wrote: > > >>>>> Лучше всего - сделать так, чтобы OpenSSL научился проверять > >>>>> OCSP-ответы не полной цепочкой сертификатов вплоть до доверенного > >>>>> root'а, а ровно так, как и должно быть по стандарту - с помощью > >>>>> одного только сертификата issuer'а. Тогда проблема исчезнет. > > [...] > > >> https://www.openssl.org/docs/manmaster/man3/OCSP_basic_verify.html > >> там говорится о флаге OCSP_TRUSTOTHER, смысл примерно такой: > >> > >> : ... or if the signer certificate was found in certs and > >> : the flags contain OCSP_TRUSTOTHER. Otherwise the function > >> : continues by validating the signer certificate. > >> > >> О том же написано и в CHANGELOG: > >> > >> *) New OCSP verify flag OCSP_TRUSTOTHER. When set the "other" > >> certificates passed by the function are trusted implicitly. > >> If any of them signed the response then it is assumed > >> to be valid and is not verified. > >> > >> Насколько я понимаю, это и есть та самая проверка с помощью > >> одного только сертификата issuer'а, о которой Вы говорите? > >> > >> Если это то, что надо, то сейчас уже ничто не мешает сделать > >> в nginx директиву ocsp_stapling_verify включенной по-умолчанию? > >> И для ее работы не нужно будет прописывать ssl_trusted_certificate? > > > В зависимости от того, каким сертификатом подписан OCSP-ответ - > > этого может быть достаточно или нет. RFC 6960 допускает два > > варианта подписи в OCSP-ответах: > > > - issuer подписывает OCSP-ответ сам; или > > - issuer выпускает сертификат, которым подписываются OCSP-ответы > > (и этот сертификат включается в OCSP-ответ). > > На самом деле - там три варианта, вот еще третий: > > - a Trusted Responder whose public key is trusted by the requestor > > Подробности здесь: https://tools.ietf.org/html/rfc6960#section-2.2 Что, насколько я понимаю, предполагает out-of-band trust, и не распространяется на ответы от собственно OCSP-сервиса CA. В реальной жизни - это работать не будет. В 4.2.2.2, описывающем поведение CA при подписи OCSP-ответов, закрытый список из двух пунктов. > > В обоих случаях для проверки OCSP-ответа достаточно знать > > issuer'а, однако второй случай в OpenSSL не работает (впрочем, я > > давно не порверял; но если верить "документации", в этом месте > > ничего не зименилось). При этом по понятным причинам мало кто > > использует собственно CA для подписи OCSP-ответов, соответственно > > не работает это приблизительно всегда. > > В RFC 6960 написано по поводу сертификата из второго случая: > > : This certificate MUST be issued directly > : by the CA that is identified in the request. > > https://tools.ietf.org/html/rfc6960#section-4.2.2.2 > > Как это может не работать в OpenSSL, если сертификат, которым > подписываются OCSP-ответы является валидным и проверка идет > полной цепочкой сертификатов вплоть до доверенного root'а? Именно в "до доверенного root'а" и состоит проблема. Для проверки подписи OCSP-ответа достаточно знать issuer'а - обычно это промежуточный CA, и так или иначе лежит в цепочке на сервере (и его так или иначе надо знать, чтобы сформировать OCSP-запрос). Знать всю цепочку вплоть до root'а - серверу при этом не нужно. Однако приходится, потому что в противном случае OpenSSL не может проверить OCSP-ответ. > Кстати, мне так и не удалось найти в стандарте RFC 6960 требования > проверять OCSP-ответ с помощью одного только сертификата issuer'а. Потому что это не требование - а, напротив, отсутствие требования признавать что-то, что подписано так, что проверка OCSP-ответа с помощью только issuer'а оказывается невозможна. В частности, в пункте 4.2.2.2 вслед за "MUST be issued directly" сказано так: Note: For backwards compatibility with RFC 2560 [RFC2560], it is not prohibited to issue a certificate for an Authorized Responder using a different issuing key than the key used to issue the certificate being checked for revocation. However, such a practice is strongly discouraged, since clients are not required to recognize a responder with such a certificate as an Authorized Responder. То есть если OCSP-ответ не подписан напрямую issuer'ом (и тогда проверка подписи тривиальна, response -> issuer) или выпущенным им сертификатом (и тогда проверка подписи чуть сложнее, но тоже проста, response -> responder -> issuer), то никто ничего не обещал. > >> ocsp_stapling_verify в nginx можно без проблем использовать > >> и прямо сейчас, только для этого надо прописать дополнительно > >> ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem; > >> > >> Насколько я понял из предыдущего обсуждения, нет разумных причин, > >> чтобы выключать использование OCSP stapling и ocsp_stapling_verify. > >> > >> И вместе с тем, есть причины, чтобы их включать: > >> OCSP stapling - сайт у клиентов будет открываться быстрее. > >> ocsp_stapling_verify - не будет проблем с неразумными браузерами. > > > Про "быстрее" - есть нюансы. В частности, OCSP-ответ отправляется > > клиенту, пытающемуся использовать OCSP stapling, в каждом > > SSL handshake'е (а это местами может быть больно с точки зрения latency, не > > говоря уже про трафик), в то время как в значительной части > > случаев он клиенту на самом деле не нужен (например, уже есть в > > кэше). > > Открытие сайта по HTTPS без OCSP Stapling подразумевает, > что браузер сам будет проверять не отозван ли сертификат сервера. > Клиент в это время будет сидеть перед монитором и ждать открытия сайта. Или не будет - см. пример в скобках. > https://blog.cloudflare.com/ocsp-stapling-how-cloudflare-just-made-ssl-30/ > OCSP Stapling: How CloudFlare Just Made SSL 30% Faster Какой-либо фактической информации, позволяющей сравнить случаи использования OCSP stapling и его не использования, эта статья не содержит. А о том, что ребята в CloudFlare обладают выдающимися моральными качествами и способны написать статью о том, как они включили разработанную мной функциональность в nginx'е без единой ссылки на меня и nginx - я и так в курсе, спасибо. > > Про verify - тоже есть нюансы. Дискуссия, если я её правильно > > понял, как раз о том, что включать verify обходится дороже с > > административной точки зрения, чем хотелось бы. При этом плюсы - > > призрачны, ибо защищают от атак, которых на практике не бывает > > (а если бы они были - браузеры бы давно исправились). > > В начале дискуссии вопрос был о том, почему для того чтобы директива > ssl_stapling_verify on; нормально работала необходимо также прописывать > ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem; > если содержимое файла chain.pem можно получить из файла fullchain.pem > выбросив оттуда первый сертификат, который является сертификатом сайта? И ответ на этот вопрос - потому что интерфейс проверки сертификатов кривой, и требует массы дополнительных приседаний, чтобы работать. Именно поэтому по умолчанию используется ssl_stapling_verify off. Кроме того, если у вас в ssl_certificate указана полная цепочка, включая сертификат root CA, то это неправильно. Root-сертификат у клиентов и так есть, отправлять клиентам его - бессмысленная трата ресурсов, соответственно и включать его в цепочку в ssl_certificate - не надо. Если же root-сертификата в цепочке нет, то получить из ssl_certificate полную цепочку, включая root, по очевидным причинам не получится, и ssl_stapling_verify работать не будет. > Кроме необходимости прописывать совсем лишние директивы в конфиге > есть и более серьезная проблема - директива ssl_trusted_certificate > сейчас исполняет две совершенно различные роли вместо одной, как раньше. Директива ssl_trusted_certificate появилась фактически в рамках работы над OCSP stapling, так что "как раньше" это странное утверждение. > > Единственное несомненное преимущество OCSP stapling'а - это > > меньшая нагрузка на инфраструктуру CA > И на 30% более быстрое открытие сайта клиентом, > если на сервере используется OCSP stapling. Это откровенное маркетинговое передёргивание, не учитывающее никаких других эффектов от OCSP stapling'а, кроме собственно "улучшений". Не говоря уже о том, что: а) Цифры в исходном посте Mike Belshe - это не статистика, а конкретный trial с конкретным сервером и конкретным CA, и всё это в мобильной сети. б) Ребята в CloudFlare насчитали 30%, сложив время всех операций, относящихся к OCSP. Меж тем, там будет максимум 16% даже без учёта увеличения времени handshake'а за счёт OCSP-ответов, так как OCSP stapling работает только для конечного сертификата, а цифры приводятся с учётом проверки отзыва промежуточного CA. Не надо на это вестись. -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Thu Sep 13 10:10:34 2018 From: nginx-forum на forum.nginx.org (clgs) Date: Thu, 13 Sep 2018 06:10:34 -0400 Subject: =?UTF-8?B?UmU6INCd0LUg0YDQsNCx0L7RgtCw0LXRgiAkaHR0cCB4ICDQsiDQutC+0L3RgtC1?= =?UTF-8?B?0LrRgdGC0LUgaHR0cCwg0LAg0LjQvNC10L3QvdC+INCyIGdlbw==?= In-Reply-To: <8e1a766aa3deb6ac8d0abb30d00d64d8.NginxMailingListRussian@forum.nginx.org> References: <8e1a766aa3deb6ac8d0abb30d00d64d8.NginxMailingListRussian@forum.nginx.org> Message-ID: <59f6e1567897a3246e9ed2f828d3557b.NginxMailingListRussian@forum.nginx.org> Не кто не ответит?( Posted at Nginx Forum: https://forum.nginx.org/read.php?21,280946,281189#msg-281189 From mdounin на mdounin.ru Thu Sep 13 10:55:05 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 13 Sep 2018 13:55:05 +0300 Subject: =?UTF-8?B?UmU6INCd0LUg0YDQsNCx0L7RgtCw0LXRgiAkaHR0cCB4ICDQsiDQutC+0L3RgtC1?= =?UTF-8?B?0LrRgdGC0LUgaHR0cCwg0LAg0LjQvNC10L3QvdC+INCyIGdlbw==?= In-Reply-To: <59f6e1567897a3246e9ed2f828d3557b.NginxMailingListRussian@forum.nginx.org> References: <8e1a766aa3deb6ac8d0abb30d00d64d8.NginxMailingListRussian@forum.nginx.org> <59f6e1567897a3246e9ed2f828d3557b.NginxMailingListRussian@forum.nginx.org> Message-ID: <20180913105505.GU56558@mdounin.ru> Hello! On Thu, Sep 13, 2018 at 06:10:34AM -0400, clgs wrote: > Не кто не ответит?( Вам ответили, но вы этого не видите, потому что ходите через глючный форум - ссылки на который не просто так выпилены с официального сайта. Ответ можно прочитать тут: http://mailman.nginx.org/pipermail/nginx-ru/2018-August/061431.html Впрочем, скорее всего этого ответа вы тоже не увидите. -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Thu Sep 13 19:28:02 2018 From: nginx-forum на forum.nginx.org (Slowpoke) Date: Thu, 13 Sep 2018 15:28:02 -0400 Subject: =?UTF-8?B?0J/QtdGA0LXQvdCw0L/RgNCw0LLQu9C10L3QuNC1INCyIG5naW54INC/0L4g0Ls=?= =?UTF-8?B?0L7Qs9C40L3Rgw==?= Message-ID: <710131c3e895af6d52eab792d86f42aa.NginxMailingListRussian@forum.nginx.org> Можно ли в nginx реализовать следующую вещь? 1) Прикрутить к nginx доменную аутентфикацию. 2) Сверять логин пользователя с списком и если логин там есть, то перенаправить пользователя на 1 сайт, а если нет, то на другой? Это реализуемо? Если да, то как? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,281222,281222#msg-281222 From kpoxa на kpoxa.net Fri Sep 14 14:36:54 2018 From: kpoxa на kpoxa.net (kpoxa) Date: Fri, 14 Sep 2018 17:36:54 +0300 Subject: =?UTF-8?B?dXJsIGVzY2FwZSDQsiDQu9C+0LPQsNGFINCx0LXQtyDQstC90LXRiNC90LjRhSA=?= =?UTF-8?B?0LzQvtC00YPQu9C10Lk=?= Message-ID: Добрый день. Существует ли способ заполучить в лог заэкспкейпленные uri и referrer ? Вариант с escape-json не то, что требуется, к сожалению. PS. Не планируется ли функционал из модуля (или сам модуль) https://github.com/openresty/set-misc-nginx-module добавить в nginx ? -- Рустам From gmm на csdoc.com Sat Sep 15 11:35:35 2018 From: gmm на csdoc.com (Gena Makhomed) Date: Sat, 15 Sep 2018 14:35:35 +0300 Subject: OCSP stapling in Nginx >=1.3.7 In-Reply-To: <20180912143606.GQ56558@mdounin.ru> References: <1240491d-0262-b7de-b4cf-a8e29f7274f9@csdoc.com> <20180910130419.GC56558@mdounin.ru> <20180911032109.GK56558@mdounin.ru> <20180911123810.GM56558@mdounin.ru> <1d4bed82-2b3d-b6a4-ba6d-16e8872134ad@csdoc.com> <20180911155920.GP56558@mdounin.ru> <01c41dde-d08a-df21-e423-63659c6dd7ad@csdoc.com> <20180912143606.GQ56558@mdounin.ru> Message-ID: <16a36038-8ad8-27b2-5417-f16354a9cfe9@csdoc.com> On 12.09.2018 17:36, Maxim Dounin wrote: >>>>>>> Лучше всего - сделать так, чтобы OpenSSL научился проверять >>>>>>> OCSP-ответы не полной цепочкой сертификатов вплоть до доверенного >>>>>>> root'а, а ровно так, как и должно быть по стандарту - с помощью >>>>>>> одного только сертификата issuer'а. Тогда проблема исчезнет. Задал вопрос по этому поводу в списке рассылки openssl-users: https://mta.openssl.org/pipermail/openssl-users/2018-September/008795.html - пока что мне там никто ничего так и не ответил. >>> В зависимости от того, каким сертификатом подписан OCSP-ответ - >>> этого может быть достаточно или нет. RFC 6960 допускает два >>> варианта подписи в OCSP-ответах: >>> - issuer подписывает OCSP-ответ сам; или >>> - issuer выпускает сертификат, которым подписываются OCSP-ответы >>> (и этот сертификат включается в OCSP-ответ). >>> В обоих случаях для проверки OCSP-ответа достаточно знать >>> issuer'а, однако второй случай в OpenSSL не работает (впрочем, я >>> давно не порверял; но если верить "документации", в этом месте >>> ничего не зименилось). При этом по понятным причинам мало кто >>> использует собственно CA для подписи OCSP-ответов, соответственно >>> не работает это приблизительно всегда. Проверил второй случай, openssl-1.0.2k из CentOS 7.5 все работает: 1. Получаю сертификат сервера (0) и сертификат issuer'а (1): openssl s_client -showcerts -connect www.godaddy.com:443 < /dev/null | less Сертификат сервера сохраняю в файл www.godaddy.com-cert.pem а сертификат issuer'а - в файл www.godaddy.com-issuer.pem 2. Узнаю OCSP URI, это http://ocsp.godaddy.com/ openssl x509 -text -noout -in www.godaddy.com-cert.pem | less 3. Делаю запрос на получение OCSP ответа от этого сервера: openssl ocsp -verify_other www.godaddy.com-issuer.pem -issuer www.godaddy.com-issuer.pem -cert www.godaddy.com-cert.pem -text -url http://ocsp.godaddy.com/ -header "Host" "ocsp.godaddy.com" | less Из ответа видно, что для подписи используется отдельный сертификат Go Daddy Validation Authority - G2, при этом "Response verify OK", то есть OpenSSL может проверить ответ сервера и в этом случае. Если убрать параметр '-verify_other www.godaddy.com-issuer.pem' тогда возвращается сообщение про ошибку: Response Verify Failure 140345419933584:error:27069065:OCSP routines:OCSP_basic_verify:certificate verify error:ocsp_vfy.c:138:Verify error:unable to get local issuer certificate Получается, что OpenSSL уже очень давно умеет проверять OCSP-ответ с помощью одного только сертификата issuer'а? >>>> Насколько я понял из предыдущего обсуждения, нет разумных причин, >>>> чтобы выключать использование OCSP stapling и ocsp_stapling_verify. >>>> >>>> И вместе с тем, есть причины, чтобы их включать: >>>> OCSP stapling - сайт у клиентов будет открываться быстрее. >>>> ocsp_stapling_verify - не будет проблем с неразумными браузерами. >> >>> Про "быстрее" - есть нюансы. В частности, OCSP-ответ отправляется >>> клиенту, пытающемуся использовать OCSP stapling, в каждом >>> SSL handshake'е (а это местами может быть больно с точки зрения latency, не >>> говоря уже про трафик), в то время как в значительной части >>> случаев он клиенту на самом деле не нужен (например, уже есть в >>> кэше). Почему это может быть больно с точки зрения latency? Ведь nginx держит OCSP-ответ в своей памяти и отдает его клиенту практически мгновенно. Этот ответ как правило валиден от 24 часов до 7 или даже 14 дней. Трафик - это дополнительный килобайт, максимум два килобайта. Разве это много? Страница сайта весит от сотен килобайт до нескольких мегабайт, и 1-2 килобайта роли не играют. Если OCSP-статус сертификата клиенту не нужен, зачем же в таком случае клиент его постоянно запрашивает? Это же клиент решает, получать ему OCSP-статус сертификата или нет. Вот ответ сервера, если OCSP-статус не запрашивать: openssl s_client -showcerts -connect www.godaddy.com:443 < /dev/null | less А вот ответ сервера, если OCSP-статус запрашивать: openssl s_client -showcerts -status -connect www.godaddy.com:443 < /dev/null | less Если глупый клиент постоянно запрашивает OCSP-статус сертификата, даже в том случае если ему этот статус уже известен и не нужен - это наверное не проблемы сервера, а проблемы самого клиента. (И исправлять эту проблему надо на клиенте а не на сервере) >> Открытие сайта по HTTPS без OCSP Stapling подразумевает, >> что браузер сам будет проверять не отозван ли сертификат сервера. >> Клиент в это время будет сидеть перед монитором и ждать открытия сайта. > Или не будет - см. пример в скобках. Обычно веб-мастера стараются максимально ускорить первое открытие сайта клиентом. Потому что если сайт будет открываться долго, например, 5 или 10 секунд - пользователь этого может просто не дождаться и уйти. При первом открытии сайта - OCSP-ответа точно нет в кэше клиента. >>> Про verify - тоже есть нюансы. Дискуссия, если я её правильно >>> понял, как раз о том, что включать verify обходится дороже с >>> административной точки зрения, чем хотелось бы. При этом плюсы - >>> призрачны, ибо защищают от атак, которых на практике не бывает >>> (а если бы они были - браузеры бы давно исправились). >> >> В начале дискуссии вопрос был о том, почему для того чтобы директива >> ssl_stapling_verify on; нормально работала необходимо также прописывать >> ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem; >> если содержимое файла chain.pem можно получить из файла fullchain.pem >> выбросив оттуда первый сертификат, который является сертификатом сайта? > > И ответ на этот вопрос - потому что интерфейс проверки сертификатов > кривой, и требует массы дополнительных приседаний, чтобы работать. > Именно поэтому по умолчанию используется ssl_stapling_verify off. Передать библиотеке OpenSSL сертификат issuer'а два раза, в параметрах -issuer и -verify_other - это не выглядит очень сложным. > Кроме того, если у вас в ssl_certificate указана полная цепочка, > включая сертификат root CA, то это неправильно. Root-сертификат у > клиентов и так есть, отправлять клиентам его - бессмысленная трата > ресурсов, соответственно и включать его в цепочку в > ssl_certificate - не надо. У меня сертификат получен с помощью certbot, "Let’s Encrypt Authority X3" - это промежуточный сертификат. Он подписан с помощью "DST Root CA X3", подробности здесь: https://letsencrypt.org/certificates/ В конфиге nginx прописано ssl_stapling on; ssl_stapling_verify on; resolver 127.0.0.1; ssl_certificate /etc/letsencrypt/live/.../fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/.../privkey.pem; Директива ssl_trusted_certificate вообще нигде в конфиге не указана, при этом - nginx не пишет в лог никаких ошибок верификации сертификата. > Если же root-сертификата в цепочке нет, то получить из > ssl_certificate полную цепочку, включая root, по очевидным > причинам не получится, и ssl_stapling_verify работать не будет. Почему же в таком случае nginx не пишет в лог никаких ошибок? Версия 1.15.3, пакет из официального репозитория nginx.org >>> Единственное несомненное преимущество OCSP stapling'а >>> - это меньшая нагрузка на инфраструктуру CA Let’s Encrypt дает мне SSL-сертификаты полностью бесплатно, с моей стороны нормально будет в ответ уменьшить нагрузку на их сервера, включив OCSP stapling для всех сайтов. Если же я выключу OCSP stapling, тогда я буду в чем-то похож на персонажа басни Крылова "Свинья под дубом". Кроме того, например, Майкрософт включает OCSP stapling в своем веб-сервере IIS по-умолчанию уже очень давно. Они же это делают не для того, чтобы навредить своим клиентам, а наоборот, чтобы сайты их клиентов открывались еще быстрее? P.S. Кстати, пользователи жалуются, что есть BUG в nginx, связанный с сертификатами с флагом "OCSP Must Staple": https://blog.crashed.org/nginx-stapling-busted/ -- Best regards, Gena From gmm на csdoc.com Sat Sep 15 15:20:40 2018 From: gmm на csdoc.com (Gena Makhomed) Date: Sat, 15 Sep 2018 18:20:40 +0300 Subject: How to Improve SEO with HTTPS and NGINX In-Reply-To: <20180911032109.GK56558@mdounin.ru> References: <1240491d-0262-b7de-b4cf-a8e29f7274f9@csdoc.com> <20180910130419.GC56558@mdounin.ru> <20180911032109.GK56558@mdounin.ru> Message-ID: <5c8702ff-8992-e640-592b-4ad393b7aade@csdoc.com> On 11.09.2018 6:21, Maxim Dounin wrote: >>>> ssl_stapling on; >>>> ssl_stapling_verify on; >>>> resolver 8.8.8.8 1.1.1.1 9.9.9.9 ipv6=off; >>> Just a side note: использование сторонних DNS-серверов - это >>> плохое решение. Цитируя документацию: >>> : Для предотвращения DNS-спуфинга рекомендуется использовать >>> : DNS-серверы в защищённой доверенной локальной сети. >> Разве сервера 8.8.8.8, 1.1.1.1 и 9.9.9.9 подвержены атаке DNS spoofing? >> https://en.wikipedia.org/wiki/DNS_spoofing > Речь не о том, подвержены ли эти сервера атакам. Речь о том, что > при использовании не-локальных DNS-серверов в некотороых случаях > становятся возможны атаки на resolver nginx'а, так как он общается > с удалённым DNS-сервером - то есть, фактически, открыт для всего > мира с точностью до номера порта и 16-битного query id, ибо > spoofing IP-адреса в UDP-пакетах проблемы не представляет. Кстати, на сайте www.nginx.com предлагается использовать в конфиге ресолверы 8.8.8.8 и 8.8.4.4. Вот в этой статье: https://www.nginx.com/blog/improve-seo-https-nginx/ How to Improve SEO with HTTPS and NGINX ssl_stapling on; ssl_stapling_verify on; ssl_trusted_certificate /etc/nginx/cert/trustchain.crt; resolver 8.8.8.8 8.8.4.4 valid=300s; Если включено ssl_stapling_verify on; - тогда вроде бы нет проблем с DNS-спуфингом, поскольку nginx будет отбрасывать те OCSP-ответы, которые он не сможет проверить и уязвимости в данном случае не будет? -- Best regards, Gena From mdounin на mdounin.ru Sun Sep 16 23:36:54 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 17 Sep 2018 02:36:54 +0300 Subject: OCSP stapling in Nginx >=1.3.7 In-Reply-To: <16a36038-8ad8-27b2-5417-f16354a9cfe9@csdoc.com> References: <20180910130419.GC56558@mdounin.ru> <20180911032109.GK56558@mdounin.ru> <20180911123810.GM56558@mdounin.ru> <1d4bed82-2b3d-b6a4-ba6d-16e8872134ad@csdoc.com> <20180911155920.GP56558@mdounin.ru> <01c41dde-d08a-df21-e423-63659c6dd7ad@csdoc.com> <20180912143606.GQ56558@mdounin.ru> <16a36038-8ad8-27b2-5417-f16354a9cfe9@csdoc.com> Message-ID: <20180916233654.GD56558@mdounin.ru> Hello! On Sat, Sep 15, 2018 at 02:35:35PM +0300, Gena Makhomed wrote: > On 12.09.2018 17:36, Maxim Dounin wrote: > > >>>>>>> Лучше всего - сделать так, чтобы OpenSSL научился проверять > >>>>>>> OCSP-ответы не полной цепочкой сертификатов вплоть до доверенного > >>>>>>> root'а, а ровно так, как и должно быть по стандарту - с помощью > >>>>>>> одного только сертификата issuer'а. Тогда проблема исчезнет. > > Задал вопрос по этому поводу в списке рассылки openssl-users: > https://mta.openssl.org/pipermail/openssl-users/2018-September/008795.html > - пока что мне там никто ничего так и не ответил. > > >>> В зависимости от того, каким сертификатом подписан OCSP-ответ - > >>> этого может быть достаточно или нет. RFC 6960 допускает два > >>> варианта подписи в OCSP-ответах: > > >>> - issuer подписывает OCSP-ответ сам; или > >>> - issuer выпускает сертификат, которым подписываются OCSP-ответы > >>> (и этот сертификат включается в OCSP-ответ). > > >>> В обоих случаях для проверки OCSP-ответа достаточно знать > >>> issuer'а, однако второй случай в OpenSSL не работает (впрочем, я > >>> давно не порверял; но если верить "документации", в этом месте > >>> ничего не зименилось). При этом по понятным причинам мало кто > >>> использует собственно CA для подписи OCSP-ответов, соответственно > >>> не работает это приблизительно всегда. > > Проверил второй случай, openssl-1.0.2k из CentOS 7.5 все работает: > > 1. Получаю сертификат сервера (0) и сертификат issuer'а (1): > openssl s_client -showcerts -connect www.godaddy.com:443 < /dev/null | less > > Сертификат сервера сохраняю в файл www.godaddy.com-cert.pem > а сертификат issuer'а - в файл www.godaddy.com-issuer.pem > > 2. Узнаю OCSP URI, это http://ocsp.godaddy.com/ > openssl x509 -text -noout -in www.godaddy.com-cert.pem | less > > 3. Делаю запрос на получение OCSP ответа от этого сервера: > openssl ocsp -verify_other www.godaddy.com-issuer.pem -issuer > www.godaddy.com-issuer.pem -cert www.godaddy.com-cert.pem -text -url > http://ocsp.godaddy.com/ -header "Host" "ocsp.godaddy.com" | less > > Из ответа видно, что для подписи используется отдельный сертификат > Go Daddy Validation Authority - G2, при этом "Response verify OK", > то есть OpenSSL может проверить ответ сервера и в этом случае. > > Если убрать параметр '-verify_other www.godaddy.com-issuer.pem' > тогда возвращается сообщение про ошибку: > > Response Verify Failure > 140345419933584:error:27069065:OCSP > routines:OCSP_basic_verify:certificate verify > error:ocsp_vfy.c:138:Verify error:unable to get local issuer certificate > > Получается, что OpenSSL уже очень давно умеет проверять > OCSP-ответ с помощью одного только сертификата issuer'а? Получается, что в CentOS 7.5 есть bundle с доверенными корневыми сертификатами, который используется openssl по умолчанию. Если его отключить - указав параметры -CAfile и -CApath явно - то валидация сломается. > >>>> Насколько я понял из предыдущего обсуждения, нет разумных причин, > >>>> чтобы выключать использование OCSP stapling и ocsp_stapling_verify. > >>>> > >>>> И вместе с тем, есть причины, чтобы их включать: > >>>> OCSP stapling - сайт у клиентов будет открываться быстрее. > >>>> ocsp_stapling_verify - не будет проблем с неразумными браузерами. > >> > >>> Про "быстрее" - есть нюансы. В частности, OCSP-ответ отправляется > >>> клиенту, пытающемуся использовать OCSP stapling, в каждом > >>> SSL handshake'е (а это местами может быть больно с точки зрения latency, не > >>> говоря уже про трафик), в то время как в значительной части > >>> случаев он клиенту на самом деле не нужен (например, уже есть в > >>> кэше). > > Почему это может быть больно с точки зрения latency? Ведь nginx держит > OCSP-ответ в своей памяти и отдает его клиенту практически мгновенно. > Этот ответ как правило валиден от 24 часов до 7 или даже 14 дней. > > Трафик - это дополнительный килобайт, максимум два килобайта. > Разве это много? Страница сайта весит от сотен килобайт > до нескольких мегабайт, и 1-2 килобайта роли не играют. Дополнительная пара килобайт в начале соедениния - это потенциальный выход за пределы исходного окна, и соответственно лишний RTT на соединение. С получившим сейчас достаточно широкое распространение initcwnd10 (rfc6928, окно до 14k) - скорее всего плохо не будет (но тоже вопрос, какая цепочка сертификатов при этом стоит), а если используется более традиционный rfc3390 с окном до 4 килобайт - как раз из-за stapling'а нарваться на лишний round-trip элементарно. Что до трафика, то всё зависит как раз от того, какой в данном конкретном случае средний трафик передаётся по соединению. И далеко не везде это сотни килобайт. > Если OCSP-статус сертификата клиенту не нужен, > зачем же в таком случае клиент его постоянно запрашивает? > > Это же клиент решает, получать ему OCSP-статус сертификата или нет. Клиент не может знать, нужен ему статус или нет. Более того - он даже не может знать, какой сертификат ему вернут. Соответственно если он использует stapling - то в любом полном handshake'е вынужден получать и stapling тоже. [...] > >>> Про verify - тоже есть нюансы. Дискуссия, если я её правильно > >>> понял, как раз о том, что включать verify обходится дороже с > >>> административной точки зрения, чем хотелось бы. При этом плюсы - > >>> призрачны, ибо защищают от атак, которых на практике не бывает > >>> (а если бы они были - браузеры бы давно исправились). > >> > >> В начале дискуссии вопрос был о том, почему для того чтобы директива > >> ssl_stapling_verify on; нормально работала необходимо также прописывать > >> ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem; > >> если содержимое файла chain.pem можно получить из файла fullchain.pem > >> выбросив оттуда первый сертификат, который является сертификатом сайта? > > > > И ответ на этот вопрос - потому что интерфейс проверки сертификатов > > кривой, и требует массы дополнительных приседаний, чтобы работать. > > Именно поэтому по умолчанию используется ssl_stapling_verify off. > > Передать библиотеке OpenSSL сертификат issuer'а два раза, > в параметрах -issuer и -verify_other - это не выглядит очень сложным. К сожалению, это работает не так. Точнее - так это не работает. Всё что можно передать - nginx передаёт, но этого недостаточно, если OCSP-ответы подписаны с использованием промежуточного сертификата. > > Кроме того, если у вас в ssl_certificate указана полная цепочка, > > включая сертификат root CA, то это неправильно. Root-сертификат у > > клиентов и так есть, отправлять клиентам его - бессмысленная трата > > ресурсов, соответственно и включать его в цепочку в > > ssl_certificate - не надо. > > У меня сертификат получен с помощью certbot, > "Let’s Encrypt Authority X3" - это промежуточный сертификат. > Он подписан с помощью "DST Root CA X3", подробности здесь: > https://letsencrypt.org/certificates/ > > В конфиге nginx прописано > > ssl_stapling on; > ssl_stapling_verify on; > resolver 127.0.0.1; > > ssl_certificate /etc/letsencrypt/live/.../fullchain.pem; > ssl_certificate_key /etc/letsencrypt/live/.../privkey.pem; > > Директива ssl_trusted_certificate вообще нигде в конфиге не указана, > при этом - nginx не пишет в лог никаких ошибок верификации сертификата. Потому что letsencrypt - подписывает OCSP-ответы непосредственно issuer'ом, не используя промежуточный сертфикат. Соответственно для него - ssl_stapling_verify работает без дополнительных приседаний, хватает сертифката issuer'а, который nginx достаёт из цепочки ssl_certificate. К сожалению, это далеко не всегда так. И к ещё большему сожалению - никто не гарантирует, что в один прекрасный момент это не перестанет быть так и для letsencrypt тоже. [...] > Кстати, пользователи жалуются, что есть BUG в nginx, > связанный с сертификатами с флагом "OCSP Must Staple": > https://blog.crashed.org/nginx-stapling-busted/ Потому что "Must Staple" - это попытка превратить OCSP stapling из механизма оптимизации в обязательный механизм, аналогичный короткоживущим сертификатам. Не сюрприз, что так не работает - требования совершенно разные. Любители Must Staple общаются в траке в двух тикетах: https://trac.nginx.org/nginx/ticket/812 https://trac.nginx.org/nginx/ticket/990 Пока что они делают это с нулевым полезным выходом. -- Maxim Dounin http://mdounin.ru/ From mdounin на mdounin.ru Sun Sep 16 23:42:17 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 17 Sep 2018 02:42:17 +0300 Subject: How to Improve SEO with HTTPS and NGINX In-Reply-To: <5c8702ff-8992-e640-592b-4ad393b7aade@csdoc.com> References: <1240491d-0262-b7de-b4cf-a8e29f7274f9@csdoc.com> <20180910130419.GC56558@mdounin.ru> <20180911032109.GK56558@mdounin.ru> <5c8702ff-8992-e640-592b-4ad393b7aade@csdoc.com> Message-ID: <20180916234217.GE56558@mdounin.ru> Hello! On Sat, Sep 15, 2018 at 06:20:40PM +0300, Gena Makhomed wrote: > On 11.09.2018 6:21, Maxim Dounin wrote: > > >>>> ssl_stapling on; > >>>> ssl_stapling_verify on; > >>>> resolver 8.8.8.8 1.1.1.1 9.9.9.9 ipv6=off; > > >>> Just a side note: использование сторонних DNS-серверов - это > >>> плохое решение. Цитируя документацию: > > >>> : Для предотвращения DNS-спуфинга рекомендуется использовать > >>> : DNS-серверы в защищённой доверенной локальной сети. > > >> Разве сервера 8.8.8.8, 1.1.1.1 и 9.9.9.9 подвержены атаке DNS spoofing? > >> https://en.wikipedia.org/wiki/DNS_spoofing > > > Речь не о том, подвержены ли эти сервера атакам. Речь о том, что > > при использовании не-локальных DNS-серверов в некотороых случаях > > становятся возможны атаки на resolver nginx'а, так как он общается > > с удалённым DNS-сервером - то есть, фактически, открыт для всего > > мира с точностью до номера порта и 16-битного query id, ибо > > spoofing IP-адреса в UDP-пакетах проблемы не представляет. > > Кстати, на сайте www.nginx.com предлагается использовать > в конфиге ресолверы 8.8.8.8 и 8.8.4.4. Вот в этой статье: > > https://www.nginx.com/blog/improve-seo-https-nginx/ > How to Improve SEO with HTTPS and NGINX > > ssl_stapling on; > ssl_stapling_verify on; > ssl_trusted_certificate /etc/nginx/cert/trustchain.crt; > resolver 8.8.8.8 8.8.4.4 valid=300s; Наши маркетологи - к сожалению, далеко не всегда пишут то, что действительно стоит использовать. > Если включено ssl_stapling_verify on; - тогда вроде бы нет проблем > с DNS-спуфингом, поскольку nginx будет отбрасывать те OCSP-ответы, > которые он не сможет проверить и уязвимости в данном случае не будет? Не стоит путать отсутствие проблем и наличие механизма, позволяющего минимизировать ущерб. -- Maxim Dounin http://mdounin.ru/ From chipitsine на gmail.com Mon Sep 17 13:05:28 2018 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Mon, 17 Sep 2018 18:05:28 +0500 Subject: OCSP stapling in Nginx >=1.3.7 In-Reply-To: <20180916233654.GD56558@mdounin.ru> References: <20180910130419.GC56558@mdounin.ru> <20180911032109.GK56558@mdounin.ru> <20180911123810.GM56558@mdounin.ru> <1d4bed82-2b3d-b6a4-ba6d-16e8872134ad@csdoc.com> <20180911155920.GP56558@mdounin.ru> <01c41dde-d08a-df21-e423-63659c6dd7ad@csdoc.com> <20180912143606.GQ56558@mdounin.ru> <16a36038-8ad8-27b2-5417-f16354a9cfe9@csdoc.com> <20180916233654.GD56558@mdounin.ru> Message-ID: пн, 17 сент. 2018 г. в 4:37, Maxim Dounin : > Hello! > > On Sat, Sep 15, 2018 at 02:35:35PM +0300, Gena Makhomed wrote: > > > On 12.09.2018 17:36, Maxim Dounin wrote: > > > > >>>>>>> Лучше всего - сделать так, чтобы OpenSSL научился проверять > > >>>>>>> OCSP-ответы не полной цепочкой сертификатов вплоть до доверенного > > >>>>>>> root'а, а ровно так, как и должно быть по стандарту - с помощью > > >>>>>>> одного только сертификата issuer'а. Тогда проблема исчезнет. > > > > Задал вопрос по этому поводу в списке рассылки openssl-users: > > > https://mta.openssl.org/pipermail/openssl-users/2018-September/008795.html > > - пока что мне там никто ничего так и не ответил. > > > > >>> В зависимости от того, каким сертификатом подписан OCSP-ответ - > > >>> этого может быть достаточно или нет. RFC 6960 допускает два > > >>> варианта подписи в OCSP-ответах: > > > > >>> - issuer подписывает OCSP-ответ сам; или > > >>> - issuer выпускает сертификат, которым подписываются OCSP-ответы > > >>> (и этот сертификат включается в OCSP-ответ). > > > > >>> В обоих случаях для проверки OCSP-ответа достаточно знать > > >>> issuer'а, однако второй случай в OpenSSL не работает (впрочем, я > > >>> давно не порверял; но если верить "документации", в этом месте > > >>> ничего не зименилось). При этом по понятным причинам мало кто > > >>> использует собственно CA для подписи OCSP-ответов, соответственно > > >>> не работает это приблизительно всегда. > > > > Проверил второй случай, openssl-1.0.2k из CentOS 7.5 все работает: > > > > 1. Получаю сертификат сервера (0) и сертификат issuer'а (1): > > openssl s_client -showcerts -connect www.godaddy.com:443 < /dev/null | > less > > > > Сертификат сервера сохраняю в файл www.godaddy.com-cert.pem > > а сертификат issuer'а - в файл www.godaddy.com-issuer.pem > > > > 2. Узнаю OCSP URI, это http://ocsp.godaddy.com/ > > openssl x509 -text -noout -in www.godaddy.com-cert.pem | less > > > > 3. Делаю запрос на получение OCSP ответа от этого сервера: > > openssl ocsp -verify_other www.godaddy.com-issuer.pem -issuer > > www.godaddy.com-issuer.pem -cert www.godaddy.com-cert.pem -text -url > > http://ocsp.godaddy.com/ -header "Host" "ocsp.godaddy.com" | less > > > > Из ответа видно, что для подписи используется отдельный сертификат > > Go Daddy Validation Authority - G2, при этом "Response verify OK", > > то есть OpenSSL может проверить ответ сервера и в этом случае. > > > > Если убрать параметр '-verify_other www.godaddy.com-issuer.pem' > > тогда возвращается сообщение про ошибку: > > > > Response Verify Failure > > 140345419933584:error:27069065:OCSP > > routines:OCSP_basic_verify:certificate verify > > error:ocsp_vfy.c:138:Verify error:unable to get local issuer certificate > > > > Получается, что OpenSSL уже очень давно умеет проверять > > OCSP-ответ с помощью одного только сертификата issuer'а? > > Получается, что в CentOS 7.5 есть bundle с доверенными корневыми > сертификатами, который используется openssl по умолчанию. Если > его отключить - указав параметры -CAfile и -CApath явно - то > валидация сломается. > > > >>>> Насколько я понял из предыдущего обсуждения, нет разумных причин, > > >>>> чтобы выключать использование OCSP stapling и ocsp_stapling_verify. > > >>>> > > >>>> И вместе с тем, есть причины, чтобы их включать: > > >>>> OCSP stapling - сайт у клиентов будет открываться быстрее. > > >>>> ocsp_stapling_verify - не будет проблем с неразумными браузерами. > > >> > > >>> Про "быстрее" - есть нюансы. В частности, OCSP-ответ отправляется > > >>> клиенту, пытающемуся использовать OCSP stapling, в каждом > > >>> SSL handshake'е (а это местами может быть больно с точки зрения > latency, не > > >>> говоря уже про трафик), в то время как в значительной части > > >>> случаев он клиенту на самом деле не нужен (например, уже есть в > > >>> кэше). > > > > Почему это может быть больно с точки зрения latency? Ведь nginx держит > > OCSP-ответ в своей памяти и отдает его клиенту практически мгновенно. > > Этот ответ как правило валиден от 24 часов до 7 или даже 14 дней. > > > > Трафик - это дополнительный килобайт, максимум два килобайта. > > Разве это много? Страница сайта весит от сотен килобайт > > до нескольких мегабайт, и 1-2 килобайта роли не играют. > > Дополнительная пара килобайт в начале соедениния - это > потенциальный выход за пределы исходного окна, и соответственно > лишний RTT на соединение. > > С получившим сейчас достаточно широкое распространение initcwnd10 > (rfc6928, окно до 14k) - скорее всего плохо не будет (но тоже > вопрос, какая цепочка сертификатов при этом стоит), а если > используется более традиционный rfc3390 с окном до 4 килобайт - > как раз из-за stapling'а нарваться на лишний round-trip > элементарно. > > Что до трафика, то всё зависит как раз от того, какой в данном > конкретном случае средний трафик передаётся по соединению. И > далеко не везде это сотни килобайт. > > > Если OCSP-статус сертификата клиенту не нужен, > > зачем же в таком случае клиент его постоянно запрашивает? > > > > Это же клиент решает, получать ему OCSP-статус сертификата или нет. > > Клиент не может знать, нужен ему статус или нет. Более того - он > даже не может знать, какой сертификат ему вернут. Соответственно > если он использует stapling - то в любом полном handshake'е > вынужден получать и stapling тоже. > > [...] > > > >>> Про verify - тоже есть нюансы. Дискуссия, если я её правильно > > >>> понял, как раз о том, что включать verify обходится дороже с > > >>> административной точки зрения, чем хотелось бы. При этом плюсы - > > >>> призрачны, ибо защищают от атак, которых на практике не бывает > > >>> (а если бы они были - браузеры бы давно исправились). > > >> > > >> В начале дискуссии вопрос был о том, почему для того чтобы директива > > >> ssl_stapling_verify on; нормально работала необходимо также > прописывать > > >> ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem; > > >> если содержимое файла chain.pem можно получить из файла fullchain.pem > > >> выбросив оттуда первый сертификат, который является сертификатом > сайта? > > > > > > И ответ на этот вопрос - потому что интерфейс проверки сертификатов > > > кривой, и требует массы дополнительных приседаний, чтобы работать. > > > Именно поэтому по умолчанию используется ssl_stapling_verify off. > > > > Передать библиотеке OpenSSL сертификат issuer'а два раза, > > в параметрах -issuer и -verify_other - это не выглядит очень сложным. > > К сожалению, это работает не так. Точнее - так это не работает. > Всё что можно передать - nginx передаёт, но этого недостаточно, > если OCSP-ответы подписаны с использованием промежуточного > сертификата. > > > > Кроме того, если у вас в ssl_certificate указана полная цепочка, > > > включая сертификат root CA, то это неправильно. Root-сертификат у > > > клиентов и так есть, отправлять клиентам его - бессмысленная трата > > > ресурсов, соответственно и включать его в цепочку в > > > ssl_certificate - не надо. > > > > У меня сертификат получен с помощью certbot, > > "Let’s Encrypt Authority X3" - это промежуточный сертификат. > > Он подписан с помощью "DST Root CA X3", подробности здесь: > > https://letsencrypt.org/certificates/ > > > > В конфиге nginx прописано > > > > ssl_stapling on; > > ssl_stapling_verify on; > > resolver 127.0.0.1; > > > > ssl_certificate /etc/letsencrypt/live/.../fullchain.pem; > > ssl_certificate_key /etc/letsencrypt/live/.../privkey.pem; > > > > Директива ssl_trusted_certificate вообще нигде в конфиге не указана, > > при этом - nginx не пишет в лог никаких ошибок верификации сертификата. > > Потому что letsencrypt - подписывает OCSP-ответы непосредственно > issuer'ом, не используя промежуточный сертфикат. Соответственно > для него - ssl_stapling_verify работает без дополнительных > приседаний, хватает сертифката issuer'а, который nginx достаёт из > цепочки ssl_certificate. > > К сожалению, это далеко не всегда так. И к ещё большему сожалению - > никто не гарантирует, что в один прекрасный момент это не > перестанет быть так и для letsencrypt тоже. > > [...] > > > Кстати, пользователи жалуются, что есть BUG в nginx, > > связанный с сертификатами с флагом "OCSP Must Staple": > > https://blog.crashed.org/nginx-stapling-busted/ > > Потому что "Must Staple" - это попытка превратить OCSP stapling из > механизма оптимизации в обязательный механизм, аналогичный > короткоживущим сертификатам. Не сюрприз, что так не работает - > требования совершенно разные. > > Любители Must Staple общаются в траке в двух тикетах: > > https://trac.nginx.org/nginx/ticket/812 > https://trac.nginx.org/nginx/ticket/990 > > Пока что они делают это с нулевым полезным выходом. > из этих тикетов, в общем, есть здравое зерно, что было бы неплохо каким-то проактивным способом уметь получать OCSP ответы. почему это разумно 1) список сертов более или менее известен (пока что nginx не умеет и не планировать выпускать серты самостоятельно) 2) это сокращает время доставки контента и делает процедуру более предсказуемой (по сравнению с тем, когда надо пойти за OCSP ответом в то время, когда на проводе сидит пользователь) я не уверен, что архитектурно правильным решением будет делать это именно силами nginx. возможно, некое стороннее приложение (надо удобным способом уметь согласовывать список сертов и момент перечитывания OCSP с диска) > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Tue Sep 18 07:42:18 2018 From: nginx-forum на forum.nginx.org (clgs) Date: Tue, 18 Sep 2018 03:42:18 -0400 Subject: =?UTF-8?B?UmU6INCd0LUg0YDQsNCx0L7RgtCw0LXRgiAkaHR0cCB4ICDQsiDQutC+0L3RgtC1?= =?UTF-8?B?0LrRgdGC0LUgaHR0cCwg0LAg0LjQvNC10L3QvdC+INCyIGdlbw==?= In-Reply-To: <20180823145650.GD56558@mdounin.ru> References: <20180823145650.GD56558@mdounin.ru> Message-ID: <21ea6fdf99c5fd50b4bc5dd03ff065dd.NginxMailingListRussian@forum.nginx.org> Спасибо Максим. Увидел Ваши сообщения. Не понял как работает рассылка, поэтому написал на форуме. По поводу ответа, в блок geo положить блок map и уже в мапе заюзать переменную? Или сразу использовать блок map ? По возможности ответьте через форум. https://forum.nginx.org/read.php?21,280946,281198 Спасибо. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,280946,281251#msg-281251 From chipitsine на gmail.com Tue Sep 18 07:49:42 2018 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 18 Sep 2018 12:49:42 +0500 Subject: =?UTF-8?B?c3lzdGVtZCBpbnN0YW50aWF0ZWQgdW5pdHMgLSDQvtCx0YHRg9C00LjQvCA/?= Message-ID: привет! мы распробовали удобную штуку - инстансы. в стоковом варианте такого не предлагается, кажется это настолько крутая штука, что ее стоит евангелизировать и всяко продвигать. рассмотрите вариант включения в поставку еще одного юнита для инстансов ? (ну или, что, наверное, хуже с точки зрения совместимости, поменять текущий единственный юнит на параметризованный) ? Илья Шипицин ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From alex.hha на gmail.com Tue Sep 18 10:20:32 2018 From: alex.hha на gmail.com (Alex Domoradov) Date: Tue, 18 Sep 2018 13:20:32 +0300 Subject: =?UTF-8?B?UmU6IHN5c3RlbWQgaW5zdGFudGlhdGVkIHVuaXRzIC0g0L7QsdGB0YPQtNC40Lwg?= =?UTF-8?B?Pw==?= In-Reply-To: References: Message-ID: А можно чуть подоробнее, хотя бы простенький пример, для тех кто не в курсе? On Tue, Sep 18, 2018 at 10:49 AM Илья Шипицин wrote: > привет! > > мы распробовали удобную штуку - инстансы. > в стоковом варианте такого не предлагается, кажется это настолько крутая > штука, что ее стоит евангелизировать и всяко продвигать. > > рассмотрите вариант включения в поставку еще одного юнита для инстансов ? > (ну или, что, наверное, хуже с точки зрения совместимости, поменять > текущий единственный юнит на параметризованный) ? > > Илья Шипицин > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Tue Sep 18 10:35:13 2018 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 18 Sep 2018 15:35:13 +0500 Subject: =?UTF-8?B?UmU6IHN5c3RlbWQgaW5zdGFudGlhdGVkIHVuaXRzIC0g0L7QsdGB0YPQtNC40Lwg?= =?UTF-8?B?Pw==?= In-Reply-To: References: Message-ID: примерно так [root на xxx ~]# cat /lib/systemd/system/nginx на .service [Unit] Description=nginx - high performance web server instance %i Documentation=http://nginx.org/en/docs/ After=network-online.target remote-fs.target nss-lookup.target Wants=network-online.target [Service] Type=forking PIDFile=/var/run/nginx-%i.pid ExecStart=/usr/sbin/nginx -c /etc/nginx-%i/nginx.conf -p /etc/nginx-%i -g "pid /var/run/nginx-%i.pid;" ExecReload=/bin/kill -s HUP $MAINPID ExecStop=/bin/kill -s TERM $MAINPID [Install] WantedBy=multi-user.target это позволяет за счет параметра (который подставляется в %i) создавать отдельные инстансы. более детально http://0pointer.de/blog/projects/instances.html удобства в изоляции, вплоть до накладывания cgroup на разные инстансы вт, 18 сент. 2018 г. в 15:20, Alex Domoradov : > А можно чуть подоробнее, хотя бы простенький пример, для тех кто не в > курсе? > > On Tue, Sep 18, 2018 at 10:49 AM Илья Шипицин > wrote: > >> привет! >> >> мы распробовали удобную штуку - инстансы. >> в стоковом варианте такого не предлагается, кажется это настолько крутая >> штука, что ее стоит евангелизировать и всяко продвигать. >> >> рассмотрите вариант включения в поставку еще одного юнита для инстансов ? >> (ну или, что, наверное, хуже с точки зрения совместимости, поменять >> текущий единственный юнит на параметризованный) ? >> >> Илья Шипицин >> _______________________________________________ >> 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 ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From skobolo на gmail.com Tue Sep 18 11:26:00 2018 From: skobolo на gmail.com (Seva Kobylin) Date: Tue, 18 Sep 2018 14:26:00 +0300 Subject: =?UTF-8?B?UmU6IHN5c3RlbWQgaW5zdGFudGlhdGVkIHVuaXRzIC0g0L7QsdGB0YPQtNC40Lwg?= =?UTF-8?B?Pw==?= In-Reply-To: References: Message-ID: <7939E736-56B1-4052-BD1D-FA9D64D62455@gmail.com> А вопрос-то в чём? Что предлагается сделать? Ну и второй вопрос — а зачем? :-) В моей голове не так много реальных примеров, которые требуют запуск нескольких инстансов мастер-процессов nginx на одной машине. > 18 сент. 2018 г., в 13:35, Илья Шипицин написал(а): > > примерно так > > [root на xxx ~]# cat /lib/systemd/system/nginx на .service > [Unit] > Description=nginx - high performance web server instance %i > Documentation=http://nginx.org/en/docs/ > After=network-online.target remote-fs.target nss-lookup.target > Wants=network-online.target > > [Service] > Type=forking > PIDFile=/var/run/nginx-%i.pid > ExecStart=/usr/sbin/nginx -c /etc/nginx-%i/nginx.conf -p /etc/nginx-%i -g "pid /var/run/nginx-%i.pid;" > ExecReload=/bin/kill -s HUP $MAINPID > ExecStop=/bin/kill -s TERM $MAINPID > > [Install] > WantedBy=multi-user.target > > это позволяет за счет параметра (который подставляется в %i) создавать отдельные инстансы. > > > более детально http://0pointer.de/blog/projects/instances.html > > > > удобства в изоляции, вплоть до накладывания cgroup на разные инстансы > > вт, 18 сент. 2018 г. в 15:20, Alex Domoradov >: > А можно чуть подоробнее, хотя бы простенький пример, для тех кто не в курсе? > > On Tue, Sep 18, 2018 at 10:49 AM Илья Шипицин > wrote: > привет! > > мы распробовали удобную штуку - инстансы. > в стоковом варианте такого не предлагается, кажется это настолько крутая штука, что ее стоит евангелизировать и всяко продвигать. > > рассмотрите вариант включения в поставку еще одного юнита для инстансов ? > (ну или, что, наверное, хуже с точки зрения совместимости, поменять текущий единственный юнит на параметризованный) ? > > Илья Шипицин > _______________________________________________ > 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 _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From andrey на kopeyko.ru Tue Sep 18 11:46:59 2018 From: andrey на kopeyko.ru (Andrey Kopeyko) Date: Tue, 18 Sep 2018 14:46:59 +0300 (MSK) Subject: =?UTF-8?B?W1NwYW1dIFJlOiBzeXN0ZW1kIGluc3RhbnRpYXRlZCB1bml0cyAtINC+0LHRgdGD?= =?UTF-8?B?0LTQuNC8ID8=?= In-Reply-To: <7939E736-56B1-4052-BD1D-FA9D64D62455@gmail.com> References: <7939E736-56B1-4052-BD1D-FA9D64D62455@gmail.com> Message-ID: On Tue, 18 Sep 2018, Seva Kobylin wrote: > Ну и второй вопрос — а зачем? :-) В моей голове не так много реальных > примеров, которые требуют запуск нескольких инстансов мастер-процессов nginx > на одной машине. Но когда нужно - такой параметризированный unit сильно упрощает жизнь. > Что предлагается сделать? Честно говоря, я не вижу здесь предмета для дискуссии. Если мэйнтейнеры откажутся доложить приведённый "nginx на .service" в поставку - давайте положим его в contribs/ >> 18 сент. 2018 г., в 13:35, Илья Шипицин написал(а): >> >> примерно так >> >> [root на xxx ~]# cat /lib/systemd/system/nginx на .service >> [Unit] >> Description=nginx - high performance web server instance %i >> Documentation=http://nginx.org/en/docs/ >> After=network-online.target remote-fs.target nss-lookup.target >> Wants=network-online.target >> >> [Service] >> Type=forking >> PIDFile=/var/run/nginx-%i.pid >> ExecStart=/usr/sbin/nginx -c /etc/nginx-%i/nginx.conf -p /etc/nginx-%i -g "pid /var/run/nginx-%i.pid;" >> ExecReload=/bin/kill -s HUP $MAINPID >> ExecStop=/bin/kill -s TERM $MAINPID >> >> [Install] >> WantedBy=multi-user.target >> >> это позволяет за счет параметра (который подставляется в %i) создавать отдельные инстансы. >> > -- Best regards, Andrey A. Kopeyko From chipitsine на gmail.com Tue Sep 18 11:53:17 2018 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 18 Sep 2018 16:53:17 +0500 Subject: =?UTF-8?B?UmU6IFtTcGFtXSBSZTogc3lzdGVtZCBpbnN0YW50aWF0ZWQgdW5pdHMgLSDQvtCx?= =?UTF-8?B?0YHRg9C00LjQvCA/?= In-Reply-To: References: <7939E736-56B1-4052-BD1D-FA9D64D62455@gmail.com> Message-ID: On Tue, Sep 18, 2018, 4:47 PM Andrey Kopeyko wrote: > On Tue, 18 Sep 2018, Seva Kobylin wrote: > > > Ну и второй вопрос — а зачем? :-) В моей голове не так много реальных > > примеров, которые требуют запуск нескольких инстансов мастер-процессов > nginx > > на одной машине. > > Но когда нужно - такой параметризированный unit сильно упрощает жизнь. > Меня опередили)) Ещё добавлю, что для популяризации, пожалуй, стоит этот случай разобрать в документации > > Что предлагается сделать? > > Честно говоря, я не вижу здесь предмета для дискуссии. > > Если мэйнтейнеры откажутся доложить приведённый "nginx на .service" в > поставку - > давайте положим его в contribs/ > > > >> 18 сент. 2018 г., в 13:35, Илья Шипицин > написал(а): > >> > >> примерно так > >> > >> [root на xxx ~]# cat /lib/systemd/system/nginx на .service > >> [Unit] > >> Description=nginx - high performance web server instance %i > >> Documentation=http://nginx.org/en/docs/ > >> After=network-online.target remote-fs.target nss-lookup.target > >> Wants=network-online.target > >> > >> [Service] > >> Type=forking > >> PIDFile=/var/run/nginx-%i.pid > >> ExecStart=/usr/sbin/nginx -c /etc/nginx-%i/nginx.conf -p /etc/nginx-%i > -g "pid /var/run/nginx-%i.pid;" > >> ExecReload=/bin/kill -s HUP $MAINPID > >> ExecStop=/bin/kill -s TERM $MAINPID > >> > >> [Install] > >> WantedBy=multi-user.target > >> > >> это позволяет за счет параметра (который подставляется в %i) > создавать отдельные инстансы. > >> > > > > -- > Best regards, > Andrey A. Kopeyko >_______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From alex.hha на gmail.com Tue Sep 18 12:42:05 2018 From: alex.hha на gmail.com (Alex Domoradov) Date: Tue, 18 Sep 2018 15:42:05 +0300 Subject: =?UTF-8?B?UmU6IFtTcGFtXSBSZTogc3lzdGVtZCBpbnN0YW50aWF0ZWQgdW5pdHMgLSDQvtCx?= =?UTF-8?B?0YHRg9C00LjQvCA/?= In-Reply-To: References: <7939E736-56B1-4052-BD1D-FA9D64D62455@gmail.com> Message-ID: Думаю, что хороший пример, не оторванный от реальности, очень помог бы On Tue, Sep 18, 2018 at 2:53 PM Илья Шипицин wrote: > > > On Tue, Sep 18, 2018, 4:47 PM Andrey Kopeyko wrote: > >> On Tue, 18 Sep 2018, Seva Kobylin wrote: >> >> > Ну и второй вопрос — а зачем? :-) В моей голове не так много реальных >> > примеров, которые требуют запуск нескольких инстансов мастер-процессов >> nginx >> > на одной машине. >> >> Но когда нужно - такой параметризированный unit сильно упрощает жизнь. >> > > Меня опередили)) > > Ещё добавлю, что для популяризации, пожалуй, стоит этот случай разобрать в > документации > > > >> > Что предлагается сделать? >> >> Честно говоря, я не вижу здесь предмета для дискуссии. >> >> Если мэйнтейнеры откажутся доложить приведённый "nginx на .service" в >> поставку - >> давайте положим его в contribs/ >> >> >> >> 18 сент. 2018 г., в 13:35, Илья Шипицин >> написал(а): >> >> >> >> примерно так >> >> >> >> [root на xxx ~]# cat /lib/systemd/system/nginx на .service >> >> [Unit] >> >> Description=nginx - high performance web server instance %i >> >> Documentation=http://nginx.org/en/docs/ >> >> After=network-online.target remote-fs.target nss-lookup.target >> >> Wants=network-online.target >> >> >> >> [Service] >> >> Type=forking >> >> PIDFile=/var/run/nginx-%i.pid >> >> ExecStart=/usr/sbin/nginx -c /etc/nginx-%i/nginx.conf -p /etc/nginx-%i >> -g "pid /var/run/nginx-%i.pid;" >> >> ExecReload=/bin/kill -s HUP $MAINPID >> >> ExecStop=/bin/kill -s TERM $MAINPID >> >> >> >> [Install] >> >> WantedBy=multi-user.target >> >> >> >> это позволяет за счет параметра (который подставляется в %i) >> создавать отдельные инстансы. >> >> >> > >> >> -- >> Best regards, >> Andrey A. Kopeyko > >_______________________________________________ >> 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 ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Tue Sep 18 12:54:26 2018 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 18 Sep 2018 17:54:26 +0500 Subject: =?UTF-8?B?UmU6IFtTcGFtXSBSZTogc3lzdGVtZCBpbnN0YW50aWF0ZWQgdW5pdHMgLSDQvtCx?= =?UTF-8?B?0YHRg9C00LjQvCA/?= In-Reply-To: References: <7939E736-56B1-4052-BD1D-FA9D64D62455@gmail.com> Message-ID: вт, 18 сент. 2018 г. в 17:42, Alex Domoradov : > Думаю, что хороший пример, не оторванный от реальности, очень помог бы > например, такая картина конфиги у нас генерируются динамически, приложения есть http, есть stream. stream это, например, RDP stream меняются очень редко, http меняются часто. если мы делаем reload - у пользователей RDP в это время рвутся сессии (потому что завершаются старые воркеры через worker_shutdown_timeout) если мы делим на 2 инстанса, то каждый инстанс reload-ится по своей логике > > On Tue, Sep 18, 2018 at 2:53 PM Илья Шипицин wrote: > >> >> >> On Tue, Sep 18, 2018, 4:47 PM Andrey Kopeyko wrote: >> >>> On Tue, 18 Sep 2018, Seva Kobylin wrote: >>> >>> > Ну и второй вопрос — а зачем? :-) В моей голове не так много реальных >>> > примеров, которые требуют запуск нескольких инстансов мастер-процессов >>> nginx >>> > на одной машине. >>> >>> Но когда нужно - такой параметризированный unit сильно упрощает жизнь. >>> >> >> Меня опередили)) >> >> Ещё добавлю, что для популяризации, пожалуй, стоит этот случай разобрать >> в документации >> >> >> >>> > Что предлагается сделать? >>> >>> Честно говоря, я не вижу здесь предмета для дискуссии. >>> >>> Если мэйнтейнеры откажутся доложить приведённый "nginx на .service" в >>> поставку - >>> давайте положим его в contribs/ >>> >>> >>> >> 18 сент. 2018 г., в 13:35, Илья Шипицин >>> написал(а): >>> >> >>> >> примерно так >>> >> >>> >> [root на xxx ~]# cat /lib/systemd/system/nginx на .service >>> >> [Unit] >>> >> Description=nginx - high performance web server instance %i >>> >> Documentation=http://nginx.org/en/docs/ >>> >> After=network-online.target remote-fs.target nss-lookup.target >>> >> Wants=network-online.target >>> >> >>> >> [Service] >>> >> Type=forking >>> >> PIDFile=/var/run/nginx-%i.pid >>> >> ExecStart=/usr/sbin/nginx -c /etc/nginx-%i/nginx.conf -p >>> /etc/nginx-%i -g "pid /var/run/nginx-%i.pid;" >>> >> ExecReload=/bin/kill -s HUP $MAINPID >>> >> ExecStop=/bin/kill -s TERM $MAINPID >>> >> >>> >> [Install] >>> >> WantedBy=multi-user.target >>> >> >>> >> это позволяет за счет параметра (который подставляется в %i) >>> создавать отдельные инстансы. >>> >> >>> > >>> >>> -- >>> Best regards, >>> Andrey A. Kopeyko >> >_______________________________________________ >>> 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 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Tue Sep 18 13:02:18 2018 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 18 Sep 2018 18:02:18 +0500 Subject: =?UTF-8?B?UmU6IFtTcGFtXSBSZTogc3lzdGVtZCBpbnN0YW50aWF0ZWQgdW5pdHMgLSDQvtCx?= =?UTF-8?B?0YHRg9C00LjQvCA/?= In-Reply-To: References: <7939E736-56B1-4052-BD1D-FA9D64D62455@gmail.com> Message-ID: вт, 18 сент. 2018 г. в 17:42, Alex Domoradov : > Думаю, что хороший пример, не оторванный от реальности, очень помог бы > еще такой пример - вы предоставляете as a service штуку, которая генерит конфиг и применяет его. и у вас несколько потребителей (приложений) если конфиг общий и какое-то приложение сгенерило себе битый конфиг, то не reload-ится у всех, и все ждут, пока починят. если вы пилите на инстансы, то каждая команда делает reload и ни от кого не зависит > > On Tue, Sep 18, 2018 at 2:53 PM Илья Шипицин wrote: > >> >> >> On Tue, Sep 18, 2018, 4:47 PM Andrey Kopeyko wrote: >> >>> On Tue, 18 Sep 2018, Seva Kobylin wrote: >>> >>> > Ну и второй вопрос — а зачем? :-) В моей голове не так много реальных >>> > примеров, которые требуют запуск нескольких инстансов мастер-процессов >>> nginx >>> > на одной машине. >>> >>> Но когда нужно - такой параметризированный unit сильно упрощает жизнь. >>> >> >> Меня опередили)) >> >> Ещё добавлю, что для популяризации, пожалуй, стоит этот случай разобрать >> в документации >> >> >> >>> > Что предлагается сделать? >>> >>> Честно говоря, я не вижу здесь предмета для дискуссии. >>> >>> Если мэйнтейнеры откажутся доложить приведённый "nginx на .service" в >>> поставку - >>> давайте положим его в contribs/ >>> >>> >>> >> 18 сент. 2018 г., в 13:35, Илья Шипицин >>> написал(а): >>> >> >>> >> примерно так >>> >> >>> >> [root на xxx ~]# cat /lib/systemd/system/nginx на .service >>> >> [Unit] >>> >> Description=nginx - high performance web server instance %i >>> >> Documentation=http://nginx.org/en/docs/ >>> >> After=network-online.target remote-fs.target nss-lookup.target >>> >> Wants=network-online.target >>> >> >>> >> [Service] >>> >> Type=forking >>> >> PIDFile=/var/run/nginx-%i.pid >>> >> ExecStart=/usr/sbin/nginx -c /etc/nginx-%i/nginx.conf -p >>> /etc/nginx-%i -g "pid /var/run/nginx-%i.pid;" >>> >> ExecReload=/bin/kill -s HUP $MAINPID >>> >> ExecStop=/bin/kill -s TERM $MAINPID >>> >> >>> >> [Install] >>> >> WantedBy=multi-user.target >>> >> >>> >> это позволяет за счет параметра (который подставляется в %i) >>> создавать отдельные инстансы. >>> >> >>> > >>> >>> -- >>> Best regards, >>> Andrey A. Kopeyko >> >_______________________________________________ >>> 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 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From gmm на csdoc.com Tue Sep 18 14:01:07 2018 From: gmm на csdoc.com (Gena Makhomed) Date: Tue, 18 Sep 2018 17:01:07 +0300 Subject: OCSP stapling in Nginx >=1.3.7 In-Reply-To: <20180916233654.GD56558@mdounin.ru> References: <20180910130419.GC56558@mdounin.ru> <20180911032109.GK56558@mdounin.ru> <20180911123810.GM56558@mdounin.ru> <1d4bed82-2b3d-b6a4-ba6d-16e8872134ad@csdoc.com> <20180911155920.GP56558@mdounin.ru> <01c41dde-d08a-df21-e423-63659c6dd7ad@csdoc.com> <20180912143606.GQ56558@mdounin.ru> <16a36038-8ad8-27b2-5417-f16354a9cfe9@csdoc.com> <20180916233654.GD56558@mdounin.ru> Message-ID: <8ee9b91c-606b-26e9-9ecb-16c49583ab8b@csdoc.com> On 17.09.2018 2:36, Maxim Dounin wrote: >>>>>>>>> Лучше всего - сделать так, чтобы OpenSSL научился проверять >>>>>>>>> OCSP-ответы не полной цепочкой сертификатов вплоть до доверенного >>>>>>>>> root'а, а ровно так, как и должно быть по стандарту - с помощью >>>>>>>>> одного только сертификата issuer'а. Тогда проблема исчезнет. Над OCSP в OpenSSL работал Rob Stradling из Comodo, может быть имеет смысл к нему обратиться с просьбой исправить эту проблему в OpenSSL? >> Кстати, пользователи жалуются, что есть BUG в nginx, >> связанный с сертификатами с флагом "OCSP Must Staple": >> https://blog.crashed.org/nginx-stapling-busted/ > Потому что "Must Staple" - это попытка превратить OCSP stapling > из механизма оптимизации в обязательный механизм, аналогичный > короткоживущим сертификатам. Не сюрприз, что так не работает - > требования совершенно разные. RFC 7633 был создан сотрудником Comodo, в RFC он пишет, что цель RFC - "prevents a denial-of-service attack". Сейчас, если кто-то с помощью DDoS-атаки заблокирует OCSP responder - клиенты не смогут отличить отозванный сертификат от действительного. При массовом внедрении флага OCSP Must-Staple в сертификаты - делать DDoS-атаки на OCSP responder не будет иметь смысла. То есть цель у флага OCSP Must-Staple наверное та же самая, что и у OCSP Stapling - снизить нагрузку на инфраструктуру CA. Кстати, тест на ssllabs.com показывает OCSP Must-Staple зеленым цветом. Ivan Ristic как бы намекает, что это полезный флаг и его стоит включить. > Любители Must Staple общаются в траке в двух тикетах: > > https://trac.nginx.org/nginx/ticket/812 > https://trac.nginx.org/nginx/ticket/990 > > Пока что они делают это с нулевым полезным выходом. Они в основном там просят сделать возможным указывать в конфиге несколько директив ssl_stapling_file для ECDSA и RSA сертификатов. Но есть ведь и другие способы решения этой проблемы, например, чтобы nginx получал OCSP-ответ для сертификата с Must-Staple до того, как он отправит свой ответ клиенту. Пользователю ведь нет разницы, кто сходит за OCSP-ответом для сертификата - или браузер или сам веб-сервер. Разумеется, не отправлять ответ клиенту без OCSP Stapling'а имеет смысл только для тех сертификатов, у которых установлен флаг OCSP Must-Staple. P.S. Кстати, если посмотреть через https://www.ssllabs.com/ssltest/ на сайты nginx.org и nginx.com, то видно, что с nginx.org все нормально, а вот nginx.com настроен не совсем оптимально. Наверное самый простой вариант корректной настройки сервера: # OpenSSL, ssl_ciphers и nginx: прокачиваем на 100% # https://habrahabr.ru/post/325230/ ssl_prefer_server_ciphers on; ssl_protocols TLSv1.3 TLSv1.2 TLSv1.1 TLSv1; ssl_ciphers EECDH:+AES256:-3DES:RSA+AES:RSA+3DES:!NULL:!RC4; Может быть имеет смысл сделать эти значения значениями по-умолчанию в nginx? -- Best regards, Gena From chipitsine на gmail.com Tue Sep 18 16:18:52 2018 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 18 Sep 2018 21:18:52 +0500 Subject: OCSP stapling in Nginx >=1.3.7 In-Reply-To: <8ee9b91c-606b-26e9-9ecb-16c49583ab8b@csdoc.com> References: <20180910130419.GC56558@mdounin.ru> <20180911032109.GK56558@mdounin.ru> <20180911123810.GM56558@mdounin.ru> <1d4bed82-2b3d-b6a4-ba6d-16e8872134ad@csdoc.com> <20180911155920.GP56558@mdounin.ru> <01c41dde-d08a-df21-e423-63659c6dd7ad@csdoc.com> <20180912143606.GQ56558@mdounin.ru> <16a36038-8ad8-27b2-5417-f16354a9cfe9@csdoc.com> <20180916233654.GD56558@mdounin.ru> <8ee9b91c-606b-26e9-9ecb-16c49583ab8b@csdoc.com> Message-ID: вт, 18 сент. 2018 г. в 19:01, Gena Makhomed : > On 17.09.2018 2:36, Maxim Dounin wrote: > > >>>>>>>>> Лучше всего - сделать так, чтобы OpenSSL научился проверять > >>>>>>>>> OCSP-ответы не полной цепочкой сертификатов вплоть до доверенного > >>>>>>>>> root'а, а ровно так, как и должно быть по стандарту - с помощью > >>>>>>>>> одного только сертификата issuer'а. Тогда проблема исчезнет. > > Над OCSP в OpenSSL работал Rob Stradling из Comodo, может быть имеет > смысл к нему обратиться с просьбой исправить эту проблему в OpenSSL? > > >> Кстати, пользователи жалуются, что есть BUG в nginx, > >> связанный с сертификатами с флагом "OCSP Must Staple": > >> https://blog.crashed.org/nginx-stapling-busted/ > > > Потому что "Must Staple" - это попытка превратить OCSP stapling > > из механизма оптимизации в обязательный механизм, аналогичный > > короткоживущим сертификатам. Не сюрприз, что так не работает - > > требования совершенно разные. > > RFC 7633 был создан сотрудником Comodo, в RFC он пишет, > что цель RFC - "prevents a denial-of-service attack". > > Сейчас, если кто-то с помощью DDoS-атаки заблокирует OCSP responder > - клиенты не смогут отличить отозванный сертификат от действительного. > > При массовом внедрении флага OCSP Must-Staple в сертификаты > - делать DDoS-атаки на OCSP responder не будет иметь смысла. > вы и правы и неправы одновременно. Must-Staple обязывает отдать OCSP ответ. вопрос в том, как с OCSP будет работать https-сервер. если он попытается пойти за OCSP в момент, когда к нему подключается браузер (а инфраструктура CA "лежит"), то это одно. если https-сервер озаботился и сходил за OCSP заранее, то наличие или отсутствие работающей инфраструктуры CA становится менее важным. полностью исключить инфраструктуру СА из цепочки нельзя в силу дизайна протокола (надо будет почитать, допустимы ли кросс-подписи для OCSP ....) > > То есть цель у флага OCSP Must-Staple наверное та же самая, > что и у OCSP Stapling - снизить нагрузку на инфраструктуру CA. > цель у этого флага непонятна никому. есть ощущение, что (как и многие аспекты TLS/SSL) это просто не очень продуманный дизайн. > > Кстати, тест на ssllabs.com показывает OCSP Must-Staple зеленым цветом. > Ivan Ristic как бы намекает, что это полезный флаг и его стоит включить. > > > Любители Must Staple общаются в траке в двух тикетах: > > > > https://trac.nginx.org/nginx/ticket/812 > > https://trac.nginx.org/nginx/ticket/990 > > > > Пока что они делают это с нулевым полезным выходом. > > Они в основном там просят сделать возможным указывать в конфиге > несколько директив ssl_stapling_file для ECDSA и RSA сертификатов. > > Но есть ведь и другие способы решения этой проблемы, например, > чтобы nginx получал OCSP-ответ для сертификата с Must-Staple до того, > как он отправит свой ответ клиенту. Пользователю ведь нет разницы, кто > сходит за OCSP-ответом для сертификата - или браузер или сам веб-сервер. > > Разумеется, не отправлять ответ клиенту без OCSP Stapling'а имеет смысл > только для тех сертификатов, у которых установлен флаг OCSP Must-Staple. > > P.S. > > Кстати, если посмотреть через https://www.ssllabs.com/ssltest/ > на сайты nginx.org и nginx.com, то видно, что с nginx.org все > нормально, а вот nginx.com настроен не совсем оптимально. > > Наверное самый простой вариант корректной настройки сервера: > > # OpenSSL, ssl_ciphers и nginx: прокачиваем на 100% > # https://habrahabr.ru/post/325230/ > > ssl_prefer_server_ciphers on; > ssl_protocols TLSv1.3 TLSv1.2 TLSv1.1 TLSv1; > ssl_ciphers EECDH:+AES256:-3DES:RSA+AES:RSA+3DES:!NULL:!RC4; > > Может быть имеет смысл сделать эти значения > значениями по-умолчанию в nginx? > > -- > Best regards, > Gena > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Tue Sep 18 17:03:31 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 18 Sep 2018 20:03:31 +0300 Subject: OCSP stapling in Nginx >=1.3.7 In-Reply-To: <8ee9b91c-606b-26e9-9ecb-16c49583ab8b@csdoc.com> References: <20180911032109.GK56558@mdounin.ru> <20180911123810.GM56558@mdounin.ru> <1d4bed82-2b3d-b6a4-ba6d-16e8872134ad@csdoc.com> <20180911155920.GP56558@mdounin.ru> <01c41dde-d08a-df21-e423-63659c6dd7ad@csdoc.com> <20180912143606.GQ56558@mdounin.ru> <16a36038-8ad8-27b2-5417-f16354a9cfe9@csdoc.com> <20180916233654.GD56558@mdounin.ru> <8ee9b91c-606b-26e9-9ecb-16c49583ab8b@csdoc.com> Message-ID: <20180918170331.GR56558@mdounin.ru> Hello! On Tue, Sep 18, 2018 at 05:01:07PM +0300, Gena Makhomed wrote: > On 17.09.2018 2:36, Maxim Dounin wrote: > > >>>>>>>>> Лучше всего - сделать так, чтобы OpenSSL научился проверять > >>>>>>>>> OCSP-ответы не полной цепочкой сертификатов вплоть до доверенного > >>>>>>>>> root'а, а ровно так, как и должно быть по стандарту - с помощью > >>>>>>>>> одного только сертификата issuer'а. Тогда проблема исчезнет. > > Над OCSP в OpenSSL работал Rob Stradling из Comodo, может быть имеет > смысл к нему обратиться с просьбой исправить эту проблему в OpenSSL? Rob точно учавствовал в обсуждениях, где проблема излагалась, и даже, помнится, пытался что-то править. > >> Кстати, пользователи жалуются, что есть BUG в nginx, > >> связанный с сертификатами с флагом "OCSP Must Staple": > >> https://blog.crashed.org/nginx-stapling-busted/ > > > Потому что "Must Staple" - это попытка превратить OCSP stapling > > из механизма оптимизации в обязательный механизм, аналогичный > > короткоживущим сертификатам. Не сюрприз, что так не работает - > > требования совершенно разные. > > RFC 7633 был создан сотрудником Comodo, в RFC он пишет, > что цель RFC - "prevents a denial-of-service attack". > > Сейчас, если кто-то с помощью DDoS-атаки заблокирует OCSP responder > - клиенты не смогут отличить отозванный сертификат от действительного. > > При массовом внедрении флага OCSP Must-Staple в сертификаты > - делать DDoS-атаки на OCSP responder не будет иметь смысла. > > То есть цель у флага OCSP Must-Staple наверное та же самая, > что и у OCSP Stapling - снизить нагрузку на инфраструктуру CA. Цель "Must Staple", как она обсуждалась на cabforum'е - сделать обязательной проверку отзыва, не нагружая дополнительно инфраструктуру CA. Проблема в том, что нельзя просто так взять механизм оптимизации и сделать из него механизм контроля, это две разные задачи, которые надо решать по-разному. > Кстати, тест на ssllabs.com показывает OCSP Must-Staple зеленым цветом. > Ivan Ristic как бы намекает, что это полезный флаг и его стоит включить. > > > Любители Must Staple общаются в траке в двух тикетах: > > > > https://trac.nginx.org/nginx/ticket/812 > > https://trac.nginx.org/nginx/ticket/990 > > > > Пока что они делают это с нулевым полезным выходом. > > Они в основном там просят сделать возможным указывать в конфиге > несколько директив ssl_stapling_file для ECDSA и RSA сертификатов. > > Но есть ведь и другие способы решения этой проблемы, например, > чтобы nginx получал OCSP-ответ для сертификата с Must-Staple до того, > как он отправит свой ответ клиенту. Пользователю ведь нет разницы, кто > сходит за OCSP-ответом для сертификата - или браузер или сам веб-сервер. > > Разумеется, не отправлять ответ клиенту без OCSP Stapling'а имеет смысл > только для тех сертификатов, у которых установлен флаг OCSP Must-Staple. Проблема для начала в том, что в OpenSSL нет возможности подождать получения OCSP-ответа, не блокируя рабочий процесс nginx'а. > P.S. > > Кстати, если посмотреть через https://www.ssllabs.com/ssltest/ > на сайты nginx.org и nginx.com, то видно, что с nginx.org все > нормально, а вот nginx.com настроен не совсем оптимально. > > Наверное самый простой вариант корректной настройки сервера: > > # OpenSSL, ssl_ciphers и nginx: прокачиваем на 100% > # https://habrahabr.ru/post/325230/ > > ssl_prefer_server_ciphers on; > ssl_protocols TLSv1.3 TLSv1.2 TLSv1.1 TLSv1; > ssl_ciphers EECDH:+AES256:-3DES:RSA+AES:RSA+3DES:!NULL:!RC4; > > Может быть имеет смысл сделать эти значения > значениями по-умолчанию в nginx? Я не считаю использование "ssl_prefer_server_ciphers on" правильным приблизительно нигде, кроме ситуаций, когда автор конфигурации чётко понимает, чего он хочет добиться, и регулярно занимается анализом и пересмотром списка используемых шифров. И даже в этом случае - его использование подчас выходит боком, как например с выбором AES vs. ChaCha20: https://trac.nginx.org/nginx/ticket/1445 Во всех остальных случаях - значение "ssl_prefer_server_ciphers off;", используемое по умолчанию, является лучшим выбором, так как позволяет клиенту самому выбрать, какой шифр для него лучше. Текущие значения по умолчанию - "ssl_prefer_server_ciphers off;" и "ssl_ciphers HIGH:!aNULL:!MD5;" - позволяют получить наилучшую работу SSL с минимальными усилиями. Что до "не совсем оптимально", то рекомендую внимательно посмотреть, на что именно жалуется ssllabs в данном случае. Он жалуется на то, что на практике не будет Forward Secrecy со следующими браузерами: IE 7 / Vista IE 10 / Win Phone 8.0 IE 11 / Win Phone 8.1 То есть речь идёт про старые версии IE на неподдерживаемых операционных системах. При том, что общая доля IE сейчас ~3%. Подозреваю, что у тех, кто всё ещё пользуется этими браузерами - если такие люди ещё действительно остались - есть проблемы серьёзнее, чем отсутствие Forward Secrecy. -- Maxim Dounin http://mdounin.ru/ From mdounin на mdounin.ru Tue Sep 18 17:28:20 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 18 Sep 2018 20:28:20 +0300 Subject: OCSP stapling in Nginx >=1.3.7 In-Reply-To: References: <20180911123810.GM56558@mdounin.ru> <1d4bed82-2b3d-b6a4-ba6d-16e8872134ad@csdoc.com> <20180911155920.GP56558@mdounin.ru> <01c41dde-d08a-df21-e423-63659c6dd7ad@csdoc.com> <20180912143606.GQ56558@mdounin.ru> <16a36038-8ad8-27b2-5417-f16354a9cfe9@csdoc.com> <20180916233654.GD56558@mdounin.ru> <8ee9b91c-606b-26e9-9ecb-16c49583ab8b@csdoc.com> Message-ID: <20180918172820.GS56558@mdounin.ru> Hello! On Tue, Sep 18, 2018 at 09:18:52PM +0500, Илья Шипицин wrote: > вт, 18 сент. 2018 г. в 19:01, Gena Makhomed : [...] > > То есть цель у флага OCSP Must-Staple наверное та же самая, > > что и у OCSP Stapling - снизить нагрузку на инфраструктуру CA. > > цель у этого флага непонятна никому. есть ощущение, что (как и многие > аспекты TLS/SSL) это просто не очень продуманный дизайн. Цель не секрет же - сделать обязательную проверку отзыва сертификата. Против явного флага "обязательно проверять отзыв" активно возражали представители CA - справедливо полагая, что им от таких сертификатов прилетит нагрузки на OCSP-сервера - в результате получилось вот такое вот. -- Maxim Dounin http://mdounin.ru/ From chipitsine на gmail.com Tue Sep 18 17:49:26 2018 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 18 Sep 2018 22:49:26 +0500 Subject: OCSP stapling in Nginx >=1.3.7 In-Reply-To: <20180918172820.GS56558@mdounin.ru> References: <20180911123810.GM56558@mdounin.ru> <1d4bed82-2b3d-b6a4-ba6d-16e8872134ad@csdoc.com> <20180911155920.GP56558@mdounin.ru> <01c41dde-d08a-df21-e423-63659c6dd7ad@csdoc.com> <20180912143606.GQ56558@mdounin.ru> <16a36038-8ad8-27b2-5417-f16354a9cfe9@csdoc.com> <20180916233654.GD56558@mdounin.ru> <8ee9b91c-606b-26e9-9ecb-16c49583ab8b@csdoc.com> <20180918172820.GS56558@mdounin.ru> Message-ID: вт, 18 сент. 2018 г. в 22:28, Maxim Dounin : > Hello! > > On Tue, Sep 18, 2018 at 09:18:52PM +0500, Илья Шипицин wrote: > > > вт, 18 сент. 2018 г. в 19:01, Gena Makhomed : > > [...] > > > > То есть цель у флага OCSP Must-Staple наверное та же самая, > > > что и у OCSP Stapling - снизить нагрузку на инфраструктуру CA. > > > > цель у этого флага непонятна никому. есть ощущение, что (как и многие > > аспекты TLS/SSL) это просто не очень продуманный дизайн. > > Цель не секрет же - сделать обязательную проверку отзыва > сертификата. Против явного флага "обязательно проверять отзыв" > активно возражали представители CA - справедливо полагая, что им > от таких сертификатов прилетит нагрузки на OCSP-сервера - в > результате получилось вот такое вот. > собственно, через CDP/CRL проверка не менее "обязательная" тут вопрос в том, что они хотели сделать обязательной именно OCSP проверку подозреваю, что на клиенте можно любую отключить (CDP/CRL точно, OCSP не смотрел еще как) > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Tue Sep 18 19:09:07 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 18 Sep 2018 22:09:07 +0300 Subject: OCSP stapling in Nginx >=1.3.7 In-Reply-To: References: <1d4bed82-2b3d-b6a4-ba6d-16e8872134ad@csdoc.com> <20180911155920.GP56558@mdounin.ru> <01c41dde-d08a-df21-e423-63659c6dd7ad@csdoc.com> <20180912143606.GQ56558@mdounin.ru> <16a36038-8ad8-27b2-5417-f16354a9cfe9@csdoc.com> <20180916233654.GD56558@mdounin.ru> <8ee9b91c-606b-26e9-9ecb-16c49583ab8b@csdoc.com> <20180918172820.GS56558@mdounin.ru> Message-ID: <20180918190907.GT56558@mdounin.ru> Hello! On Tue, Sep 18, 2018 at 10:49:26PM +0500, Илья Шипицин wrote: > вт, 18 сент. 2018 г. в 22:28, Maxim Dounin : > > > Hello! > > > > On Tue, Sep 18, 2018 at 09:18:52PM +0500, Илья Шипицин wrote: > > > > > вт, 18 сент. 2018 г. в 19:01, Gena Makhomed : > > > > [...] > > > > > > То есть цель у флага OCSP Must-Staple наверное та же самая, > > > > что и у OCSP Stapling - снизить нагрузку на инфраструктуру CA. > > > > > > цель у этого флага непонятна никому. есть ощущение, что (как и многие > > > аспекты TLS/SSL) это просто не очень продуманный дизайн. > > > > Цель не секрет же - сделать обязательную проверку отзыва > > сертификата. Против явного флага "обязательно проверять отзыв" > > активно возражали представители CA - справедливо полагая, что им > > от таких сертификатов прилетит нагрузки на OCSP-сервера - в > > результате получилось вот такое вот. > > > > собственно, через CDP/CRL проверка не менее "обязательная" > тут вопрос в том, что они хотели сделать обязательной именно OCSP проверку > > подозреваю, что на клиенте можно любую отключить (CDP/CRL точно, OCSP не > смотрел еще как) Проблема в том, что сейчас (и всегда) проверка отзыва - не является обязательной. И, более того, количество случайных ошибок при проверках отзыва сертификатов таково, что даже если браузер проверяет отзыв сертификата, то в случае ошибки - всё равно даёт доступ к сайту (aka "soft fail"). Это приводит к тому, что фактически revocation не работает - даже если клиент пытается проверить отзыв по CRL или OCSP, достаточно на сетевом уровне лишить его возможности связаться с соответствующими серверами - и проверка ни на что не повлияет. При этом идея "давайте всегда проверять отзыв, и если не смогли этого сделать - возвращать клиенту ошибку" (aka "hard fail" для всех по умолчанию) была не близка браузерам, они логично полагали, что будет много случайных ошибок из-за недоступности CDP и/или OCSP-серверов, и пользователи не будут счастливы. Было предложено сделать отдельный флаг в сертификатах, требующий hard fail для конкретного сертификата. Но это в свою очередь не понравилось представителям CA, так как они справедливо полагали, что подобные сертификаты могут создать серьёзную нагрузку на OCSP-сервера (как, впрочем, и на CRL Distribution Points, но браузеры сейчас фактически не пользуются CRL в чистом виде). И "must staple" получился как некоторый итог этого столкновения интересов. По крайней мере как-то так историю появления "must staple" помню я, благо как раз в это время был подписан на cabforum mailing list и наблюдал процесс в развитии. Могу, впрочем, врать в деталях (и не только в деталях) - это было давно, да и моё личное мнение о итоге - влияет на восприятие. IMHO, итог получился так себе - получили ещё одну неработающую технологию вместо логичного флага о том, как следует относиться к ошибкам проверки отзыва сертификата. Можно пытаться сделать эту технологию чуть более работающей - но, кажется, даже при идеальной реализации совсем хорошей она просто не может стать, так как в любом случае у нас существует состояние "сервер запустили, но OCSP-ответ мы получить не можем". Впрочем, возможно на подобное закладываться и не надо, а достаточно улучшить получение и кэширование OCSP-ответов, чтобы минимизировать шансы возникновения подобных проблем, и с практической точки зрения этого будет достаточно. -- Maxim Dounin http://mdounin.ru/ From ngnx8810773a83 на avksrv.org Tue Sep 18 20:08:07 2018 From: ngnx8810773a83 на avksrv.org (Alexey) Date: Tue, 18 Sep 2018 23:08:07 +0300 Subject: OCSP stapling in Nginx >=1.3.7 In-Reply-To: <20180918170331.GR56558@mdounin.ru> References: <20180911032109.GK56558@mdounin.ru> <20180911123810.GM56558@mdounin.ru> <1d4bed82-2b3d-b6a4-ba6d-16e8872134ad@csdoc.com> <20180911155920.GP56558@mdounin.ru> <01c41dde-d08a-df21-e423-63659c6dd7ad@csdoc.com> <20180912143606.GQ56558@mdounin.ru> <16a36038-8ad8-27b2-5417-f16354a9cfe9@csdoc.com> <20180916233654.GD56558@mdounin.ru> <8ee9b91c-606b-26e9-9ecb-16c49583ab8b@csdoc.com> <20180918170331.GR56558@mdounin.ru> Message-ID: День добрый 18.09.2018 20:03, Maxim Dounin пишет: > Hello! > > Проблема для начала в том, что в OpenSSL нет возможности подождать > получения OCSP-ответа, не блокируя рабочий процесс nginx'а. > Смотрели мы на реализацию получение  OCSP ответов нгинксом, во первых если у нас много воркеров, то в каждом воркере кеш свой и в каждом из воркеров после включения, или перегрузки конфигурации кеш, естественно, слетает. и  при достаточно большом трафике на https все воркеры сразу набрасываются на процедуру получения OCSP. Както малопродуктивно, учитывая что сам по себе ответ от ЦА меняется не часто. Первый (сколько то первых) ответ от воркера почти всегда в итоге улетает без OCSP.  В итоге в систему выкатки конфигурации было привнесено средство получения готовых ocsp файлов (через openssl ocsp) для каждого используемого сертификата и раскладывание их по серверам по мере появления изменений. В таком виде процесс получения контролируем, ЦА получает 1 запрос в, условно, сутки, а не по куче от всех воркеров с каждого сервера одновременно. Ответы можно перепроверить. И даже первый ответ от нгинкса с готовым файлом улетает с OCSP всегда. Ошибки получения, если такие случаются ловятся в одном месте, а не по куче еррор логов по всем серверам. Опять же единичные ошибки ни к чему страшному не приводят, всегда есть день-другой запаса по сроку действия прошлого ответа, а если конфигурацию у нгинкса перегрузили, то весь кеш сразу и слетел. флаг Must Staple мы не используем,  но если кто то планирует, то отдавать на откуп получение ответов НГИНКСу, наверное совсем не стоит. зы, кстати если у нгинкса проблемы с получением OCSP от ЦА, но в кеше чтото еще есть с прошлых разов, то, кажется, он отдает последний закешированный ответ и после окончания его действия, что хуже, чем его вообще не отдавать. некоторые браузеры таки начинают ругаться. (понятно, что если получать файл внешним скриптом, то это тоже надо бы обрабатывать и както реагировать. но тут свой скрипт, делай что хочешь. Можно просто выкинуть из конфига соотв команду, если нет достаточно свежего файла.) /Алексей From gmm на csdoc.com Tue Sep 18 21:26:01 2018 From: gmm на csdoc.com (Gena Makhomed) Date: Wed, 19 Sep 2018 00:26:01 +0300 Subject: OCSP stapling in Nginx >=1.3.7 In-Reply-To: <20180918170331.GR56558@mdounin.ru> References: <20180911032109.GK56558@mdounin.ru> <20180911123810.GM56558@mdounin.ru> <1d4bed82-2b3d-b6a4-ba6d-16e8872134ad@csdoc.com> <20180911155920.GP56558@mdounin.ru> <01c41dde-d08a-df21-e423-63659c6dd7ad@csdoc.com> <20180912143606.GQ56558@mdounin.ru> <16a36038-8ad8-27b2-5417-f16354a9cfe9@csdoc.com> <20180916233654.GD56558@mdounin.ru> <8ee9b91c-606b-26e9-9ecb-16c49583ab8b@csdoc.com> <20180918170331.GR56558@mdounin.ru> Message-ID: <84aaaf54-f440-48ce-345c-2997afe7ec83@csdoc.com> On 18.09.2018 20:03, Maxim Dounin wrote: >>>> Кстати, пользователи жалуются, что есть BUG в nginx, >>>> связанный с сертификатами с флагом "OCSP Must Staple": >>>> https://blog.crashed.org/nginx-stapling-busted/ >>> Потому что "Must Staple" - это попытка превратить OCSP stapling >>> из механизма оптимизации в обязательный механизм, аналогичный >>> короткоживущим сертификатам. Не сюрприз, что так не работает - >>> требования совершенно разные. >> RFC 7633 был создан сотрудником Comodo, в RFC он пишет, >> что цель RFC - "prevents a denial-of-service attack". >> >> Сейчас, если кто-то с помощью DDoS-атаки заблокирует OCSP responder >> - клиенты не смогут отличить отозванный сертификат от действительного. >> >> При массовом внедрении флага OCSP Must-Staple в сертификаты >> - делать DDoS-атаки на OCSP responder не будет иметь смысла. >> >> То есть цель у флага OCSP Must-Staple наверное та же самая, >> что и у OCSP Stapling - снизить нагрузку на инфраструктуру CA. > Цель "Must Staple", как она обсуждалась на cabforum'е - сделать > обязательной проверку отзыва, не нагружая дополнительно > инфраструктуру CA. > > Проблема в том, что нельзя просто так взять механизм оптимизации и > сделать из него механизм контроля, это две разные задачи, которые > надо решать по-разному. Если задача стоит "сделать обязательной проверку отзыва, не нагружая дополнительно инфраструктуру CA" - как же можно решить эту задачу другими методами, без флага Must Staple? Ведь флаг "обязательно проверять отзыв через OCSP" создаст очень большую нагрузку на CA - это будет хуже чем Must Staple. Тем более, что сейчас Google Chrome OCSP вообще не использует. Если добавить в сертификат флаг о том, как следует относиться к ошибкам проверки отзыва сертификата - у него может быть всего два варианта, soft fail (то же самое что и отсутствие этого флага), и hard fail, это вариант "Must Staple" перенесенный на уровень браузера, то есть это будет равно флагу "обязательно проверять отзыв через OCSP". >>> Любители Must Staple общаются в траке в двух тикетах: >>> >>> https://trac.nginx.org/nginx/ticket/812 >>> https://trac.nginx.org/nginx/ticket/990 >>> >>> Пока что они делают это с нулевым полезным выходом. >> Они в основном там просят сделать возможным указывать в конфиге >> несколько директив ssl_stapling_file для ECDSA и RSA сертификатов. >> >> Но есть ведь и другие способы решения этой проблемы, например, >> чтобы nginx получал OCSP-ответ для сертификата с Must-Staple до того, >> как он отправит свой ответ клиенту. Пользователю ведь нет разницы, кто >> сходит за OCSP-ответом для сертификата - или браузер или сам веб-сервер. > Проблема для начала в том, что в OpenSSL нет возможности подождать > получения OCSP-ответа, не блокируя рабочий процесс nginx'а. Насколько я понимаю из исходников, nginx делает запрос к OCSP серверу самостоятельно, не блокируя рабочий процесс nginx'а. Очень похожий функционал запроса с "ожиданием" уже реализован в nginx, в директиве proxy_cache_lock - там ведь рабочий процесс не блокируется. > Я не считаю использование "ssl_prefer_server_ciphers on" > правильным приблизительно нигде, кроме ситуаций, когда автор > конфигурации чётко понимает, чего он хочет добиться, и регулярно > занимается анализом и пересмотром списка используемых шифров. > > И даже в этом случае - его использование подчас выходит боком, как > например с выбором AES vs. ChaCha20: > > https://trac.nginx.org/nginx/ticket/1445 Теперь понял, спасибо за подробное объяснение по этому вопросу. Кстати, в веб-сервере gws, который обслуживает сайт www.google.com эта проблема с AES vs. ChaCha20 уже успешно решена, ssltest говорит, что "This server prefers ChaCha20 suites with clients that don't have AES-NI (e.g., Android devices)" -- Best regards, Gena From chipitsine на gmail.com Tue Sep 18 21:59:40 2018 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 19 Sep 2018 02:59:40 +0500 Subject: OCSP stapling in Nginx >=1.3.7 In-Reply-To: <84aaaf54-f440-48ce-345c-2997afe7ec83@csdoc.com> References: <20180911032109.GK56558@mdounin.ru> <20180911123810.GM56558@mdounin.ru> <1d4bed82-2b3d-b6a4-ba6d-16e8872134ad@csdoc.com> <20180911155920.GP56558@mdounin.ru> <01c41dde-d08a-df21-e423-63659c6dd7ad@csdoc.com> <20180912143606.GQ56558@mdounin.ru> <16a36038-8ad8-27b2-5417-f16354a9cfe9@csdoc.com> <20180916233654.GD56558@mdounin.ru> <8ee9b91c-606b-26e9-9ecb-16c49583ab8b@csdoc.com> <20180918170331.GR56558@mdounin.ru> <84aaaf54-f440-48ce-345c-2997afe7ec83@csdoc.com> Message-ID: ср, 19 сент. 2018 г. в 2:26, Gena Makhomed : > On 18.09.2018 20:03, Maxim Dounin wrote: > > >>>> Кстати, пользователи жалуются, что есть BUG в nginx, > >>>> связанный с сертификатами с флагом "OCSP Must Staple": > >>>> https://blog.crashed.org/nginx-stapling-busted/ > > >>> Потому что "Must Staple" - это попытка превратить OCSP stapling > >>> из механизма оптимизации в обязательный механизм, аналогичный > >>> короткоживущим сертификатам. Не сюрприз, что так не работает - > >>> требования совершенно разные. > > >> RFC 7633 был создан сотрудником Comodo, в RFC он пишет, > >> что цель RFC - "prevents a denial-of-service attack". > >> > >> Сейчас, если кто-то с помощью DDoS-атаки заблокирует OCSP responder > >> - клиенты не смогут отличить отозванный сертификат от действительного. > >> > >> При массовом внедрении флага OCSP Must-Staple в сертификаты > >> - делать DDoS-атаки на OCSP responder не будет иметь смысла. > >> > >> То есть цель у флага OCSP Must-Staple наверное та же самая, > >> что и у OCSP Stapling - снизить нагрузку на инфраструктуру CA. > > > Цель "Must Staple", как она обсуждалась на cabforum'е - сделать > > обязательной проверку отзыва, не нагружая дополнительно > > инфраструктуру CA. > > > > Проблема в том, что нельзя просто так взять механизм оптимизации и > > сделать из него механизм контроля, это две разные задачи, которые > > надо решать по-разному. > > Если задача стоит "сделать обязательной проверку отзыва, > не нагружая дополнительно инфраструктуру CA" - как же можно > решить эту задачу другими методами, без флага Must Staple? > SSL соединение может быть установлено, если сервер использует а) действующий сертификат (на текущий момент времени) б) сертификат серверного типа в) сертификат не отозван (это можно проверить через CRL) это, собственно, "другие" методы. известные еще нашим отцам и дедам. но исторически в части CRL все работало не очень стабильно, и браузеры де факто не делают проблемы, если не могут скачать CRL вероятно, они так же не будут делать проблемы с сертами Must Staple > > Ведь флаг "обязательно проверять отзыв через OCSP" создаст > очень большую нагрузку на CA - это будет хуже чем Must Staple. > Тем более, что сейчас Google Chrome OCSP вообще не использует. > > Если добавить в сертификат флаг о том, как следует относиться > к ошибкам проверки отзыва сертификата - у него может быть всего > два варианта, soft fail (то же самое что и отсутствие этого флага), > и hard fail, это вариант "Must Staple" перенесенный на уровень браузера, > то есть это будет равно флагу "обязательно проверять отзыв через OCSP". > > >>> Любители Must Staple общаются в траке в двух тикетах: > >>> > >>> https://trac.nginx.org/nginx/ticket/812 > >>> https://trac.nginx.org/nginx/ticket/990 > >>> > >>> Пока что они делают это с нулевым полезным выходом. > > >> Они в основном там просят сделать возможным указывать в конфиге > >> несколько директив ssl_stapling_file для ECDSA и RSA сертификатов. > >> > >> Но есть ведь и другие способы решения этой проблемы, например, > >> чтобы nginx получал OCSP-ответ для сертификата с Must-Staple до того, > >> как он отправит свой ответ клиенту. Пользователю ведь нет разницы, кто > >> сходит за OCSP-ответом для сертификата - или браузер или сам веб-сервер. > > > Проблема для начала в том, что в OpenSSL нет возможности подождать > > получения OCSP-ответа, не блокируя рабочий процесс nginx'а. > > Насколько я понимаю из исходников, nginx делает запрос к OCSP > серверу самостоятельно, не блокируя рабочий процесс nginx'а. > > Очень похожий функционал запроса с "ожиданием" уже реализован в nginx, > в директиве proxy_cache_lock - там ведь рабочий процесс не блокируется. > > > Я не считаю использование "ssl_prefer_server_ciphers on" > > правильным приблизительно нигде, кроме ситуаций, когда автор > > конфигурации чётко понимает, чего он хочет добиться, и регулярно > > занимается анализом и пересмотром списка используемых шифров. > > > > И даже в этом случае - его использование подчас выходит боком, как > > например с выбором AES vs. ChaCha20: > > > > https://trac.nginx.org/nginx/ticket/1445 > > Теперь понял, спасибо за подробное объяснение по этому вопросу. > на Xeon chacha20 проигрывает, мы сравнили openssl speed -evp chacha20 с openssl speed -evp aes-128-gcm желание приоритезировать chacha20 отпало > > Кстати, в веб-сервере gws, который обслуживает сайт www.google.com > эта проблема с AES vs. ChaCha20 уже успешно решена, ssltest говорит, > что "This server prefers ChaCha20 suites with clients > that don't have AES-NI (e.g., Android devices)" > > -- > Best regards, > Gena > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Wed Sep 19 18:56:08 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 19 Sep 2018 21:56:08 +0300 Subject: OCSP stapling in Nginx >=1.3.7 In-Reply-To: <84aaaf54-f440-48ce-345c-2997afe7ec83@csdoc.com> References: <20180911123810.GM56558@mdounin.ru> <1d4bed82-2b3d-b6a4-ba6d-16e8872134ad@csdoc.com> <20180911155920.GP56558@mdounin.ru> <01c41dde-d08a-df21-e423-63659c6dd7ad@csdoc.com> <20180912143606.GQ56558@mdounin.ru> <16a36038-8ad8-27b2-5417-f16354a9cfe9@csdoc.com> <20180916233654.GD56558@mdounin.ru> <8ee9b91c-606b-26e9-9ecb-16c49583ab8b@csdoc.com> <20180918170331.GR56558@mdounin.ru> <84aaaf54-f440-48ce-345c-2997afe7ec83@csdoc.com> Message-ID: <20180919185608.GZ56558@mdounin.ru> Hello! On Wed, Sep 19, 2018 at 12:26:01AM +0300, Gena Makhomed wrote: > On 18.09.2018 20:03, Maxim Dounin wrote: > > >>>> Кстати, пользователи жалуются, что есть BUG в nginx, > >>>> связанный с сертификатами с флагом "OCSP Must Staple": > >>>> https://blog.crashed.org/nginx-stapling-busted/ > > >>> Потому что "Must Staple" - это попытка превратить OCSP stapling > >>> из механизма оптимизации в обязательный механизм, аналогичный > >>> короткоживущим сертификатам. Не сюрприз, что так не работает - > >>> требования совершенно разные. > > >> RFC 7633 был создан сотрудником Comodo, в RFC он пишет, > >> что цель RFC - "prevents a denial-of-service attack". > >> > >> Сейчас, если кто-то с помощью DDoS-атаки заблокирует OCSP responder > >> - клиенты не смогут отличить отозванный сертификат от действительного. > >> > >> При массовом внедрении флага OCSP Must-Staple в сертификаты > >> - делать DDoS-атаки на OCSP responder не будет иметь смысла. > >> > >> То есть цель у флага OCSP Must-Staple наверное та же самая, > >> что и у OCSP Stapling - снизить нагрузку на инфраструктуру CA. > > > Цель "Must Staple", как она обсуждалась на cabforum'е - сделать > > обязательной проверку отзыва, не нагружая дополнительно > > инфраструктуру CA. > > > > Проблема в том, что нельзя просто так взять механизм оптимизации и > > сделать из него механизм контроля, это две разные задачи, которые > > надо решать по-разному. > > Если задача стоит "сделать обязательной проверку отзыва, > не нагружая дополнительно инфраструктуру CA" - как же можно > решить эту задачу другими методами, без флага Must Staple? Всё так, именно этой цели соответствует решение "must staple". Проблема тут во многом - в целеполагании. [...] > >> Они в основном там просят сделать возможным указывать в конфиге > >> несколько директив ssl_stapling_file для ECDSA и RSA сертификатов. > >> > >> Но есть ведь и другие способы решения этой проблемы, например, > >> чтобы nginx получал OCSP-ответ для сертификата с Must-Staple до того, > >> как он отправит свой ответ клиенту. Пользователю ведь нет разницы, кто > >> сходит за OCSP-ответом для сертификата - или браузер или сам веб-сервер. > > > Проблема для начала в том, что в OpenSSL нет возможности подождать > > получения OCSP-ответа, не блокируя рабочий процесс nginx'а. > > Насколько я понимаю из исходников, nginx делает запрос к OCSP > серверу самостоятельно, не блокируя рабочий процесс nginx'а. > > Очень похожий функционал запроса с "ожиданием" уже реализован в nginx, > в директиве proxy_cache_lock - там ведь рабочий процесс не блокируется. В тот момент, когда от клиента пришло соединение с запросом certificate status и OpenSSL'ем был вызван соответствующий callback - у nginx'а нет возможности как-либо отложить обработку этого соединения. Соответственно либо к этому моменту у nginx'а уже есть соответствующий OCSP-ответ - и тогда он может его отправить клиенту, либо соответствующего OCSP-ответа нет - и тогда он не может его отправить, а максимум что может - это инициировать запрос к OCSP-серверу, чтобы этот ответ получить для последующих клиентов. > > Я не считаю использование "ssl_prefer_server_ciphers on" > > правильным приблизительно нигде, кроме ситуаций, когда автор > > конфигурации чётко понимает, чего он хочет добиться, и регулярно > > занимается анализом и пересмотром списка используемых шифров. > > > > И даже в этом случае - его использование подчас выходит боком, как > > например с выбором AES vs. ChaCha20: > > > > https://trac.nginx.org/nginx/ticket/1445 > > Теперь понял, спасибо за подробное объяснение по этому вопросу. > > Кстати, в веб-сервере gws, который обслуживает сайт www.google.com > эта проблема с AES vs. ChaCha20 уже успешно решена, ssltest говорит, > что "This server prefers ChaCha20 suites with clients > that don't have AES-NI (e.g., Android devices)" Эту проблему можно столь же успешно решить, просто не пытаясь включать "ssl_prefer_server_ciphers". Попытки же изобретать сложную логику - "здесь играем, здесь не играем, здесь рыбу заворачивали" - выглядят, скажем мягко, странно. -- Maxim Dounin http://mdounin.ru/ From mdounin на mdounin.ru Wed Sep 19 19:25:15 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 19 Sep 2018 22:25:15 +0300 Subject: OCSP stapling in Nginx >=1.3.7 In-Reply-To: References: <1d4bed82-2b3d-b6a4-ba6d-16e8872134ad@csdoc.com> <20180911155920.GP56558@mdounin.ru> <01c41dde-d08a-df21-e423-63659c6dd7ad@csdoc.com> <20180912143606.GQ56558@mdounin.ru> <16a36038-8ad8-27b2-5417-f16354a9cfe9@csdoc.com> <20180916233654.GD56558@mdounin.ru> <8ee9b91c-606b-26e9-9ecb-16c49583ab8b@csdoc.com> <20180918170331.GR56558@mdounin.ru> <84aaaf54-f440-48ce-345c-2997afe7ec83@csdoc.com> Message-ID: <20180919192515.GA56558@mdounin.ru> Hello! On Wed, Sep 19, 2018 at 02:59:40AM +0500, Илья Шипицин wrote: [...] > > > Я не считаю использование "ssl_prefer_server_ciphers on" > > > правильным приблизительно нигде, кроме ситуаций, когда автор > > > конфигурации чётко понимает, чего он хочет добиться, и регулярно > > > занимается анализом и пересмотром списка используемых шифров. > > > > > > И даже в этом случае - его использование подчас выходит боком, как > > > например с выбором AES vs. ChaCha20: > > > > > > https://trac.nginx.org/nginx/ticket/1445 > > > > Теперь понял, спасибо за подробное объяснение по этому вопросу. > > > > > на Xeon chacha20 проигрывает, мы сравнили > > openssl speed -evp chacha20 > > с > > openssl speed -evp aes-128-gcm > > желание приоритезировать chacha20 отпало Проблема с ChaCha20 vs. AES - в том, что ChaCha20 получается гораздо менее энергозатратным шифром для мобильных устройств, и его использование вместо AES - позволяет телефонам дольше работать от батарейки. Для нормальных же компьютеров с поддержкой AES-NI - наоборот, лучше AES. Соответственно если хочется получить оптимальный для клиента результат - надо смотреть на то, что хочет клиент. При этом понятно, что для самого сервера - это может быть не самое оптимальное решение, но с учётом производительности что ChaCha20, что AES - это вряд ли будет заметно. -- Maxim Dounin http://mdounin.ru/ From chipitsine на gmail.com Wed Sep 19 19:53:24 2018 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 20 Sep 2018 00:53:24 +0500 Subject: OCSP stapling in Nginx >=1.3.7 In-Reply-To: <20180919192515.GA56558@mdounin.ru> References: <1d4bed82-2b3d-b6a4-ba6d-16e8872134ad@csdoc.com> <20180911155920.GP56558@mdounin.ru> <01c41dde-d08a-df21-e423-63659c6dd7ad@csdoc.com> <20180912143606.GQ56558@mdounin.ru> <16a36038-8ad8-27b2-5417-f16354a9cfe9@csdoc.com> <20180916233654.GD56558@mdounin.ru> <8ee9b91c-606b-26e9-9ecb-16c49583ab8b@csdoc.com> <20180918170331.GR56558@mdounin.ru> <84aaaf54-f440-48ce-345c-2997afe7ec83@csdoc.com> <20180919192515.GA56558@mdounin.ru> Message-ID: чт, 20 сент. 2018 г. в 0:25, Maxim Dounin : > Hello! > > On Wed, Sep 19, 2018 at 02:59:40AM +0500, Илья Шипицин wrote: > > [...] > > > > > Я не считаю использование "ssl_prefer_server_ciphers on" > > > > правильным приблизительно нигде, кроме ситуаций, когда автор > > > > конфигурации чётко понимает, чего он хочет добиться, и регулярно > > > > занимается анализом и пересмотром списка используемых шифров. > > > > > > > > И даже в этом случае - его использование подчас выходит боком, как > > > > например с выбором AES vs. ChaCha20: > > > > > > > > https://trac.nginx.org/nginx/ticket/1445 > > > > > > Теперь понял, спасибо за подробное объяснение по этому вопросу. > > > > > > > > > на Xeon chacha20 проигрывает, мы сравнили > > > > openssl speed -evp chacha20 > > > > с > > > > openssl speed -evp aes-128-gcm > > > > желание приоритезировать chacha20 отпало > > Проблема с ChaCha20 vs. AES - в том, что ChaCha20 получается > гораздо менее энергозатратным шифром для мобильных устройств, > и его использование вместо AES - позволяет телефонам дольше > работать от батарейки. Для нормальных же компьютеров с поддержкой > AES-NI - наоборот, лучше AES. > я думаю, правильно в данном случае поступить таким образом. я эксплуатирую сервера, и снижаю нагрузку на них. а про телефоны пусть голова болит у тех, кто их программирует. голова у них большая )) не надо нам за это переживать > > Соответственно если хочется получить оптимальный для клиента > результат - надо смотреть на то, что хочет клиент. При этом > понятно, что для самого сервера - это может быть не самое > оптимальное решение, но с учётом производительности что ChaCha20, > что AES - это вряд ли будет заметно. > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From gmm на csdoc.com Wed Sep 19 22:31:53 2018 From: gmm на csdoc.com (Gena Makhomed) Date: Thu, 20 Sep 2018 01:31:53 +0300 Subject: OCSP stapling in Nginx >=1.3.7 In-Reply-To: <20180919185608.GZ56558@mdounin.ru> References: <20180911123810.GM56558@mdounin.ru> <1d4bed82-2b3d-b6a4-ba6d-16e8872134ad@csdoc.com> <20180911155920.GP56558@mdounin.ru> <01c41dde-d08a-df21-e423-63659c6dd7ad@csdoc.com> <20180912143606.GQ56558@mdounin.ru> <16a36038-8ad8-27b2-5417-f16354a9cfe9@csdoc.com> <20180916233654.GD56558@mdounin.ru> <8ee9b91c-606b-26e9-9ecb-16c49583ab8b@csdoc.com> <20180918170331.GR56558@mdounin.ru> <84aaaf54-f440-48ce-345c-2997afe7ec83@csdoc.com> <20180919185608.GZ56558@mdounin.ru> Message-ID: On 19.09.2018 21:56, Maxim Dounin wrote: >>> Цель "Must Staple", как она обсуждалась на cabforum'е - сделать >>> обязательной проверку отзыва, не нагружая дополнительно >>> инфраструктуру CA. >>> Проблема в том, что нельзя просто так взять механизм оптимизации и >>> сделать из него механизм контроля, это две разные задачи, которые >>> надо решать по-разному. >> Если задача стоит "сделать обязательной проверку отзыва, >> не нагружая дополнительно инфраструктуру CA" - как же можно >> решить эту задачу другими методами, без флага Must Staple? > Всё так, именно этой цели соответствует решение "must staple". > Проблема тут во многом - в целеполагании. Правильной была бы цель "сделать обязательной проверку отзыва" без каких-либо дополнительных условий? Правильным решением в таком случае был бы флаг в сертификате "обязательно проверять отзыв сертификата", так что если веб-сервер прислал OCSP-ответ прикрепленный к сертификату сервером, браузер использует его, а если веб-сервер ничего не прислал, тогда браузер должен сам в обязательном порядке сделать OCSP-запрос и получить ответ? И только если браузер не смог получить OCSP-ответ, только в этом случае запрещать клиенту доступ к сайту с таким флагом в сертификате? Такое решение задачи наверное было бы наиболее удобным для создателей веб-серверов, но значительно увеличило бы нагрузку на инфраструктуру CA, потому что OCSP Stapling по умолчанию выключен в nginx и нет никаких вариантов, чтобы сделать "ssl_stapling on" по-умолчанию из-за необходимости вручную указывать настройки resolver в конфиге? Для предотвращения DNS-спуфинга ничего иного нельзя придумать, кроме как "использовать DNS-серверы в защищённой доверенной локальной сети"? >>>> Они в основном там просят сделать возможным указывать в конфиге >>>> несколько директив ssl_stapling_file для ECDSA и RSA сертификатов. >>>> >>>> Но есть ведь и другие способы решения этой проблемы, например, >>>> чтобы nginx получал OCSP-ответ для сертификата с Must-Staple до того, >>>> как он отправит свой ответ клиенту. Пользователю ведь нет разницы, кто >>>> сходит за OCSP-ответом для сертификата - или браузер или сам веб-сервер. >>> Проблема для начала в том, что в OpenSSL нет возможности подождать >>> получения OCSP-ответа, не блокируя рабочий процесс nginx'а. >> Насколько я понимаю из исходников, nginx делает запрос к OCSP >> серверу самостоятельно, не блокируя рабочий процесс nginx'а. >> >> Очень похожий функционал запроса с "ожиданием" уже реализован в nginx, >> в директиве proxy_cache_lock - там ведь рабочий процесс не блокируется. > В тот момент, когда от клиента пришло соединение с запросом > certificate status и OpenSSL'ем был вызван соответствующий > callback - у nginx'а нет возможности как-либо отложить обработку > этого соединения. > > Соответственно либо к этому моменту у nginx'а уже есть > соответствующий OCSP-ответ - и тогда он может его отправить > клиенту, либо соответствующего OCSP-ответа нет - и тогда он не > может его отправить, а максимум что может - это инициировать > запрос к OCSP-серверу, чтобы этот ответ получить для последующих > клиентов. У nginx есть отдельный процесс cache manager, который управляет кэшем независимо от рабочих процессов nginx, может быть имеет смысл также сделать ocsp cache manager, который будет заниматься получением и кэшированием OCSP-ответов для всех присутствующих сертификатов? Этот ocsp cache manager может следить за тем, чтобы OCSP-ответы всегда были не устаревшими, и если прошло, например, 50% или 66% времени жизни OCSP-ответа, - тогда он инициирует новый OCSP-запрос и складывает ответы в файловую систему (для быстрого перезапуска) а также в shared memory для быстрого доступа из рабочих процессов nginx. Чтобы минимизировать вероятность получение клиентом ответа сервера без прикрепленного к сертификату OCSP-ответа - ocsp cache manager должен при старте проверить есть ли у него в кэше OCSP-ответы для всех сертификатов, и если нет - сразу же инициировать получение OCSP-ответа, не дожидаясь пока придет первый запрос от клиента. Наверное будет лучше если рабочие процессы nginx'а для SSL-соединений с сертификатами с флагом "Must Staple" будут делать return 444 если у них нет в наличии актуального OCSP-ответа для этого сертификата. Все равно ведь без OCSP-ответа браузеры не будут открывать сайт. >>> Я не считаю использование "ssl_prefer_server_ciphers on" >>> правильным приблизительно нигде, кроме ситуаций, когда автор >>> конфигурации чётко понимает, чего он хочет добиться, и регулярно >>> занимается анализом и пересмотром списка используемых шифров. >>> И даже в этом случае - его использование подчас выходит боком, как >>> например с выбором AES vs. ChaCha20: >>> >>> https://trac.nginx.org/nginx/ticket/1445 >> Теперь понял, спасибо за подробное объяснение по этому вопросу. >> >> Кстати, в веб-сервере gws, который обслуживает сайт www.google.com >> эта проблема с AES vs. ChaCha20 уже успешно решена, ssltest говорит, >> что "This server prefers ChaCha20 suites with clients >> that don't have AES-NI (e.g., Android devices)" > Эту проблему можно столь же успешно решить, просто не пытаясь > включать "ssl_prefer_server_ciphers". Попытки же изобретать > сложную логику - "здесь играем, здесь не играем, здесь рыбу > заворачивали" - выглядят, скажем мягко, странно. Эта сложная логика уже изобретена и встроена в OpenSSL, достаточно только указать флаг SSL_OP_PRIORITIZE_CHACHA. Получается очень красивое решение, так что и Forward Secrecy можно получить с большинством браузеров и мобильные клиенты будут использовать наиболее эффективный для них шифр ChaCha20. https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_options.html SSL_OP_PRIORITIZE_CHACHA When SSL_OP_CIPHER_SERVER_PREFERENCE is set, temporarily reprioritize ChaCha20-Poly1305 ciphers to the top of the server cipher list if a ChaCha20-Poly1305 cipher is at the top of the client cipher list. This helps those clients (e.g. mobile) use ChaCha20-Poly1305 if that cipher is anywhere in the server cipher list; but still allows other clients to use AES and other ciphers. Requires SSL_OP_CIPHER_SERVER_PREFERENCE. -- Best regards, Gena From gmm на csdoc.com Wed Sep 19 22:53:02 2018 From: gmm на csdoc.com (Gena Makhomed) Date: Thu, 20 Sep 2018 01:53:02 +0300 Subject: OCSP stapling in Nginx >=1.3.7 In-Reply-To: References: <20180911032109.GK56558@mdounin.ru> <20180911123810.GM56558@mdounin.ru> <1d4bed82-2b3d-b6a4-ba6d-16e8872134ad@csdoc.com> <20180911155920.GP56558@mdounin.ru> <01c41dde-d08a-df21-e423-63659c6dd7ad@csdoc.com> <20180912143606.GQ56558@mdounin.ru> <16a36038-8ad8-27b2-5417-f16354a9cfe9@csdoc.com> <20180916233654.GD56558@mdounin.ru> <8ee9b91c-606b-26e9-9ecb-16c49583ab8b@csdoc.com> <20180918170331.GR56558@mdounin.ru> Message-ID: On 18.09.2018 23:08, Alexey wrote: > Смотрели мы на реализацию получение  OCSP ответов нгинксом, во первых > если у нас много воркеров, то в каждом воркере кеш свой и в каждом из > воркеров после включения, или перегрузки конфигурации кеш, естественно, > слетает. и  при достаточно большом трафике на https все воркеры сразу > набрасываются на процедуру получения OCSP. Както малопродуктивно, > учитывая что сам по себе ответ от ЦА меняется не часто. Первый (сколько > то первых) ответ от воркера почти всегда в итоге улетает без OCSP.  В > итоге в систему выкатки конфигурации было привнесено средство получения > готовых ocsp файлов (через openssl ocsp) для каждого используемого > сертификата и раскладывание их по серверам по мере появления изменений. > В таком виде процесс получения контролируем, ЦА получает 1 запрос в, > условно, сутки, а не по куче от всех воркеров с каждого сервера > одновременно. Ответы можно перепроверить. И даже первый ответ от нгинкса > с готовым файлом улетает с OCSP всегда. Ошибки получения, если такие > случаются ловятся в одном месте, а не по куче еррор логов по всем > серверам. Опять же единичные ошибки ни к чему страшному не приводят, > всегда есть день-другой запаса по сроку действия прошлого ответа, а если > конфигурацию у нгинкса перегрузили, то весь кеш сразу и слетел. Это не работает, если надо иметь одновременно ECDSA и RSA сертификаты. В https://trac.nginx.org/nginx/ticket/990 о проблеме подробно написано. > флаг Must Staple мы не используем,  но если кто то планирует, то > отдавать на откуп получение ответов НГИНКСу, наверное совсем не стоит. Получать OCSP-ответы и держать их в кэше - это вполне себе работа для веб-сервера. > зы, кстати если у нгинкса проблемы с получением OCSP от ЦА, но в кеше > чтото еще есть с прошлых разов, то, кажется, он отдает последний > закешированный ответ и после окончания его действия, что хуже, чем его > вообще не отдавать. некоторые браузеры таки начинают ругаться. (понятно, > что если получать файл внешним скриптом, то это тоже надо бы > обрабатывать и както реагировать. но тут свой скрипт, делай что хочешь. > Можно просто выкинуть из конфига соотв команду, если нет достаточно > свежего файла.) Эта проблема была исправлена еще в 2015 году: https://trac.nginx.org/nginx/ticket/425#comment:4 -- Best regards, Gena From ngnx8810773a83 на avksrv.org Wed Sep 19 23:43:59 2018 From: ngnx8810773a83 на avksrv.org (Alexey) Date: Thu, 20 Sep 2018 02:43:59 +0300 Subject: OCSP stapling in Nginx >=1.3.7 In-Reply-To: References: <20180911032109.GK56558@mdounin.ru> <20180911123810.GM56558@mdounin.ru> <1d4bed82-2b3d-b6a4-ba6d-16e8872134ad@csdoc.com> <20180911155920.GP56558@mdounin.ru> <01c41dde-d08a-df21-e423-63659c6dd7ad@csdoc.com> <20180912143606.GQ56558@mdounin.ru> <16a36038-8ad8-27b2-5417-f16354a9cfe9@csdoc.com> <20180916233654.GD56558@mdounin.ru> <8ee9b91c-606b-26e9-9ecb-16c49583ab8b@csdoc.com> <20180918170331.GR56558@mdounin.ru> Message-ID: <17d8a5bb-ea5a-e6ff-d8c0-31d8276af044@avksrv.org> 20.09.2018 1:53, Gena Makhomed пишет: > > Эта проблема была исправлена еще в 2015 году: > https://trac.nginx.org/nginx/ticket/425#comment:4 > Все конечно может быть :), и возможно оно и было исправлено, но..., тем не менее оно стрельнуло на 1.14... :/ на веб серверах жестко зарублены исходящие соединения. Для OCSP были дырки до сетей СА.  В один непрекрасный день CA сменил IP и как раз довольно скоро протухли OCSP в кеше ... но как выяснилось очень мало какие браузеры на это реагируют (может быть было бы хуже, если бы было Must Staple, но его там нет) /Алексей From mdounin на mdounin.ru Thu Sep 20 00:06:36 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 20 Sep 2018 03:06:36 +0300 Subject: OCSP stapling in Nginx >=1.3.7 In-Reply-To: References: <20180911155920.GP56558@mdounin.ru> <01c41dde-d08a-df21-e423-63659c6dd7ad@csdoc.com> <20180912143606.GQ56558@mdounin.ru> <16a36038-8ad8-27b2-5417-f16354a9cfe9@csdoc.com> <20180916233654.GD56558@mdounin.ru> <8ee9b91c-606b-26e9-9ecb-16c49583ab8b@csdoc.com> <20180918170331.GR56558@mdounin.ru> <84aaaf54-f440-48ce-345c-2997afe7ec83@csdoc.com> <20180919185608.GZ56558@mdounin.ru> Message-ID: <20180920000636.GC56558@mdounin.ru> Hello! On Thu, Sep 20, 2018 at 01:31:53AM +0300, Gena Makhomed wrote: > On 19.09.2018 21:56, Maxim Dounin wrote: > > >>> Цель "Must Staple", как она обсуждалась на cabforum'е - сделать > >>> обязательной проверку отзыва, не нагружая дополнительно > >>> инфраструктуру CA. > > >>> Проблема в том, что нельзя просто так взять механизм оптимизации и > >>> сделать из него механизм контроля, это две разные задачи, которые > >>> надо решать по-разному. > > >> Если задача стоит "сделать обязательной проверку отзыва, > >> не нагружая дополнительно инфраструктуру CA" - как же можно > >> решить эту задачу другими методами, без флага Must Staple? > > > Всё так, именно этой цели соответствует решение "must staple". > > Проблема тут во многом - в целеполагании. > > Правильной была бы цель "сделать обязательной проверку отзыва" > без каких-либо дополнительных условий? Именно так. Потому что мешать в одну кучу требование о проверке отзыва сертфиката и технические аспекты одного из вариантов этой проверки - это плохой путь. > Правильным решением в таком случае был бы флаг в сертификате > "обязательно проверять отзыв сертификата", так что если веб-сервер > прислал OCSP-ответ прикрепленный к сертификату сервером, браузер > использует его, а если веб-сервер ничего не прислал, тогда браузер > должен сам в обязательном порядке сделать OCSP-запрос и получить ответ? > И только если браузер не смог получить OCSP-ответ, только в этом случае > запрещать клиенту доступ к сайту с таким флагом в сертификате? И это было бы логично: именно так сейчас браузеры, использующие OCSP, и работают, с той лишь разницей, что по результатам неудачной проверки доступ - не запрещают. > Такое решение задачи наверное было бы наиболее удобным для создателей > веб-серверов, но значительно увеличило бы нагрузку на инфраструктуру CA, Не увеличило бы. Потому что по факту - OCSP сейчас и так включён по умолчанию во всех браузерах, его использующих. Более того: был бы однозначный мотив для таких сертификатов включать OCSP stapling, так как это повышало бы надёжность в ситуациях, когда OCSP-сервер оказывался бы по каким-то причинам недоступен. [...] > > В тот момент, когда от клиента пришло соединение с запросом > > certificate status и OpenSSL'ем был вызван соответствующий > > callback - у nginx'а нет возможности как-либо отложить обработку > > этого соединения. > > > > Соответственно либо к этому моменту у nginx'а уже есть > > соответствующий OCSP-ответ - и тогда он может его отправить > > клиенту, либо соответствующего OCSP-ответа нет - и тогда он не > > может его отправить, а максимум что может - это инициировать > > запрос к OCSP-серверу, чтобы этот ответ получить для последующих > > клиентов. > > У nginx есть отдельный процесс cache manager, который управляет кэшем > независимо от рабочих процессов nginx, может быть имеет смысл также > сделать ocsp cache manager, который будет заниматься получением > и кэшированием OCSP-ответов для всех присутствующих сертификатов? Можно сделать много всего. Но это не избавляет от ситуации, когда соединение, в котором надо вернуть OCSP-ответ, уже есть, а самого OCSP-ответа - ещё нет. [...] > > Эту проблему можно столь же успешно решить, просто не пытаясь > > включать "ssl_prefer_server_ciphers". Попытки же изобретать > > сложную логику - "здесь играем, здесь не играем, здесь рыбу > > заворачивали" - выглядят, скажем мягко, странно. > > Эта сложная логика уже изобретена и встроена в OpenSSL, > достаточно только указать флаг SSL_OP_PRIORITIZE_CHACHA. > > Получается очень красивое решение, так что и Forward Secrecy > можно получить с большинством браузеров и мобильные клиенты > будут использовать наиболее эффективный для них шифр ChaCha20. Это что угодно, но только не красивое решение. Люди потратили массу сил и времени на изобретение сложной логики (и теперь хотят, чтобы разработчики nginx'а и все пользователи nginx'а - присоединились к процессу, потому что встроить эту логику в существующий механизм выбора приоритета шифров - не осилили). И всё ради того, чтобы насильно обеспечить Forward Secrecy людям, сознательно забившим на обновление софта. Не говоря уже о том, что аналогичные проблемы - будут возникать в будущем снова и снова. -- Maxim Dounin http://mdounin.ru/ From gmm на csdoc.com Thu Sep 20 02:40:16 2018 From: gmm на csdoc.com (Gena Makhomed) Date: Thu, 20 Sep 2018 05:40:16 +0300 Subject: OCSP stapling in Nginx >=1.3.7 In-Reply-To: <20180920000636.GC56558@mdounin.ru> References: <20180911155920.GP56558@mdounin.ru> <01c41dde-d08a-df21-e423-63659c6dd7ad@csdoc.com> <20180912143606.GQ56558@mdounin.ru> <16a36038-8ad8-27b2-5417-f16354a9cfe9@csdoc.com> <20180916233654.GD56558@mdounin.ru> <8ee9b91c-606b-26e9-9ecb-16c49583ab8b@csdoc.com> <20180918170331.GR56558@mdounin.ru> <84aaaf54-f440-48ce-345c-2997afe7ec83@csdoc.com> <20180919185608.GZ56558@mdounin.ru> <20180920000636.GC56558@mdounin.ru> Message-ID: <7c65d09e-4b49-a0f7-f58e-6cd4f443450e@csdoc.com> On 20.09.2018 3:06, Maxim Dounin wrote: >> Правильной была бы цель "сделать обязательной проверку отзыва" >> без каких-либо дополнительных условий? > Именно так. Потому что мешать в одну кучу требование о проверке > отзыва сертфиката и технические аспекты одного из вариантов этой > проверки - это плохой путь. >> Правильным решением в таком случае был бы флаг в сертификате >> "обязательно проверять отзыв сертификата", так что если веб-сервер >> прислал OCSP-ответ прикрепленный к сертификату сервером, браузер >> использует его, а если веб-сервер ничего не прислал, тогда браузер >> должен сам в обязательном порядке сделать OCSP-запрос и получить ответ? >> И только если браузер не смог получить OCSP-ответ, только в этом случае >> запрещать клиенту доступ к сайту с таким флагом в сертификате? > И это было бы логично: именно так сейчас браузеры, использующие > OCSP, и работают, с той лишь разницей, что по результатам > неудачной проверки доступ - не запрещают. Может быть еще не поздно предложить RFC в котором будет описан такой флаг "сделать обязательной проверку отзыва" ? >> Такое решение задачи наверное было бы наиболее удобным для создателей >> веб-серверов, но значительно увеличило бы нагрузку на инфраструктуру CA, > Не увеличило бы. Потому что по факту - OCSP сейчас и так включён > по умолчанию во всех браузерах, его использующих. Если не увеличило бы, почему же тогда представители CA были против? ======================================== On 18.09.2018 22:09, Maxim Dounin wrote: > Было предложено сделать отдельный флаг в сертификатах, требующий > hard fail для конкретного сертификата. Но это в свою очередь не > понравилось представителям CA, так как они справедливо полагали, > что подобные сертификаты могут создать серьёзную нагрузку на > OCSP-сервера (как, впрочем, и на CRL Distribution Points, но > браузеры сейчас фактически не пользуются CRL в чистом виде). И > "must staple" получился как некоторый итог этого столкновения > интересов. ======================================== >>> В тот момент, когда от клиента пришло соединение с запросом >>> certificate status и OpenSSL'ем был вызван соответствующий >>> callback - у nginx'а нет возможности как-либо отложить обработку >>> этого соединения. >>> >>> Соответственно либо к этому моменту у nginx'а уже есть >>> соответствующий OCSP-ответ - и тогда он может его отправить >>> клиенту, либо соответствующего OCSP-ответа нет - и тогда он не >>> может его отправить, а максимум что может - это инициировать >>> запрос к OCSP-серверу, чтобы этот ответ получить для последующих >>> клиентов. >> У nginx есть отдельный процесс cache manager, который управляет кэшем >> независимо от рабочих процессов nginx, может быть имеет смысл также >> сделать ocsp cache manager, который будет заниматься получением >> и кэшированием OCSP-ответов для всех присутствующих сертификатов? > Можно сделать много всего. Но это не избавляет от ситуации, когда > соединение, в котором надо вернуть OCSP-ответ, уже есть, а самого > OCSP-ответа - ещё нет. Избавляет полностью, если OCSP responder отвечает на запросы. Когда в конфиг добавили новый сертификат и сделали reload - сначала ocsp cache manager убеждается, что у него есть актуальные OCSP-ответы для всех "Must Staple" сертификатов и только после этого применяется новая конфигурация для всех рабочих процессов nginx'а. Когда в конфиг добавили новый сертификат и запустили nginx - сначала запускается ocsp cache manager, убеждается, что у него есть актуальные OCSP-ответы для всех "Must Staple" сертификатов и только после этого запускаются рабочие процессы nginx'а. Когда в процессе работы nginx'а OCSP responder не доступен более чем 50% времени жизни OCSP-ответа - это форс-мажорная ситуация и в таком случае nginx просто закрывает соединение с клиентом для всех соединений с "Must Staple" сертификатами до тех пор, пока актуальный OCSP-ответ не будет получен. Это лучше, чем возвращать клиенту "Must Staple" сертификат без OCSP-ответа. >>> Эту проблему можно столь же успешно решить, просто не пытаясь >>> включать "ssl_prefer_server_ciphers". Попытки же изобретать >>> сложную логику - "здесь играем, здесь не играем, здесь рыбу >>> заворачивали" - выглядят, скажем мягко, странно. >> Эта сложная логика уже изобретена и встроена в OpenSSL, >> достаточно только указать флаг SSL_OP_PRIORITIZE_CHACHA. >> >> Получается очень красивое решение, так что и Forward Secrecy >> можно получить с большинством браузеров и мобильные клиенты >> будут использовать наиболее эффективный для них шифр ChaCha20. > Это что угодно, но только не красивое решение. Люди потратили > массу сил и времени на изобретение сложной логики (и теперь хотят, > чтобы разработчики nginx'а и все пользователи nginx'а - > присоединились к процессу, потому что встроить эту логику в > существующий механизм выбора приоритета шифров - не осилили). > И всё ради того, чтобы насильно обеспечить Forward Secrecy людям, > сознательно забившим на обновление софта. Не только. Директива ssl_prefer_server_ciphers применяется и в тех случаях, когда в каком-то шифре находят уязвимость, тогда этот шифр с помощью серверных приоритетов ставится на последнее место. Совсем выключить нельзя, потому что некоторые клиенты не умеют ничего другого кроме этого шифра. Такое уже было, например, когда нашли уязвимость в RC4. Или когда до того, наоборот, ставили RC4 на первое место, чтобы защититься от уязвимости в браузерах по имени BEAST. В такой ситуации все пользователи nginx'а будут поставлены перед выбором: или защитить клиентов от уязвимости в шифре но при этом быстро съедать батарею у мобильных пользователей или экономить батарею у мобильных пользователей но иметь включенным и выбираемым частью клиентов уязвимый шифр. Если бы была возможность включить SSL_OP_PRIORITIZE_CHACHA через директиву конфигурации nginx - это бы упростило жизнь, тогда можно и уязвимый шифр выключить и батарею экономить. -- Best regards, Gena From chipitsine на gmail.com Thu Sep 20 06:29:52 2018 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 20 Sep 2018 11:29:52 +0500 Subject: OCSP stapling in Nginx >=1.3.7 In-Reply-To: <7c65d09e-4b49-a0f7-f58e-6cd4f443450e@csdoc.com> References: <20180911155920.GP56558@mdounin.ru> <01c41dde-d08a-df21-e423-63659c6dd7ad@csdoc.com> <20180912143606.GQ56558@mdounin.ru> <16a36038-8ad8-27b2-5417-f16354a9cfe9@csdoc.com> <20180916233654.GD56558@mdounin.ru> <8ee9b91c-606b-26e9-9ecb-16c49583ab8b@csdoc.com> <20180918170331.GR56558@mdounin.ru> <84aaaf54-f440-48ce-345c-2997afe7ec83@csdoc.com> <20180919185608.GZ56558@mdounin.ru> <20180920000636.GC56558@mdounin.ru> <7c65d09e-4b49-a0f7-f58e-6cd4f443450e@csdoc.com> Message-ID: On Thu, Sep 20, 2018, 7:40 AM Gena Makhomed wrote: > On 20.09.2018 3:06, Maxim Dounin wrote: > > >> Правильной была бы цель "сделать обязательной проверку отзыва" > >> без каких-либо дополнительных условий? > > > Именно так. Потому что мешать в одну кучу требование о проверке > > отзыва сертфиката и технические аспекты одного из вариантов этой > > проверки - это плохой путь. > > >> Правильным решением в таком случае был бы флаг в сертификате > >> "обязательно проверять отзыв сертификата", так что если веб-сервер > >> прислал OCSP-ответ прикрепленный к сертификату сервером, браузер > >> использует его, а если веб-сервер ничего не прислал, тогда браузер > >> должен сам в обязательном порядке сделать OCSP-запрос и получить ответ? > >> И только если браузер не смог получить OCSP-ответ, только в этом случае > >> запрещать клиенту доступ к сайту с таким флагом в сертификате? > > > И это было бы логично: именно так сейчас браузеры, использующие > > OCSP, и работают, с той лишь разницей, что по результатам > > неудачной проверки доступ - не запрещают. > > Может быть еще не поздно предложить RFC в котором будет > описан такой флаг "сделать обязательной проверку отзыва" ? > > >> Такое решение задачи наверное было бы наиболее удобным для создателей > >> веб-серверов, но значительно увеличило бы нагрузку на инфраструктуру CA, > > > Не увеличило бы. Потому что по факту - OCSP сейчас и так включён > > по умолчанию во всех браузерах, его использующих. > > Если не увеличило бы, почему же тогда представители CA были против? > > ======================================== > > On 18.09.2018 22:09, Maxim Dounin wrote: > > > Было предложено сделать отдельный флаг в сертификатах, требующий > > hard fail для конкретного сертификата. Но это в свою очередь не > > понравилось представителям CA, так как они справедливо полагали, > > что подобные сертификаты могут создать серьёзную нагрузку на > > OCSP-сервера (как, впрочем, и на CRL Distribution Points, но > > браузеры сейчас фактически не пользуются CRL в чистом виде). И > > "must staple" получился как некоторый итог этого столкновения > > интересов. > > ======================================== > > >>> В тот момент, когда от клиента пришло соединение с запросом > >>> certificate status и OpenSSL'ем был вызван соответствующий > >>> callback - у nginx'а нет возможности как-либо отложить обработку > >>> этого соединения. > >>> > >>> Соответственно либо к этому моменту у nginx'а уже есть > >>> соответствующий OCSP-ответ - и тогда он может его отправить > >>> клиенту, либо соответствующего OCSP-ответа нет - и тогда он не > >>> может его отправить, а максимум что может - это инициировать > >>> запрос к OCSP-серверу, чтобы этот ответ получить для последующих > >>> клиентов. > > >> У nginx есть отдельный процесс cache manager, который управляет кэшем > >> независимо от рабочих процессов nginx, может быть имеет смысл также > >> сделать ocsp cache manager, который будет заниматься получением > >> и кэшированием OCSP-ответов для всех присутствующих сертификатов? > > > Можно сделать много всего. Но это не избавляет от ситуации, когда > > соединение, в котором надо вернуть OCSP-ответ, уже есть, а самого > > OCSP-ответа - ещё нет. > > Избавляет полностью, если OCSP responder отвечает на запросы. > > Когда в конфиг добавили новый сертификат и сделали reload - > сначала ocsp cache manager убеждается, что у него есть актуальные > OCSP-ответы для всех "Must Staple" сертификатов и только после этого > применяется новая конфигурация для всех рабочих процессов nginx'а. > это выглядит как более удобное решение, чем текущая реализация stapling. объясню. у нас на момент запуска nginx доступ до сети скорее отсутствует, чем присутствует (серверу надо добиться сходимости OSPF) на момент, когда OSPF уже сошелся, на сервер идут запросы, он должен на них отвечать если мы включаем stapling, это выглядит так 1) не, посоны, у вас сети нет, я stapling не могу включить, живите с отключенным 2) после сходимости OSPF можно сделать еще один reload, тогда stapling включается примерно такая же лотерея возникает при ситуации, когда целиком выключается датацентр. включится ли сервер с nginx после того, как запустится сетевое оборудование ? в зависимисоти от этого stapling либо включается, либо нет. вы скажете "а что вы хотели, это же выключение цода". я отвечу, что при выключении цода у меня обычно хватает забот, и мне не до тонкого траблшутинга "а не подергать ли nginx, чтобы он правильно применил stapling" > > Когда в конфиг добавили новый сертификат и запустили nginx - > сначала запускается ocsp cache manager, убеждается, что у него есть > актуальные OCSP-ответы для всех "Must Staple" сертификатов и только > после этого запускаются рабочие процессы nginx'а. > > > > > > Когда в процессе работы nginx'а OCSP responder не доступен более > чем 50% времени жизни OCSP-ответа - это форс-мажорная ситуация > и в таком случае nginx просто закрывает соединение с клиентом > для всех соединений с "Must Staple" сертификатами до тех пор, > пока актуальный OCSP-ответ не будет получен. Это лучше, чем > возвращать клиенту "Must Staple" сертификат без OCSP-ответа. > > >>> Эту проблему можно столь же успешно решить, просто не пытаясь > >>> включать "ssl_prefer_server_ciphers". Попытки же изобретать > >>> сложную логику - "здесь играем, здесь не играем, здесь рыбу > >>> заворачивали" - выглядят, скажем мягко, странно. > > >> Эта сложная логика уже изобретена и встроена в OpenSSL, > >> достаточно только указать флаг SSL_OP_PRIORITIZE_CHACHA. > >> > >> Получается очень красивое решение, так что и Forward Secrecy > >> можно получить с большинством браузеров и мобильные клиенты > >> будут использовать наиболее эффективный для них шифр ChaCha20. > > > Это что угодно, но только не красивое решение. Люди потратили > > массу сил и времени на изобретение сложной логики (и теперь хотят, > > чтобы разработчики nginx'а и все пользователи nginx'а - > > присоединились к процессу, потому что встроить эту логику в > > существующий механизм выбора приоритета шифров - не осилили). > > И всё ради того, чтобы насильно обеспечить Forward Secrecy людям, > > сознательно забившим на обновление софта. > > Не только. Директива ssl_prefer_server_ciphers применяется > и в тех случаях, когда в каком-то шифре находят уязвимость, > тогда этот шифр с помощью серверных приоритетов ставится > на последнее место. Совсем выключить нельзя, потому что > некоторые клиенты не умеют ничего другого кроме этого шифра. > Такое уже было, например, когда нашли уязвимость в RC4. > Или когда до того, наоборот, ставили RC4 на первое место, > чтобы защититься от уязвимости в браузерах по имени BEAST. > > В такой ситуации все пользователи nginx'а будут поставлены > перед выбором: или защитить клиентов от уязвимости в шифре > но при этом быстро съедать батарею у мобильных пользователей > или экономить батарею у мобильных пользователей но иметь > включенным и выбираемым частью клиентов уязвимый шифр. > > Если бы была возможность включить SSL_OP_PRIORITIZE_CHACHA > через директиву конфигурации nginx - это бы упростило жизнь, > тогда можно и уязвимый шифр выключить и батарею экономить. > > -- > Best regards, > Gena > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Thu Sep 20 13:01:46 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 20 Sep 2018 16:01:46 +0300 Subject: OCSP stapling in Nginx >=1.3.7 In-Reply-To: <7c65d09e-4b49-a0f7-f58e-6cd4f443450e@csdoc.com> References: <20180912143606.GQ56558@mdounin.ru> <16a36038-8ad8-27b2-5417-f16354a9cfe9@csdoc.com> <20180916233654.GD56558@mdounin.ru> <8ee9b91c-606b-26e9-9ecb-16c49583ab8b@csdoc.com> <20180918170331.GR56558@mdounin.ru> <84aaaf54-f440-48ce-345c-2997afe7ec83@csdoc.com> <20180919185608.GZ56558@mdounin.ru> <20180920000636.GC56558@mdounin.ru> <7c65d09e-4b49-a0f7-f58e-6cd4f443450e@csdoc.com> Message-ID: <20180920130146.GE56558@mdounin.ru> Hello! On Thu, Sep 20, 2018 at 05:40:16AM +0300, Gena Makhomed wrote: > On 20.09.2018 3:06, Maxim Dounin wrote: > > >> Правильной была бы цель "сделать обязательной проверку отзыва" > >> без каких-либо дополнительных условий? > > > Именно так. Потому что мешать в одну кучу требование о проверке > > отзыва сертфиката и технические аспекты одного из вариантов этой > > проверки - это плохой путь. > > >> Правильным решением в таком случае был бы флаг в сертификате > >> "обязательно проверять отзыв сертификата", так что если веб-сервер > >> прислал OCSP-ответ прикрепленный к сертификату сервером, браузер > >> использует его, а если веб-сервер ничего не прислал, тогда браузер > >> должен сам в обязательном порядке сделать OCSP-запрос и получить ответ? > >> И только если браузер не смог получить OCSP-ответ, только в этом случае > >> запрещать клиенту доступ к сайту с таким флагом в сертификате? > > > И это было бы логично: именно так сейчас браузеры, использующие > > OCSP, и работают, с той лишь разницей, что по результатам > > неудачной проверки доступ - не запрещают. > > Может быть еще не поздно предложить RFC в котором будет > описан такой флаг "сделать обязательной проверку отзыва" ? Лично я - далёк от того, чтобы заниматься вопросами стандартизации чего бы то ни было. Возможно, "must staple" сам рано или поздно мигрирует в такое поведение. > >> Такое решение задачи наверное было бы наиболее удобным для создателей > >> веб-серверов, но значительно увеличило бы нагрузку на инфраструктуру CA, > > > Не увеличило бы. Потому что по факту - OCSP сейчас и так включён > > по умолчанию во всех браузерах, его использующих. > > Если не увеличило бы, почему же тогда представители CA были против? ЕМНИП, на тот момент проверка отзыва был в большинстве браузеров по умолчанию выключена. > >>> В тот момент, когда от клиента пришло соединение с запросом > >>> certificate status и OpenSSL'ем был вызван соответствующий > >>> callback - у nginx'а нет возможности как-либо отложить обработку > >>> этого соединения. > >>> > >>> Соответственно либо к этому моменту у nginx'а уже есть > >>> соответствующий OCSP-ответ - и тогда он может его отправить > >>> клиенту, либо соответствующего OCSP-ответа нет - и тогда он не > >>> может его отправить, а максимум что может - это инициировать > >>> запрос к OCSP-серверу, чтобы этот ответ получить для последующих > >>> клиентов. > > >> У nginx есть отдельный процесс cache manager, который управляет кэшем > >> независимо от рабочих процессов nginx, может быть имеет смысл также > >> сделать ocsp cache manager, который будет заниматься получением > >> и кэшированием OCSP-ответов для всех присутствующих сертификатов? > > > Можно сделать много всего. Но это не избавляет от ситуации, когда > > соединение, в котором надо вернуть OCSP-ответ, уже есть, а самого > > OCSP-ответа - ещё нет. > > Избавляет полностью, если OCSP responder отвечает на запросы. > > Когда в конфиг добавили новый сертификат и сделали reload - > сначала ocsp cache manager убеждается, что у него есть актуальные > OCSP-ответы для всех "Must Staple" сертификатов и только после этого > применяется новая конфигурация для всех рабочих процессов nginx'а. > > Когда в конфиг добавили новый сертификат и запустили nginx - > сначала запускается ocsp cache manager, убеждается, что у него есть > актуальные OCSP-ответы для всех "Must Staple" сертификатов и только > после этого запускаются рабочие процессы nginx'а. > > Когда в процессе работы nginx'а OCSP responder не доступен более > чем 50% времени жизни OCSP-ответа - это форс-мажорная ситуация > и в таком случае nginx просто закрывает соединение с клиентом > для всех соединений с "Must Staple" сертификатами до тех пор, > пока актуальный OCSP-ответ не будет получен. Это лучше, чем > возвращать клиенту "Must Staple" сертификат без OCSP-ответа. О чём и речь. Во всей этой конструкции - описано множество вещей, которые надо программировать, чтобы "must staple" хоть как-то заработал. И вещей, которые надо делать на старте nginx'а - просто для того, чтобы начать работать. И при этом нет сколь-либо разумного решения для ситуации, когда OCSP responder по каким-то причинам оказывается недоступен. Закрывать соединения - это плохой, негодный подход. Очень напоминает подход "ошибка аллокации памяти - это форс-мажорная ситуация, в таком случае надо делать abort(), это лучше, чем продолжать работать". При этом всего этого можно было бы легко избежать, не пытаясь вводить "must staple" вместо требования проверки отзыва. > >>> Эту проблему можно столь же успешно решить, просто не пытаясь > >>> включать "ssl_prefer_server_ciphers". Попытки же изобретать > >>> сложную логику - "здесь играем, здесь не играем, здесь рыбу > >>> заворачивали" - выглядят, скажем мягко, странно. > > >> Эта сложная логика уже изобретена и встроена в OpenSSL, > >> достаточно только указать флаг SSL_OP_PRIORITIZE_CHACHA. > >> > >> Получается очень красивое решение, так что и Forward Secrecy > >> можно получить с большинством браузеров и мобильные клиенты > >> будут использовать наиболее эффективный для них шифр ChaCha20. > > > Это что угодно, но только не красивое решение. Люди потратили > > массу сил и времени на изобретение сложной логики (и теперь хотят, > > чтобы разработчики nginx'а и все пользователи nginx'а - > > присоединились к процессу, потому что встроить эту логику в > > существующий механизм выбора приоритета шифров - не осилили). > > И всё ради того, чтобы насильно обеспечить Forward Secrecy людям, > > сознательно забившим на обновление софта. > > Не только. Директива ssl_prefer_server_ciphers применяется > и в тех случаях, когда в каком-то шифре находят уязвимость, > тогда этот шифр с помощью серверных приоритетов ставится > на последнее место. Совсем выключить нельзя, потому что > некоторые клиенты не умеют ничего другого кроме этого шифра. > Такое уже было, например, когда нашли уязвимость в RC4. > Или когда до того, наоборот, ставили RC4 на первое место, > чтобы защититься от уязвимости в браузерах по имени BEAST. Случаи с RC4, на самом деле, хороший пример, почему подобноё управление шифрами - как раз требует чёткого понимания автором конфигурации целей и задач, и требует регулярного пересмотра. Потому что RC4 в nginx'е - по умолчанию запрещён начиная с nginx 0.8.20, выпущенного в 2009 году. И соответственно сначала все его подобавляли для борьбы с BEAST - а потом выпиливали из конфигураций обратно, когда стало понятно, что RC4 даже хуже, чем считалось до этого. При том, что сколько-нибудь реальной исходная проблема с BEAST была - разве что несколько недель после анонса, пока браузеры не выкатили свой аналог OpenSSL'ного "insert empty fragments". > В такой ситуации все пользователи nginx'а будут поставлены > перед выбором: или защитить клиентов от уязвимости в шифре > но при этом быстро съедать батарею у мобильных пользователей > или экономить батарею у мобильных пользователей но иметь > включенным и выбираемым частью клиентов уязвимый шифр. > > Если бы была возможность включить SSL_OP_PRIORITIZE_CHACHA > через директиву конфигурации nginx - это бы упростило жизнь, > тогда можно и уязвимый шифр выключить и батарею экономить. Я не спорю с тем, что соответствующая возможность - может оказаться полезной в каких-то ситуациях. Мне тут в первую очередь печально, что со стороны OpenSSL получилось очередной ad-hoc решение, требующее отдельной ручки - вместо, например, групп шифров с одинаковым приоритетом в строке спецификации шифров. Ну и равно печально, что люди не понимают, что включать ssl_prefer_server_ciphers в отсутствии серьёзных проблем, которые нужно решать на стороне сервера - не стоит. -- Maxim Dounin http://mdounin.ru/ From chipitsine на gmail.com Thu Sep 20 13:50:49 2018 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 20 Sep 2018 18:50:49 +0500 Subject: OCSP stapling in Nginx >=1.3.7 In-Reply-To: <20180920130146.GE56558@mdounin.ru> References: <20180912143606.GQ56558@mdounin.ru> <16a36038-8ad8-27b2-5417-f16354a9cfe9@csdoc.com> <20180916233654.GD56558@mdounin.ru> <8ee9b91c-606b-26e9-9ecb-16c49583ab8b@csdoc.com> <20180918170331.GR56558@mdounin.ru> <84aaaf54-f440-48ce-345c-2997afe7ec83@csdoc.com> <20180919185608.GZ56558@mdounin.ru> <20180920000636.GC56558@mdounin.ru> <7c65d09e-4b49-a0f7-f58e-6cd4f443450e@csdoc.com> <20180920130146.GE56558@mdounin.ru> Message-ID: чт, 20 сент. 2018 г. в 18:01, Maxim Dounin : > Hello! > > On Thu, Sep 20, 2018 at 05:40:16AM +0300, Gena Makhomed wrote: > > > On 20.09.2018 3:06, Maxim Dounin wrote: > > > > >> Правильной была бы цель "сделать обязательной проверку отзыва" > > >> без каких-либо дополнительных условий? > > > > > Именно так. Потому что мешать в одну кучу требование о проверке > > > отзыва сертфиката и технические аспекты одного из вариантов этой > > > проверки - это плохой путь. > > > > >> Правильным решением в таком случае был бы флаг в сертификате > > >> "обязательно проверять отзыв сертификата", так что если веб-сервер > > >> прислал OCSP-ответ прикрепленный к сертификату сервером, браузер > > >> использует его, а если веб-сервер ничего не прислал, тогда браузер > > >> должен сам в обязательном порядке сделать OCSP-запрос и получить > ответ? > > >> И только если браузер не смог получить OCSP-ответ, только в этом > случае > > >> запрещать клиенту доступ к сайту с таким флагом в сертификате? > > > > > И это было бы логично: именно так сейчас браузеры, использующие > > > OCSP, и работают, с той лишь разницей, что по результатам > > > неудачной проверки доступ - не запрещают. > > > > Может быть еще не поздно предложить RFC в котором будет > > описан такой флаг "сделать обязательной проверку отзыва" ? > > Лично я - далёк от того, чтобы заниматься вопросами стандартизации > чего бы то ни было. Возможно, "must staple" сам рано или поздно > мигрирует в такое поведение. > > > >> Такое решение задачи наверное было бы наиболее удобным для создателей > > >> веб-серверов, но значительно увеличило бы нагрузку на инфраструктуру > CA, > > > > > Не увеличило бы. Потому что по факту - OCSP сейчас и так включён > > > по умолчанию во всех браузерах, его использующих. > > > > Если не увеличило бы, почему же тогда представители CA были против? > > ЕМНИП, на тот момент проверка отзыва был в большинстве браузеров > по умолчанию выключена. > > > >>> В тот момент, когда от клиента пришло соединение с запросом > > >>> certificate status и OpenSSL'ем был вызван соответствующий > > >>> callback - у nginx'а нет возможности как-либо отложить обработку > > >>> этого соединения. > > >>> > > >>> Соответственно либо к этому моменту у nginx'а уже есть > > >>> соответствующий OCSP-ответ - и тогда он может его отправить > > >>> клиенту, либо соответствующего OCSP-ответа нет - и тогда он не > > >>> может его отправить, а максимум что может - это инициировать > > >>> запрос к OCSP-серверу, чтобы этот ответ получить для последующих > > >>> клиентов. > > > > >> У nginx есть отдельный процесс cache manager, который управляет кэшем > > >> независимо от рабочих процессов nginx, может быть имеет смысл также > > >> сделать ocsp cache manager, который будет заниматься получением > > >> и кэшированием OCSP-ответов для всех присутствующих сертификатов? > > > > > Можно сделать много всего. Но это не избавляет от ситуации, когда > > > соединение, в котором надо вернуть OCSP-ответ, уже есть, а самого > > > OCSP-ответа - ещё нет. > > > > Избавляет полностью, если OCSP responder отвечает на запросы. > > > > Когда в конфиг добавили новый сертификат и сделали reload - > > сначала ocsp cache manager убеждается, что у него есть актуальные > > OCSP-ответы для всех "Must Staple" сертификатов и только после этого > > применяется новая конфигурация для всех рабочих процессов nginx'а. > > > > Когда в конфиг добавили новый сертификат и запустили nginx - > > сначала запускается ocsp cache manager, убеждается, что у него есть > > актуальные OCSP-ответы для всех "Must Staple" сертификатов и только > > после этого запускаются рабочие процессы nginx'а. > > > > Когда в процессе работы nginx'а OCSP responder не доступен более > > чем 50% времени жизни OCSP-ответа - это форс-мажорная ситуация > > и в таком случае nginx просто закрывает соединение с клиентом > > для всех соединений с "Must Staple" сертификатами до тех пор, > > пока актуальный OCSP-ответ не будет получен. Это лучше, чем > > возвращать клиенту "Must Staple" сертификат без OCSP-ответа. > > О чём и речь. Во всей этой конструкции - описано множество вещей, > которые надо программировать, чтобы "must staple" хоть как-то > заработал. И вещей, которые надо делать на старте nginx'а - > просто для того, чтобы начать работать. И при этом нет сколь-либо > разумного решения для ситуации, когда OCSP responder по каким-то > причинам оказывается недоступен. > > Закрывать соединения - это плохой, негодный подход. Очень > напоминает подход "ошибка аллокации памяти - это форс-мажорная > ситуация, в таком случае надо делать abort(), это лучше, чем > продолжать работать". > > При этом всего этого можно было бы легко избежать, не пытаясь > вводить "must staple" вместо требования проверки отзыва. > > > >>> Эту проблему можно столь же успешно решить, просто не пытаясь > > >>> включать "ssl_prefer_server_ciphers". Попытки же изобретать > > >>> сложную логику - "здесь играем, здесь не играем, здесь рыбу > > >>> заворачивали" - выглядят, скажем мягко, странно. > > > > >> Эта сложная логика уже изобретена и встроена в OpenSSL, > > >> достаточно только указать флаг SSL_OP_PRIORITIZE_CHACHA. > > >> > > >> Получается очень красивое решение, так что и Forward Secrecy > > >> можно получить с большинством браузеров и мобильные клиенты > > >> будут использовать наиболее эффективный для них шифр ChaCha20. > > > > > Это что угодно, но только не красивое решение. Люди потратили > > > массу сил и времени на изобретение сложной логики (и теперь хотят, > > > чтобы разработчики nginx'а и все пользователи nginx'а - > > > присоединились к процессу, потому что встроить эту логику в > > > существующий механизм выбора приоритета шифров - не осилили). > > > И всё ради того, чтобы насильно обеспечить Forward Secrecy людям, > > > сознательно забившим на обновление софта. > > > > Не только. Директива ssl_prefer_server_ciphers применяется > > и в тех случаях, когда в каком-то шифре находят уязвимость, > > тогда этот шифр с помощью серверных приоритетов ставится > > на последнее место. Совсем выключить нельзя, потому что > > некоторые клиенты не умеют ничего другого кроме этого шифра. > > Такое уже было, например, когда нашли уязвимость в RC4. > > Или когда до того, наоборот, ставили RC4 на первое место, > > чтобы защититься от уязвимости в браузерах по имени BEAST. > > Случаи с RC4, на самом деле, хороший пример, почему подобноё > управление шифрами - как раз требует чёткого понимания автором > конфигурации целей и задач, и требует регулярного пересмотра. > есть "конфликт" интересов безопасников и клиентов. безопасники любят открывать SSL Labs и тыкать пальцем во все, что не зеленое. ок ... что это тут у нас ... SSL3 .... отключить. потом прибегают клиенты, у которых 1С версии 8, в которой в определенных билдах только SSL3 и никак иначе и это без конца. при то, что на самом деле наличие SSL3 не является проблемой от слова "совсем" ну хочешь - соединяйся по TLS 1.2, кто-то тебя насильно тащит на SSL3 чтоли. периодически возникает мысль, что неплохо бы иметь аналог ngx_stream_ssl_preread_module для https, который позволял бы на основании SSL Client Helo отвечать тем способом, каким хотят увидеть ответ безопасники (ну или chacha пихнуть, если видим, что пришел андроид) > > Потому что RC4 в nginx'е - по умолчанию запрещён начиная с nginx > 0.8.20, выпущенного в 2009 году. И соответственно сначала все его > подобавляли для борьбы с BEAST - а потом выпиливали из > конфигураций обратно, когда стало понятно, что RC4 даже хуже, чем > считалось до этого. При том, что сколько-нибудь реальной исходная > проблема с BEAST была - разве что несколько недель после анонса, > пока браузеры не выкатили свой аналог OpenSSL'ного "insert empty > fragments". > > > В такой ситуации все пользователи nginx'а будут поставлены > > перед выбором: или защитить клиентов от уязвимости в шифре > > но при этом быстро съедать батарею у мобильных пользователей > > или экономить батарею у мобильных пользователей но иметь > > включенным и выбираемым частью клиентов уязвимый шифр. > > > > Если бы была возможность включить SSL_OP_PRIORITIZE_CHACHA > > через директиву конфигурации nginx - это бы упростило жизнь, > > тогда можно и уязвимый шифр выключить и батарею экономить. > > Я не спорю с тем, что соответствующая возможность - может > оказаться полезной в каких-то ситуациях. > > Мне тут в первую очередь печально, что со стороны OpenSSL > получилось очередной ad-hoc решение, требующее отдельной ручки - > вместо, например, групп шифров с одинаковым приоритетом в строке > спецификации шифров. > > Ну и равно печально, что люди не понимают, что включать > ssl_prefer_server_ciphers в отсутствии серьёзных проблем, которые > нужно решать на стороне сервера - не стоит. > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From gmm на csdoc.com Thu Sep 20 17:55:30 2018 From: gmm на csdoc.com (Gena Makhomed) Date: Thu, 20 Sep 2018 20:55:30 +0300 Subject: OCSP stapling in Nginx >=1.3.7 In-Reply-To: <20180920130146.GE56558@mdounin.ru> References: <20180912143606.GQ56558@mdounin.ru> <16a36038-8ad8-27b2-5417-f16354a9cfe9@csdoc.com> <20180916233654.GD56558@mdounin.ru> <8ee9b91c-606b-26e9-9ecb-16c49583ab8b@csdoc.com> <20180918170331.GR56558@mdounin.ru> <84aaaf54-f440-48ce-345c-2997afe7ec83@csdoc.com> <20180919185608.GZ56558@mdounin.ru> <20180920000636.GC56558@mdounin.ru> <7c65d09e-4b49-a0f7-f58e-6cd4f443450e@csdoc.com> <20180920130146.GE56558@mdounin.ru> Message-ID: <06618b54-f26e-5d3e-b718-71e9b6e2acc7@csdoc.com> On 20.09.2018 16:01, Maxim Dounin wrote: >>>> У nginx есть отдельный процесс cache manager, который управляет кэшем >>>> независимо от рабочих процессов nginx, может быть имеет смысл также >>>> сделать ocsp cache manager, который будет заниматься получением >>>> и кэшированием OCSP-ответов для всех присутствующих сертификатов? >>> Можно сделать много всего. Но это не избавляет от ситуации, когда >>> соединение, в котором надо вернуть OCSP-ответ, уже есть, а самого >>> OCSP-ответа - ещё нет. >> Избавляет полностью, если OCSP responder отвечает на запросы. >> >> Когда в конфиг добавили новый сертификат и сделали reload - >> сначала ocsp cache manager убеждается, что у него есть актуальные >> OCSP-ответы для всех "Must Staple" сертификатов и только после этого >> применяется новая конфигурация для всех рабочих процессов nginx'а. >> >> Когда в конфиг добавили новый сертификат и запустили nginx - >> сначала запускается ocsp cache manager, убеждается, что у него есть >> актуальные OCSP-ответы для всех "Must Staple" сертификатов и только >> после этого запускаются рабочие процессы nginx'а. >> >> Когда в процессе работы nginx'а OCSP responder не доступен более >> чем 50% времени жизни OCSP-ответа - это форс-мажорная ситуация >> и в таком случае nginx просто закрывает соединение с клиентом >> для всех соединений с "Must Staple" сертификатами до тех пор, >> пока актуальный OCSP-ответ не будет получен. Это лучше, чем >> возвращать клиенту "Must Staple" сертификат без OCSP-ответа. > О чём и речь. Во всей этой конструкции - описано множество вещей, > которые надо программировать, чтобы "must staple" хоть как-то > заработал. И вещей, которые надо делать на старте nginx'а - > просто для того, чтобы начать работать. И при этом нет сколь-либо > разумного решения для ситуации, когда OCSP responder по каким-то > причинам оказывается недоступен. Срок жизни OCSP-ответов - самое меньшее что я видел, это 36 часов, самое большее - это 7 суток. Предлагается не ждать полного истечения срока жизни OCSP-ответа, а получать новый OCSP-ответ, когда прошло уже 50% времени жизни текущего OCSP-ответа. Так что для получения нового OCSP-ответа будет от 18 часов до 3.5 суток, это ведь много. При старте nginx'а - в 99.999% случаев все необходимые OCSP-ответы будут прочитаны ocsp cache manager из файловой системы, из кэша. Так что задержка при старте nginx будет практически нулевой. > Закрывать соединения - это плохой, негодный подход. Тогда у nginx остается всего один вариант - отправлять клиенту сертификат без OCSP-ответа. Но если OCSP responder работает нормально и оказался не доступен на небольшой промежуток времени, например, всего на несколько часов - такой проблемы не будет. > При этом всего этого можно было бы легко избежать, не пытаясь > вводить "must staple" вместо требования проверки отзыва. Автор RFC 7633 - представитель CA, ему далеки проблемы веб-серверов. >>>> Эта сложная логика уже изобретена и встроена в OpenSSL, >>>> достаточно только указать флаг SSL_OP_PRIORITIZE_CHACHA. >>>> Получается очень красивое решение, так что и Forward Secrecy >>>> можно получить с большинством браузеров и мобильные клиенты >>>> будут использовать наиболее эффективный для них шифр ChaCha20. >>> Это что угодно, но только не красивое решение. Люди потратили >>> массу сил и времени на изобретение сложной логики (и теперь хотят, >>> чтобы разработчики nginx'а и все пользователи nginx'а - >>> присоединились к процессу, потому что встроить эту логику в >>> существующий механизм выбора приоритета шифров - не осилили). Директива для включения SSL_OP_PRIORITIZE_CHACHA никому бы не помешала. Кто не хочет участвовать в процессе - просто не трогают ее и оставляют по-дефолту выключенной, а кто хочет участвовать - включает и радуется. >> В такой ситуации все пользователи nginx'а будут поставлены >> перед выбором: или защитить клиентов от уязвимости в шифре >> но при этом быстро съедать батарею у мобильных пользователей >> или экономить батарею у мобильных пользователей но иметь >> включенным и выбираемым частью клиентов уязвимый шифр. >> Если бы была возможность включить SSL_OP_PRIORITIZE_CHACHA >> через директиву конфигурации nginx - это бы упростило жизнь, >> тогда можно и уязвимый шифр выключить и батарею экономить. > Я не спорю с тем, что соответствующая возможность - может > оказаться полезной в каких-то ситуациях. > Мне тут в первую очередь печально, что со стороны OpenSSL > получилось очередной ad-hoc решение, требующее отдельной ручки - > вместо, например, групп шифров с одинаковым приоритетом в строке > спецификации шифров. А как в nginx в строке спецификации шифров ssl_ciphers можно задать группу шифров с одинаковым приоритетом? > Ну и равно печально, что люди не понимают, что включать > ssl_prefer_server_ciphers в отсутствии серьёзных проблем, > которые нужно решать на стороне сервера - не стоит. Включать ssl_prefer_server_ciphers - такое решение рекомендует всем людям и https://www.ssllabs.com/ssltest/ и Mozilla в своем https://mozilla.github.io/server-side-tls/ssl-config-generator/ и много кто и где еще. -- Best regards, Gena From mdounin на mdounin.ru Thu Sep 20 23:46:20 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 21 Sep 2018 02:46:20 +0300 Subject: OCSP stapling in Nginx >=1.3.7 In-Reply-To: <06618b54-f26e-5d3e-b718-71e9b6e2acc7@csdoc.com> References: <20180916233654.GD56558@mdounin.ru> <8ee9b91c-606b-26e9-9ecb-16c49583ab8b@csdoc.com> <20180918170331.GR56558@mdounin.ru> <84aaaf54-f440-48ce-345c-2997afe7ec83@csdoc.com> <20180919185608.GZ56558@mdounin.ru> <20180920000636.GC56558@mdounin.ru> <7c65d09e-4b49-a0f7-f58e-6cd4f443450e@csdoc.com> <20180920130146.GE56558@mdounin.ru> <06618b54-f26e-5d3e-b718-71e9b6e2acc7@csdoc.com> Message-ID: <20180920234620.GH56558@mdounin.ru> Hello! On Thu, Sep 20, 2018 at 08:55:30PM +0300, Gena Makhomed wrote: [...] > Но если OCSP responder работает нормально и оказался не доступен > на небольшой промежуток времени, например, всего на несколько > часов - такой проблемы не будет. Такая проблема совершенно точно будет - даже при идеальном кэшировании доступных OCSP-ответов. В частности, даже в этом треде уже есть пример с зафильтрованным OCSP responder'ом. Отрицать проблему - глупо. И хороших решений в рамках парадигмы "must staple" - не существует. [...] > >>> Это что угодно, но только не красивое решение. Люди потратили > >>> массу сил и времени на изобретение сложной логики (и теперь хотят, > >>> чтобы разработчики nginx'а и все пользователи nginx'а - > >>> присоединились к процессу, потому что встроить эту логику в > >>> существующий механизм выбора приоритета шифров - не осилили). > > Директива для включения SSL_OP_PRIORITIZE_CHACHA никому бы не помешала. > Кто не хочет участвовать в процессе - просто не трогают ее и оставляют > по-дефолту выключенной, а кто хочет участвовать - включает и радуется. Это очень распространённое заблуждение, будто бы наличие ненужной директивы - никому не мешает. На самом деле - любая существующая директива жрёт ресурсы как разработчиков, вынужденных заниматься её поддержкой, так и всех пользователей, так или иначе натыкающихся на неё в документации и конфигах, и вынужденных знать, что эта директива делает. [...] > > Мне тут в первую очередь печально, что со стороны OpenSSL > > получилось очередной ad-hoc решение, требующее отдельной ручки - > > вместо, например, групп шифров с одинаковым приоритетом в строке > > спецификации шифров. > > А как в nginx в строке спецификации шифров ssl_ciphers > можно задать группу шифров с одинаковым приоритетом? Строка шифров интерперетируется OpenSSL'ем. Пока не напрограммируют - никак. > > Ну и равно печально, что люди не понимают, что включать > > ssl_prefer_server_ciphers в отсутствии серьёзных проблем, > > которые нужно решать на стороне сервера - не стоит. > > Включать ssl_prefer_server_ciphers - такое решение рекомендует > всем людям и https://www.ssllabs.com/ssltest/ и Mozilla в своем > https://mozilla.github.io/server-side-tls/ssl-config-generator/ > и много кто и где еще. Это печально. (c) -- Maxim Dounin http://mdounin.ru/ From vbart на nginx.com Fri Sep 21 16:13:18 2018 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Fri, 21 Sep 2018 19:13:18 +0300 Subject: =?UTF-8?B?0KDQtdC70LjQtyBVbml0IDEuNA==?= Message-ID: <1678301.viDcXLzA2u@vbart-workstation> Здравствуйте. Рад сообщить о выпуске новой версии NGINX Unit. Ключевая особенность новой версии — динамически настраиваемая поддержка TLS и API хранилища сертификатов, который позволяет извлекать подробные сведения о цепочках сертификатов, включая имена и сроки действия. Подробности в нашей документации: - https://unit.nginx.org/configuration/#ssl-tls-and-certificates Это лишь первый шаг на пути к реализации TLS. В будущем мы добавим дополнительные возможности конфигурации и расширим функциональность, связанную с TLS. Мы также планируем обеспечить полноценную поддержку HTTP/2. Изменения в Unit 1.4 20.09.2018 *) Изменение: API управления теперь предоставляет доступ к объекту конфигурации только по "/config/". *) Добавление: появилась поддержка TLS для клиентских соединений. *) Добавление: API управления теперь поддерживает хранилище сертификатов TLS. *) Добавление: добавлена библиотека Unit (libunit), упрощающая интеграцию новых языковых модулей. *) Добавление: при закрытии постоянных HTTP-соединений отправляются ответы "408 Request Timeout". *) Добавление: улучшена поддержка OpenBSD. Спасибо Дэвиду Карлье (David Carlier). *) Исправление: после переконфигурации могла происходить ошибка сегментации. *) Исправление: могла нарушаться сборка на системах, где локаль отличается от локали по умолчанию. *) Исправление: параметр "header_read_timeout" мог работать неправильно. *) Исправление: модуль Python 3 мог неправильно обрабатывать значения полей заголовков с байтами не из ASCII. Через несколько недель мы собираемся добавить предварительную версию поддержки Node.js. Она почти готова; наши QA-инженеры уже ее тестируют. Сейчас мы также работаем над модулем Java, поддержкой WebSockets, гибкой маршрутизацией запросов и выдачей статического контента. Прошу также приветствовать Артема Конева, который присоединился к нам в роли технического писателя. Он уже начал улучшать документацию на сайте и обновил описание параметров конфигурации до текущего состояния: - https://hg.nginx.org/unit-docs/ Конечно, над сайтом еще нужно поработать, так что Артему предстоит постараться, чтобы документация Unit приобрела достойный вид. Вы можете смело присоединяться к работе над ней; свои идеи, предложения и правки оформляйте в pull-запросах и вопросах на GitHub: - https://github.com/nginx/unit-docs/ Оставайтесь с нами! -- Валентин Бартенев From gmm на csdoc.com Fri Sep 21 16:40:12 2018 From: gmm на csdoc.com (Gena Makhomed) Date: Fri, 21 Sep 2018 19:40:12 +0300 Subject: OCSP stapling in Nginx >=1.3.7 In-Reply-To: <20180920234620.GH56558@mdounin.ru> References: <20180916233654.GD56558@mdounin.ru> <8ee9b91c-606b-26e9-9ecb-16c49583ab8b@csdoc.com> <20180918170331.GR56558@mdounin.ru> <84aaaf54-f440-48ce-345c-2997afe7ec83@csdoc.com> <20180919185608.GZ56558@mdounin.ru> <20180920000636.GC56558@mdounin.ru> <7c65d09e-4b49-a0f7-f58e-6cd4f443450e@csdoc.com> <20180920130146.GE56558@mdounin.ru> <06618b54-f26e-5d3e-b718-71e9b6e2acc7@csdoc.com> <20180920234620.GH56558@mdounin.ru> Message-ID: <74683829-f359-29d7-6b02-f1f9f29b1a80@csdoc.com> On 21.09.2018 2:46, Maxim Dounin wrote: >> Но если OCSP responder работает нормально и оказался не доступен >> на небольшой промежуток времени, например, всего на несколько >> часов - такой проблемы не будет. > Такая проблема совершенно точно будет - даже при идеальном > кэшировании доступных OCSP-ответов. В частности, даже в этом > треде уже есть пример с зафильтрованным OCSP responder'ом. Если OCSP responder не работает или по какой-то другой причине не доступен веб-серверу длительное время - тогда да, проблема будет. Но если веб-сервер может получать валидные ответы от OCSP responder'а и реализовано идеальное кеширование ответов - проблем быть не должно. > Отрицать проблему - глупо. > И хороших решений в рамках парадигмы "must staple" - не существует. При недоступном/неработающем responder'е проблема будет в любом случае. Даже если вместо флага Must Staple будет флаг "всегда проверять отзыв". В этом случае и веб-сервер не сможет прикрепить OCSP-ответ и браузер не сможет получить ответ от недоступного/неработающего responder'а. В результате - точно так же можно сказать в ответ, что хороших решений в рамках парадигмы "всегда проверять отзыв сертификата" - не существует. Я не спорю с тем, что флаг "всегда проверять отзыв" был бы гораздо лучше, чем имеющийся сейчас в наличии флаг "must staple" и RFC к нему. Поменять флаг "must staple" на флаг "всегда проверять отзыв" мы уже никак не можем, флаг "must staple" уже используется СА и браузерами. Но вот сделать кэширование OCSP-ответов идеальным - это вполне возможно, так чтобы проблемы с Must Staple сертификатами из-за nginx уже не будет. -- Best regards, Gena From nginx-forum на forum.nginx.org Fri Sep 21 20:15:02 2018 From: nginx-forum на forum.nginx.org (S.A.N) Date: Fri, 21 Sep 2018 16:15:02 -0400 Subject: =?UTF-8?B?UmU6INCg0LXQu9C40LcgVW5pdCAxLjQ=?= In-Reply-To: <1678301.viDcXLzA2u@vbart-workstation> References: <1678301.viDcXLzA2u@vbart-workstation> Message-ID: <9802df3ce2506aa0076f590cf4530015.NginxMailingListRussian@forum.nginx.org> > поддержкой WebSockets, гибкой маршрутизацией запросов и выдачей статического контента. Этого действительно не хватает в Unit. НТТР кеширования, как в Nginx, тоже уже в разработке? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,281345,281350#msg-281350 From vbart на nginx.com Sat Sep 22 10:14:53 2018 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Sat, 22 Sep 2018 13:14:53 +0300 Subject: =?UTF-8?B?UmU6INCg0LXQu9C40LcgVW5pdCAxLjQ=?= In-Reply-To: <9802df3ce2506aa0076f590cf4530015.NginxMailingListRussian@forum.nginx.org> References: <1678301.viDcXLzA2u@vbart-workstation> <9802df3ce2506aa0076f590cf4530015.NginxMailingListRussian@forum.nginx.org> Message-ID: <26512672.XsSR9ail0K@vbart-laptop> On Friday, 21 September 2018 23:15:02 MSK S.A.N wrote: > > поддержкой WebSockets, гибкой > маршрутизацией запросов и выдачей статического контента. > > Этого действительно не хватает в Unit. > НТТР кеширования, как в Nginx, тоже уже в разработке? > [..] Пока в самых ближайших планах нет. Для кеширования в настоящий момент рекомендую использовать NGINX Plus. Я заметил, что вы много всего просите, а могли бы стать нашим крупнейшим клиентом и тем самым влиять на ход разработки тех или иных возможностей, как в nginx, так и в Unit. Разработка обходится совсем не бесплатно и потому получают приоритет в первую очередь те вещи, которые позволяют продолжать совершенствовать наши продукты, в том числе open-source. -- Валентин Бартенев From nginx-forum на forum.nginx.org Sat Sep 22 11:12:45 2018 From: nginx-forum на forum.nginx.org (S.A.N) Date: Sat, 22 Sep 2018 07:12:45 -0400 Subject: =?UTF-8?B?UmU6INCg0LXQu9C40LcgVW5pdCAxLjQ=?= In-Reply-To: <26512672.XsSR9ail0K@vbart-laptop> References: <26512672.XsSR9ail0K@vbart-laptop> Message-ID: <06d9ae6fe1fe8f450cf1931ee75765ad.NginxMailingListRussian@forum.nginx.org> > Я заметил, что вы много всего просите, а могли бы стать нашим > крупнейшим > клиентом и тем самым влиять на ход разработки тех или иных > возможностей, > как в nginx, так и в Unit. Разработка обходится совсем не бесплатно и > потому получают приоритет в первую очередь те вещи, которые позволяют > продолжать совершенствовать наши продукты, в том числе open-source. К сожалению, финансовые вопросы я не решаю, но во всех наших проектах я всегда лобирую ваши техн продукты, скажу честно ваши платные продукты мне сложней лобировать. Но я согласен, что бизнес должен делится прибылью с разработчиками бесплатного софта. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,281345,281359#msg-281359 From fe на hamilton.rinet.ru Tue Sep 25 09:48:42 2018 From: fe на hamilton.rinet.ru (Fedor Dikarev) Date: Tue, 25 Sep 2018 12:48:42 +0300 Subject: =?UTF-8?B?VmFyaWFibGVzINCyIGFkZF9hZnRlcl9ib2R5INC40LvQuCDQv9C10YDQtdC00LA=?= =?UTF-8?B?0YfQsCDQv9Cw0YDQsNC80LXRgtGA0L7QsiDQsiBuanMgc3VicmVxdWVzdA==?= Message-ID: Привет! Продолжаю свой вопрос про построение динамического бинарника и использование для этого add_afer_body и njs > http://mailman.nginx.org/pipermail/nginx-ru/2018-September/061454.html > http://mailman.nginx.org/pipermail/nginx-ru/2018-September/061461.html В итоге сейчас собрали такую конструкцию: > location ~ /new4game-qa/web-installer/(.*).exe { > add_after_body /exe_payload/$is_args$args; > alias /files/new4game-qa/web-installer/4game-setup.exe > } > location /exe_payload { > internal; > # rewrite ^/exe_payload/ /exe_payload/2/$gameKey/$gamekey/$arg_gameKey/$arg_gamekey/ break; > proxy_set_header X-GameKey "2/$gameKey/$arg_gameKey"; > set $gameKey $arg_gameKey; > js_content exe_payload; > } (как видим тут я пробую разные варианты передать $arg_gameKey в обработчик и все безуспешно) меня тут даже спасет если в njs будет передаваться оригинальный url запроса, но этого я тоже не смог добиться :( И сама функция: > function exe_payload(r) { > ... > var config = { > "gameKey": r.variables['gameKey'], > "r.vars": r.variables, > "r.uri": r.uri, > "r.headers": r.headersIn, > "r.key": r.headersIn["X-GameKey"] > }; > var configStr = JSON.stringify(config); И на выходе получаю: > 0079d9c0 61 6d 65 4b 65 79 22 3a 22 22 2c 22 72 2e 76 61 |ameKey":"","r.va| > 0079d9d0 72 73 22 3a 6e 75 6c 6c 2c 22 72 2e 75 72 69 22 |rs":null,"r.uri"| > 0079d9e0 3a 22 2f 65 78 65 5f 70 61 79 6c 6f 61 64 2f 24 |:"/exe_payload/$| > 0079d9f0 69 73 5f 61 72 67 73 24 61 72 67 73 22 2c 22 72 |is_args$args","r| > 0079da00 2e 68 65 61 64 65 72 73 22 3a 6e 75 6c 6c 2c 22 |.headers":null,"| Собственно можно как-то раскрывать variables в location add_after_body? Ну или может есть какой-то более правильный способ передать параметр в njs функцию вызываемую внутри этого subrequest-а? -- Fedor Dikarev From mdounin на mdounin.ru Tue Sep 25 15:25:28 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 25 Sep 2018 18:25:28 +0300 Subject: nginx-1.15.4 Message-ID: <20180925152528.GH56558@mdounin.ru> Изменения в nginx 1.15.4 25.09.2018 *) Добавление: теперь директиву ssl_early_data можно использовать с OpenSSL. *) Исправление: в модуле ngx_http_uwsgi_module. Спасибо Chris Caputo. *) Исправление: соединения к некоторым gRPC-бэкендам могли не кэшироваться при использовании директивы keepalive. *) Исправление: при использовании директивы error_page для перенаправления ошибок, возникающих на ранних этапах обработки запроса, в частности ошибок с кодом 400, могла происходить утечка сокетов. *) Исправление: директива return при возврате ошибок не изменяла код ответа, если запрос был перенаправлен с помощью директивы error_page. *) Исправление: стандартные сообщения об ошибках и ответы модуля ngx_http_autoindex_module содержали атрибут bgcolor, что могло приводить к их некорректному отображению при использовании пользовательских настроек цветов в браузерах. Спасибо Nova DasSarma. *) Изменение: уровень логгирования ошибок SSL "no suitable key share" и "no suitable signature algorithm" понижен с уровня crit до info. -- Maxim Dounin http://nginx.org/ From nginx-forum на forum.nginx.org Fri Sep 28 13:04:50 2018 From: nginx-forum на forum.nginx.org (vadv) Date: Fri, 28 Sep 2018 09:04:50 -0400 Subject: =?UTF-8?B?bmdpbnggbG9uZy1wb2xsaW5nLCDQvNGD0LvRjNGC0LjQv9C70LXQutGB0LjRgNC+?= =?UTF-8?B?0LLQsNC90LjQtSDRgdC+0LXQtNC40L3QtdC90LjQuSDQsiB1cHN0cmVhbQ==?= Message-ID: Здравствуйте, All! Есть http1 клиенты, которые подключены по long-polling, сейчас это реализовано на nginx-push-stream-module. В силу разных причин, появилась необходимость вынести функционал long-polling из nginx, чтобы nginx проксировал соединения в некий upstream. Но при этом не хочется умножать x2 кол-во соединений, который делает nginx (1 коннект от клиента, 1 коннект в upstream). Как, не переписывая клиентов, можно замультиплексировать "клиентские" соединения в upstream уменьшив их кол-во? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,281436,281436#msg-281436 From kpoxa на kpoxa.net Fri Sep 28 13:53:11 2018 From: kpoxa на kpoxa.net (kpoxa) Date: Fri, 28 Sep 2018 16:53:11 +0300 Subject: =?UTF-8?B?UmU6IG5naW54IGxvbmctcG9sbGluZywg0LzRg9C70YzRgtC40L/Qu9C10LrRgdC4?= =?UTF-8?B?0YDQvtCy0LDQvdC40LUg0YHQvtC10LTQuNC90LXQvdC40Lkg0LIgdXBzdHJl?= =?UTF-8?B?YW0=?= In-Reply-To: References: Message-ID: Добрый день. Сделайте эти соединения на отдельный ip:port пт, 28 сент. 2018 г. в 16:04, vadv : > > Здравствуйте, All! > > Есть http1 клиенты, которые подключены по long-polling, сейчас это > реализовано на nginx-push-stream-module. > В силу разных причин, появилась необходимость вынести функционал > long-polling из nginx, чтобы nginx проксировал соединения в некий upstream. > Но при этом не хочется умножать x2 кол-во соединений, который делает nginx > (1 коннект от клиента, 1 коннект в upstream). > > Как, не переписывая клиентов, можно замультиплексировать "клиентские" > соединения в upstream уменьшив их кол-во? > > Posted at Nginx Forum: https://forum.nginx.org/read.php?21,281436,281436#msg-281436 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From nginx-forum на forum.nginx.org Fri Sep 28 13:57:49 2018 From: nginx-forum на forum.nginx.org (vadv) Date: Fri, 28 Sep 2018 09:57:49 -0400 Subject: =?UTF-8?B?UmU6IG5naW54IGxvbmctcG9sbGluZywg0LzRg9C70YzRgtC40L/Qu9C10LrRgdC4?= =?UTF-8?B?0YDQvtCy0LDQvdC40LUg0YHQvtC10LTQuNC90LXQvdC40Lkg0LIgdXBzdHJl?= =?UTF-8?B?YW0=?= In-Reply-To: References: Message-ID: <7dd0b8e422261e3bbfc9d6ad18d6be68.NginxMailingListRussian@forum.nginx.org> ну то есть предлагаете развесить upstream на несколько портов, чем это поможет? если клиентов 600k, то получится 1.2ml tcp-сокетов Posted at Nginx Forum: https://forum.nginx.org/read.php?21,281436,281438#msg-281438 From chipitsine на gmail.com Fri Sep 28 13:58:11 2018 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Fri, 28 Sep 2018 18:58:11 +0500 Subject: =?UTF-8?B?UmU6IG5naW54IGxvbmctcG9sbGluZywg0LzRg9C70YzRgtC40L/Qu9C10LrRgdC4?= =?UTF-8?B?0YDQvtCy0LDQvdC40LUg0YHQvtC10LTQuNC90LXQvdC40Lkg0LIgdXBzdHJl?= =?UTF-8?B?YW0=?= In-Reply-To: References: Message-ID: Битрикс? On Fri, Sep 28, 2018, 6:05 PM vadv wrote: > Здравствуйте, All! > > Есть http1 клиенты, которые подключены по long-polling, сейчас это > реализовано на nginx-push-stream-module. > В силу разных причин, появилась необходимость вынести функционал > long-polling из nginx, чтобы nginx проксировал соединения в некий upstream. > Но при этом не хочется умножать x2 кол-во соединений, который делает nginx > (1 коннект от клиента, 1 коннект в upstream). > > Как, не переписывая клиентов, можно замультиплексировать "клиентские" > соединения в upstream уменьшив их кол-во? > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,281436,281436#msg-281436 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Fri Sep 28 14:39:33 2018 From: nginx-forum на forum.nginx.org (vadv) Date: Fri, 28 Sep 2018 10:39:33 -0400 Subject: =?UTF-8?B?UmU6IG5naW54IGxvbmctcG9sbGluZywg0LzRg9C70YzRgtC40L/Qu9C10LrRgdC4?= =?UTF-8?B?0YDQvtCy0LDQvdC40LUg0YHQvtC10LTQuNC90LXQvdC40Lkg0LIgdXBzdHJl?= =?UTF-8?B?YW0=?= In-Reply-To: References: Message-ID: <8fd90779d92fef466263b60296dc4372.NginxMailingListRussian@forum.nginx.org> нет, а можно посмотреть какие есть решения для битрикса? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,281436,281440#msg-281440 From chipitsine на gmail.com Fri Sep 28 15:06:35 2018 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Fri, 28 Sep 2018 20:06:35 +0500 Subject: =?UTF-8?B?UmU6IG5naW54IGxvbmctcG9sbGluZywg0LzRg9C70YzRgtC40L/Qu9C10LrRgdC4?= =?UTF-8?B?0YDQvtCy0LDQvdC40LUg0YHQvtC10LTQuNC90LXQvdC40Lkg0LIgdXBzdHJl?= =?UTF-8?B?YW0=?= In-Reply-To: <8fd90779d92fef466263b60296dc4372.NginxMailingListRussian@forum.nginx.org> References: <8fd90779d92fef466263b60296dc4372.NginxMailingListRussian@forum.nginx.org> Message-ID: Обычно используется сокет+поллинг (signalr, socket.io), у битрикса свои подходы, на том решении, про которое вы говорите. Оно неудобное. Было бы интересно услышать, как это готовить On Fri, Sep 28, 2018, 7:39 PM vadv wrote: > нет, > а можно посмотреть какие есть решения для битрикса? > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,281436,281440#msg-281440 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Fri Sep 28 15:11:43 2018 From: nginx-forum на forum.nginx.org (vadv) Date: Fri, 28 Sep 2018 11:11:43 -0400 Subject: =?UTF-8?B?UmU6IG5naW54IGxvbmctcG9sbGluZywg0LzRg9C70YzRgtC40L/Qu9C10LrRgdC4?= =?UTF-8?B?0YDQvtCy0LDQvdC40LUg0YHQvtC10LTQuNC90LXQvdC40Lkg0LIgdXBzdHJl?= =?UTF-8?B?YW0=?= In-Reply-To: References: Message-ID: <48ee1cbf78e90bdf78b63294e70f184f.NginxMailingListRussian@forum.nginx.org> Такая фича есть у envoyproxy: https://www.envoyproxy.io/docs/envoy/latest/configuration/http_filters/grpc_http1_bridge_filter Posted at Nginx Forum: https://forum.nginx.org/read.php?21,281436,281442#msg-281442