SSL_do_handshake() failed (SSL: error:141CF06C:SSL routines:tls_parse_ctos_key_share:bad key share) while SSL handshaking

[Maxim Dounin]

Hello!

On Tue, Jul 12, 2022 at 03:52:16PM +0400, Sergey Kandaurov wrote:

> On Tue, Jul 12, 2022 at 04:23:59AM +0300, Maxim Dounin wrote:
> > Hello!
> > 
> > On Mon, Jul 11, 2022 at 09:06:53PM +0300, Gena Makhomed wrote:
> > 
> > > On 10.07.2022 11:41, Maxim Dounin wrote:
> > > 
> > > >> Как выловить такие ошибки в логе? 
> > > >> я их не вижу, есть ошибки типа warn Но это не то.
> > > 
> > > > Вы чуть раньше в этом треде писали Илье, "client sent plain HTTP
> > > > request to HTTPS port".  Как и другие ошибки в клиентских
> > > > запросах, эти ошибки логгируются на уровне info.
> > > 
> > > nginx/1.23.0 из официального репозитория nginx.org пишет в лог:
> > > 
> > > 2022/07/11 13:14:48 [crit] 67688#67688: *154358 SSL_do_handshake() 
> > > failed (SSL: error:141CF06C:SSL routines:tls_parse_ctos_key_share:bad 
> > > key share) while SSL handshaking, client: 192.241.214.22, server: 
> > > 0.0.0.0:443
> > > 
> > > проблема тут https://stackoverflow.com/a/67424645 на стороне клиента,
> > > но в лог информация пишется на уровне [crit] - так и должно быть?
> > 
> > Нет, так не должно быть. Просто это относительно новая ошибка, 
> > добавленная в OpenSSL 1.1.1 / TLSv1.3, и ей пока не прибит 
> > правильный уровень логгирования.  Патч ниже.
> > 
> > Если в логах вылезает что-то ещё - можно и нужно жаловаться.
> > 
> > # HG changeset patch
> > # User Maxim Dounin <mdounin на mdounin.ru>
> > # Date 1657587735 -10800
> > #      Tue Jul 12 04:02:15 2022 +0300
> > # Node ID ae4b86fa92e6eb0c1fa13482695218b334f2adc3
> > # Parent  219217ea49a8d648f5cadd046f1b1294ef05693c
> > SSL: logging levels of various errors added in OpenSSL 1.1.1.
> > 
> > Starting with OpenSSL 1.1.1, various additional errors can be reported
> > by OpenSSL in case of client-related issues, most notably during TLSv1.3
> > handshakes.  In particular, SSL_R_BAD_KEY_SHARE ("bad key share"),
> > SSL_R_BAD_EXTENSION ("bad extension"), SSL_R_BAD_CIPHER ("bad cipher"),
> > SSL_R_BAD_ECPOINT ("bad ecpoint").  These are now logged at the "info"
> > level.
> 
> Looks good.
> 
> I managed to repoduce all of the errors except SSL_R_BAD_CIPHER,
> which requires extra effort to implement HRR in order to trigger it.
> Others are easy to trigger.

Pushed to http://mdounin.ru/hg/nginx/.

> If trying to enumerate TLSv1.3-specific client errors, I'd also add these
> I catched with my QUIC tests adjusted to generic TLSv1.3 over TCP:
> 
> boringssl/include/openssl/ssl.h:#define SSL_R_MISSING_KEY_SHARE 258
> boringssl/include/openssl/ssl.h:#define SSL_R_DUPLICATE_KEY_SHARE 264
> - extension is either missing or includes a dublicate group
> 
> OpenSSL has a similar error "no suitable key share" for MISSING_KEY_SHARE.
> I couldn't find an equivalent for DUPLICATE_KEY_SHARE, though.
> 
> boringssl/include/openssl/ssl.h:#define SSL_R_ERROR_PARSING_EXTENSION 149
> boringssl/include/openssl/ssl.h:#define SSL_R_PARSE_TLSEXT 190
> - both enqueued when e.g. receiving QUIC transport params in generic TLSv1.3:
> "SSL: error:10000095:SSL routines:OPENSSL_internal:ERROR_PARSING_EXTENSION:extension 57
>       error:100000be:SSL routines:OPENSSL_internal:PARSE_TLSEXT) while SSL handshaking"
> 
> PARSE_TLSEXT seems to be a rough replacement for SSL_R_BAD_EXTENSION.

I don't think I see any of these in nginx-related user reports, so 
I would rather postpone these for now.  (Either way, it looks like 
something for a separate patch.)

-- 
Maxim Dounin
http://mdounin.ru/