Re: [crit] SSL_read_early_data() failed

2020-03-05 Пенетрантность mikhal123
В коллекцию "критических" для nginx ошибок:

2020/03/05 18:52:12 [crit] 2112#2112: *1715715 SSL_write() failed while
processing HTTP/2 connection, client: ip_адрес_клиента

2020/03/05 19:51:36 [crit] 2107#2107: *1814649 SSL_write() failed while
sending response to client, client: ip_адрес_клиента

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,287080,287270#msg-287270

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: [crit] SSL_read_early_data() failed

2020-02-25 Пенетрантность mikhal123
> >  Может быть, команда разработчиков рассмотрит возможность добавления
директивы переопределения пользователем уровня ошибок, по аналогии например
с
http://nginx.org/ru/docs/http/ngx_http_limit_req_module.html#limit_req_log_level
?
> Обычно ребята предлагают протестировать подобные штуки, тем более что ты
тот клиент кто может верифицировать - помогает патч или нет.

Можешь смело считать что я протестировал предлагаемый патч, и он работает.

Но вот здесь определено ещё 100500 кодов ошибок (и будут появляться новые),
о которых nginx в настоящее время ничего не знает и считает по-умолчанию
критическими
https://github.com/openssl/openssl/blob/6d53ad6b5cf726d92860e973d7bc8c1930762086/include/openssl/sslerr.h#L464

Наверное, есть какая-то логика обучать nginx по одной ошибке за раз, но от
меня она ускользает :)

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,287080,287103#msg-287103

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: [crit] SSL_read_early_data() failed

2020-02-24 Пенетрантность Aleksandr Sytar
вс, 23 февр. 2020 г. в 21:07, mikhal123 :

>  Может быть, команда разработчиков
> рассмотрит возможность добавления директивы переопределения пользователем
> уровня ошибок, по аналогии например с
>
> http://nginx.org/ru/docs/http/ngx_http_limit_req_module.html#limit_req_log_level
> ?
>

Обычно ребята предлагают протестировать подобные штуки, тем более что ты
тот клиент кто может верифицировать - помогает патч или нет.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: [crit] SSL_read_early_data() failed

2020-02-23 Пенетрантность mikhal123
> > [crit] 11016#11016: *46796 SSL_read_early_data() failed
(SSL:error:1423D06E:SSL routines:tls_parse_ctos_server_name:bad extension)
while SSL handshaking, client: , server: 0.0.0.0:443
> Было бы интересно посмотреть, что конкретно там прилетает.
Каким образом можно это сделать? nginx-debug записывает отладочный лог до
такой степени детализации?

> > 2. Если так, то с какой целью данное извещение выводится с таким высоким
уровнем приоритета (crit)
> Так происходит по умолчанию, чтобы не пропустить ничего важного.
> > 3. Можно ли как-то отключить вывод данного извещения (например, понизив
его приоритет до warn) в логи для приведения их в прежний благопристойный
вид?
> Можно попробовать патч, понижающий уровень:
Патч наверняка сработает, но пара тысяч ненужных записей в логах в день не
перевешивают необходимости собрать nginx самому и потом патчить его заново
при выходе каждой следующей версии. Может быть, команда разработчиков
рассмотрит возможность добавления директивы переопределения пользователем
уровня ошибок, по аналогии например с
http://nginx.org/ru/docs/http/ngx_http_limit_req_module.html#limit_req_log_level
? Или я единственный админ, который недоумевает что там может быть такого
важного при установке ssl-соединения, раз я всё равно никак не могу повлиять
на повторное возникновение этих же ошибок

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,287080,287093#msg-287093

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: [crit] SSL_read_early_data() failed

2020-02-22 Пенетрантность Sergey Kandaurov

> On 21 Feb 2020, at 22:19, mikhal123  wrote:
> 
> Включил на своём сервере опцию "ssl_early_data". Всё вроде бы хорошо, но в
> error.log довольно много (порядка 0.5% от общего числа запросов, что на
> трафике в миллион уже немного напрягает) записей вида:
> [crit] 11016#11016: *46796 SSL_read_early_data() failed (SSL:
> error:1423D06E:SSL routines:tls_parse_ctos_server_name:bad extension) while
> SSL handshaking, client: , server: 0.0.0.0:443
> 

Было бы интересно посмотреть, что конкретно там прилетает.

> В связи с этим хотелось бы узнать:
> 1. Правильно ли я понимаю, что это проблемы со стороны клиентов (слишком
> старые клиенты?), и на сервере невозможно что-либо поделать для исправления
> этой ситуации?

Верно.  Так происходит, например, если получен испорченный SNI:
плохой тип и/или длина значения, нулевые байты в значении, плохой формат.

> 2. Если так, то с какой целью данное извещение выводится с таким высоким
> уровнем приоритета (crit)

Так происходит по умолчанию, чтобы не пропустить ничего важного.

> 3. Можно ли как-то отключить вывод данного извещения (например, понизив его
> приоритет до warn) в логи для приведения их в прежний благопристойный вид?
> 

