[prev in list] [next in list] [prev in thread] [next in thread]
List: openssl-users
Subject: Disabling all pre-TLS-1.3 ciphers
From: Jordan Brown <openssl () jordan ! maileater ! net>
Date: 2024-01-10 0:08:28
Message-ID: 0101018cf0b2f2fe-8babe09e-383b-4242-86eb-b3adab9df9d6-000000 () us-west-2 ! amazonses ! com
[Download RAW message or body]
I have a product that lets the customer select what TLS versions to
allow, and what TLS ciphers to allow. (Of course, most of the time they
shouldn't mess with these settings, but sometimes the evolution of the
algorithm landscape requires it.)
So, simulating API calls from the command line, it's kind of sensible
that it's a problem if I disable all pre-1.3 ciphers while allowing all
protocol versions:
$ /usr/openssl/3/bin/openssl s_server -cert foo.pem -key foo.key -cipher ''
Call to SSL_CONF_cmd(-cipher, ) failed
01000000:error:0A0000B9:SSL routines:SSL_CTX_set_cipher_list:no cipher match:
../../openssl-3.0.12/ssl/ssl_lib.c:2760:
That configuration is a problem because pre-1.3 versions are enabled,
but have no available ciphers. Rejecting it seems reasonable.
Now let's restrict it to 1.3:
$ /usr/openssl/3/bin/openssl s_server -cert foo.pem -key foo.key -tls1_3 -cipher ''
Call to SSL_CONF_cmd(-cipher, ) failed
01000000:error:0A0000B9:SSL routines:SSL_CTX_set_cipher_list:no cipher match:
../../openssl-3.0.12/ssl/ssl_lib.c:2760:
It's still rejected, but for no good reason: there are no pre-1.3
ciphers available, but there are no pre-1.3 versions available either.
It seems that, paradoxically, I must always enable at least one pre-1.3
cipher, even if I only enable 1.3.
On the other hand, but less annoying in some ways, it appears that it's
perfectly OK to require TLS 1.3 but disable all TLS 1.3 ciphers:
$ /usr/openssl/3/bin/openssl s_server -cert foo.pem -key foo.key -tls1_3 -ciphersuites ''
Using default temp DH parameters
ACCEPT
Presumably in this configuration no connection would ever succeed.
On the third hand, it's OK to require TLS 1.1 but enable only a TLS 1.2
cipher:
$ /usr/openssl/3/bin/openssl s_server -cert foo.pem -key foo.key -tls1_1 -cipher AES128-SHA256
Using default temp DH parameters
ACCEPT
It seems to me that the first (that you can't disable all pre-1.3
ciphers, even when you disable all pre-1.3 versions) is a bug. The
configuration is entirely sensible, but rejected. The second is
arguably a bug, that a nonsensical configuration *isn't* rejected, but
that seems like a less serious error. The third is also arguably a bug
on similar grounds.
The workaround would seem to be to always enable at least one pre-1.3
cipher (perhaps by leaving the default alone), even when pre-1.3
versions are all disabled.
I think the checks should be fixed to accept all sensible
configurations, and optionally to reject all nonsensical configurations.
(Note again that while I am demonstrating using the CLI, I expect that
the library behaves the same.)
Any thoughts?
--
Jordan Brown, Oracle ZFS Storage Appliance, Oracle Solaris
[Attachment #3 (text/html)]
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
I have a product that lets the customer select what TLS versions to
allow, and what TLS ciphers to allow. (Of course, most of the time
they shouldn't mess with these settings, but sometimes the evolution
of the algorithm landscape requires it.)<br>
<br>
So, simulating API calls from the command line, it's kind of
sensible that it's a problem if I disable all pre-1.3 ciphers while
allowing all protocol versions:<br>
<blockquote>
<pre>$ /usr/openssl/3/bin/openssl s_server -cert foo.pem -key foo.key -cipher \
'' Call to SSL_CONF_cmd(-cipher, ) failed
01000000:error:0A0000B9:SSL routines:SSL_CTX_set_cipher_list:no cipher match:
../../openssl-3.0.12/ssl/ssl_lib.c:2760:
</pre>
</blockquote>
That configuration is a problem because pre-1.3 versions are
enabled, but have no available ciphers. Rejecting it seems
reasonable.<br>
<br>
Now let's restrict it to 1.3:<br>
<blockquote>
<pre>$ /usr/openssl/3/bin/openssl s_server -cert foo.pem -key foo.key -tls1_3 \
-cipher '' Call to SSL_CONF_cmd(-cipher, ) failed
01000000:error:0A0000B9:SSL routines:SSL_CTX_set_cipher_list:no cipher match:
../../openssl-3.0.12/ssl/ssl_lib.c:2760:
</pre>
</blockquote>
It's still rejected, but for no good reason: there are no pre-1.3
ciphers available, but there are no pre-1.3 versions available
either.<br>
<br>
It seems that, paradoxically, I must always enable at least one
pre-1.3 cipher, even if I only enable 1.3.<br>
<br>
On the other hand, but less annoying in some ways, it appears that
it's perfectly OK to require TLS 1.3 but disable all TLS 1.3
ciphers:<br>
<blockquote>
<pre>$ /usr/openssl/3/bin/openssl s_server -cert foo.pem -key foo.key -tls1_3 \
-ciphersuites '' Using default temp DH parameters
ACCEPT
</pre>
</blockquote>
Presumably in this configuration no connection would ever succeed.<br>
<br>
On the third hand, it's OK to require TLS 1.1 but enable only a TLS
1.2 cipher:<br>
<blockquote>
<pre> $ /usr/openssl/3/bin/openssl s_server -cert foo.pem -key foo.key -tls1_1 \
-cipher AES128-SHA256 Using default temp DH parameters
ACCEPT
</pre>
</blockquote>
It seems to me that the first (that you can't disable all pre-1.3
ciphers, even when you disable all pre-1.3 versions) is a bug. The
configuration is entirely sensible, but rejected. The second is
arguably a bug, that a nonsensical configuration *isn't* rejected,
but that seems like a less serious error. The third is also
arguably a bug on similar grounds.<br>
<br>
The workaround would seem to be to always enable at least one
pre-1.3 cipher (perhaps by leaving the default alone), even when
pre-1.3 versions are all disabled.<br>
<br>
I think the checks should be fixed to accept all sensible
configurations, and optionally to reject all nonsensical
configurations.<br>
<br>
(Note again that while I am demonstrating using the CLI, I expect
that the library behaves the same.)<br>
<br>
Any thoughts?<br>
<pre class="moz-signature" cols="72">--
Jordan Brown, Oracle ZFS Storage Appliance, Oracle Solaris</pre>
</body>
</html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic