Re: [openssl-project] Inappropriate fallback triggered when "holes" in client protocol list indirectly exclude TLSv1.3
> On Aug 15, 2018, at 11:50 AM, Matt Caswell wrote: >> >> I think this counts as a regression, the client should notice that >> it implicitly disabled TLS 1.3, and therefore not react to the >> server's version sentinel by aborting the connection. Thoughts? >> > > Hmm. Yes we should probably handle this scenario. Can you open a github > issue? https://github.com/openssl/openssl/issues/6964 -- Viktor. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] Inappropriate fallback triggered when "holes" in client protocol list indirectly exclude TLSv1.3
On 15/08/18 16:46, Viktor Dukhovni wrote: > When I configure a client with a legacy TLS 1.2 protocol exclusion, > e.g. by setting SSL_OP_NO_TLSv1_2 (rather than the new min/max > version interface), as a result of the new TLS 1.3 protocol > suport configurations that previously negotiated "up to" TLS 1.1, > now fail when communicating with a TLS 1.3 server: > > $ posttls-finger -c -p '!TLSv1.2' "[127.0.0.1]" > posttls-finger: SSL_connect error to 127.0.0.1[127.0.0.1]:25: -1 > posttls-finger: warning: TLS library problem: error:1425F175:SSL > routines:ssl_choose_client_version:inappropriate > fallback:../openssl/ssl/statem/statem_lib.c:1939: > > If I then also explicitly disable "TLSv1.3" the connection succeeds: > > $ posttls-finger -c -lmay -Lsummary -p '!TLSv1.2:!TLSv1.3' "[127.0.0.1]" > posttls-finger: Anonymous TLS connection established to > 127.0.0.1[127.0.0.1]:25: TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits) > > I think this counts as a regression, the client should notice that > it implicitly disabled TLS 1.3, and therefore not react to the > server's version sentinel by aborting the connection. Thoughts? > Hmm. Yes we should probably handle this scenario. Can you open a github issue? Matt ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
[openssl-project] Inappropriate fallback triggered when "holes" in client protocol list indirectly exclude TLSv1.3
When I configure a client with a legacy TLS 1.2 protocol exclusion, e.g. by setting SSL_OP_NO_TLSv1_2 (rather than the new min/max version interface), as a result of the new TLS 1.3 protocol suport configurations that previously negotiated "up to" TLS 1.1, now fail when communicating with a TLS 1.3 server: $ posttls-finger -c -p '!TLSv1.2' "[127.0.0.1]" posttls-finger: SSL_connect error to 127.0.0.1[127.0.0.1]:25: -1 posttls-finger: warning: TLS library problem: error:1425F175:SSL routines:ssl_choose_client_version:inappropriate fallback:../openssl/ssl/statem/statem_lib.c:1939: If I then also explicitly disable "TLSv1.3" the connection succeeds: $ posttls-finger -c -lmay -Lsummary -p '!TLSv1.2:!TLSv1.3' "[127.0.0.1]" posttls-finger: Anonymous TLS connection established to 127.0.0.1[127.0.0.1]:25: TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits) I think this counts as a regression, the client should notice that it implicitly disabled TLS 1.3, and therefore not react to the server's version sentinel by aborting the connection. Thoughts? -- Viktor. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project