Можно попробовать патч, понижающий уровень:

# HG changeset patch
# User Sergey Kandaurov 
# Date 1582383432 -10800
#  Sat Feb 22 17:57:12 2020 +0300
# Node ID ffb1eaf3bd6233d941e531d68785671ae457
# Parent  72b792bb3885727bf381d4c4e66cfaf754ac7a59
SSL: logging level of "bad extension".

The "bad extension" errors are reported by OpenSSL 1.1.1
if an invalid servername extension value is received.

diff --git a/src/event/ngx_event_openssl.c b/src/event/ngx_event_openssl.c
--- a/src/event/ngx_event_openssl.c
+++ b/src/event/ngx_event_openssl.c
@@ -2896,6 +2896,9 @@ ngx_ssl_connection_error(ngx_connection_
 #ifdef SSL_R_NO_SUITABLE_KEY_SHARE
 || n == SSL_R_NO_SUITABLE_KEY_SHARE  /*  101 */
 #endif
+#ifdef SSL_R_BAD_EXTENSION
+|| n == SSL_R_BAD_EXTENSION  /*  110 */
+#endif
 #ifdef SSL_R_NO_SUITABLE_SIGNATURE_ALGORITHM
 || n == SSL_R_NO_SUITABLE_SIGNATURE_ALGORITHM/*  118 */
 #endif

Или конкретно для SNI:

diff --git a/src/event/ngx_event_openssl.c b/src/event/ngx_event_openssl.c
--- a/src/event/ngx_event_openssl.c
+++ b/src/event/ngx_event_openssl.c
@@ -2896,6 +2896,11 @@ ngx_ssl_connection_error(ngx_connection_
 #ifdef SSL_R_NO_SUITABLE_KEY_SHARE
 || n == SSL_R_NO_SUITABLE_KEY_SHARE  /*  101 */
 #endif
+#ifdef SSL_R_BAD_EXTENSION
+|| (n == SSL_R_BAD_EXTENSION /*  100 */
+&& ERR_GET_FUNC(ERR_peek_error())
+  == SSL_F_TLS_PARSE_CTOS_SERVER_NAME)
+#endif
 #ifdef SSL_R_NO_SUITABLE_SIGNATURE_ALGORITHM
 || n == SSL_R_NO_SUITABLE_SIGNATURE_ALGORITHM/*  118 */
 #endif

-- 
Sergey Kandaurov

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

[crit] SSL_read_early_data() failed

2020-02-21 Пенетрантность mikhal123
Включил на своём сервере опцию "ssl_early_data". Всё вроде бы хорошо, но в
error.log довольно много (порядка 0.5% от общего числа запросов, что на
трафике в миллион уже немного напрягает) записей вида:
[crit] 11016#11016: *46796 SSL_read_early_data() failed (SSL:
error:1423D06E:SSL routines:tls_parse_ctos_server_name:bad extension) while
SSL handshaking, client: , server: 0.0.0.0:443

В связи с этим хотелось бы узнать:
1. Правильно ли я понимаю, что это проблемы со стороны клиентов (слишком
старые клиенты?), и на сервере невозможно что-либо поделать для исправления
этой ситуации?
2. Если так, то с какой целью данное извещение выводится с таким высоким
уровнем приоритета (crit)
3. Можно ли как-то отключить вывод данного извещения (например, понизив его
приоритет до warn) в логи для приведения их в прежний благопристойный вид?

nginx -V
nginx version: nginx/1.17.8
built by gcc 8.3.0 (Debian 8.3.0-6)
built with OpenSSL 1.1.1d  10 Sep 2019
TLS SNI support enabled
configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx
--modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf
--error-log-path=/var/log/nginx/error.log
--http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid
--lock-path=/var/run/nginx.lock
--http-client-body-temp-path=/var/cache/nginx/client_temp
--http-proxy-temp-path=/var/cache/nginx/proxy_temp
--http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp
--http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp
--http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx
--with-compat --with-file-aio --with-threads --with-http_addition_module
--with-http_auth_request_module --with-http_dav_module
--with-http_flv_module --with-http_gunzip_module
--with-http_gzip_static_module --with-http_mp4_module
--with-http_random_index_module --with-http_realip_module
--with-http_secure_link_module --with-http_slice_module
--with-http_ssl_module --with-http_stub_status_module --with-http_sub_module
--with-http_v2_module --with-mail --with-mail_ssl_module --with-stream
--with-stream_realip_module --with-stream_ssl_module
--with-stream_ssl_preread_module --with-cc-opt='-g -O2
-fdebug-prefix-map=/data/builder/debuild/nginx-1.17.8/debian/debuild-base/nginx-1.17.8=.
-fstack-protector-strong -Wformat -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -fPIC' --with-ld-opt='-Wl,-z,relro -Wl,-z,now
-Wl,--as-needed -pie'

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,287080,287080#msg-287080

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru