OpenSSL 3.1.0 does not support DTLS-1.0 by default

[Splediferous]

OS: Windows 10
OpenSSL Verison 3.1.0

Openssl.exe, libssl-3-x64.dll and libcrypto-3-x64 are compiled from source with the following compile options:
no-zlib
no-module
enable-legacy
enable-fips

I am using the libss-3 and libcrypto-3 binaries but the issue can be demonstrated with openssl.exe

To reproduce:
Start the openssl client and server with the following options
openssl.exe s_server -dtls1 -listen -4 -state -debug
openssl.exe s_client -dtls1 -4 -state -debug

Client reports:

CONNECTED(00000158)
800D0000:error:0A0000BF:SSL routines:tls_setup_handshake:no protocols available:ssl/statem/statem_lib.c:104:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 15 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
---

[process exited with code 1 (0x00000001)]
You can now close this terminal with Ctrl+D, or press Enter to restart.

Server Reports

Using default temp DH parameters
ACCEPT
read from 0x1eaeaf1aa30 [0x1eaeaf32103] (16397 bytes => 15 (0xF))
0000 - 15 fe ff 00 00 00 00 00-00 00 00 00 02 02 46      ..............F
DELAY

It seems the TLS1_1 cipher suites (which I believe DTLSv1 is based on) are not being compiled in. TLS1.0 and TLS1.1 also do not work.

Setting Max and Min Protocol Version to DTLS1_VERSION does not emit any errors. (SSL_CTX_set_max_proto_version and SSL_CTX_set_min_proto_version)

openssl.exe ciphers -s -tls1_1 shows an empty list.

TLSv1 and TLSv1_1 methods (e.g. TLSv1_client_method) are available in the binary so it seems that the compile option no-tls1 is not being invoked.

Compile options enable-{tls1|tls1_1} have no effect.

Is there something I'm missing?

[t8m]

You need to use -cipher DEFAULT:@SECLEVEL=0 option with s_client or s_server otherwise only TLS1.2 and above and DTLS1.2 is enabled.

To override the default security level at OpenSSL build time you can use -DOPENSSL_TLS_SECURITY_LEVEL=0 on the Configure command line.

You can also use SSL_CTX_set_security_level(SSL_CTX *ctx, int level) or SSL_set_security_level(SSL *s, int level) calls from the application to override the default security level.

[Splediferous]

OK. That's a little confusing. Is this a change of approach?
Previously, everything was enabled and we had to specifically use the compile time options to disable (e.g. no={tls1|tls1_1}. I don't see an option to enable this in the INSTALL doc. Is it documented anywhere?

It also means that even though the cipher suites are not included at compile by default any more, the TLSv1 methods are still available in the libraries. Are they NOP's?

I wasn't sure where "-ciphers DEFAULT:@SECLEVEL=0" was supposed to be used (configure? make? openssl.exe? SSL_CTX_set_cipher_list?) but I configured for compile using:

./Configure -DOPENSSL_TLS_SECURITY_LEVEL=0 no-zlib no-module enable-legacy enable-fips

That seems to have done the trick and can now use DTLSv1 (and TLS1.0/1.1).
Thanks for very fast response and guidance.

[mattcaswell]

I wasn't sure where "-ciphers DEFAULT:@SECLEVEL=0" was supposed to be used

It's a runtime parameter to s_server/s_client. DTLSv1 and all its ciphersuites are compiled in by default. However the default security level will prevent certain algorithms from being used. Notably SHA1 is no longer considered sufficient secure for default use. Since DTLSv1 uses SHA1 it isn't available at the default security level. Simply changing the security level makes everything work again.

Is this a change of approach?

Security levels have been there for a long time. What has changed is that SHA1 dropped out of the default security level due to it no longer being considered sufficiently secure.

It also means that even though the cipher suites are not included at compile by default any more, the TLSv1 methods are still available in the libraries.

Everything you need for DTLSv1 is compiled in by default. You just need to change the runtime security level setting to make them usable.

[Splediferous]

I wasn't sure where "-ciphers DEFAULT:@SECLEVEL=0" was supposed to be used

It's a runtime parameter to s_server/s_client. DTLSv1 and all its ciphersuites are compiled in by default. However the default security level will prevent certain algorithms from being used. Notably SHA1 is no longer considered sufficient secure for default use. Since DTLSv1 uses SHA1 it isn't available at the default security level. Simply changing the security level makes everything work again.

Is this a change of approach?

Security levels have been there for a long time. What has changed is that SHA1 dropped out of the default security level due to it no longer being considered sufficiently secure.

It also means that even though the cipher suites are not included at compile by default any more, the TLSv1 methods are still available in the libraries.

Everything you need for DTLSv1 is compiled in by default. You just need to change the runtime security level setting to make them usable.

s_client and s_server report:

s_server: Unknown option: -ciphers
s_server: Use -help for summary.

s_client: Unknown option: -ciphers
s_client: Use -help for summary.

Are you sure you are not referring to 1.1.1 rather than 3.1.0? IT's fine in 1.1.1. In 3.1.0 we are supposed to use max and min protocol versions instead of those strings. From the cipher dump (see first post), the tls1 ciphers don't seem to be available at all by default.

[mattcaswell]

Unknown option: -ciphers

Typo in @t8m's original response. The option is actually called "-cipher".

[t8m]

Yep, I always confuse the -cipher option with the ciphers command.

[Splediferous]

Aha. OK. That seems to work.

Having to use the SSL_CTX_set_cipher_list is a bit of a pain for me as users can define it.

What has changed is that SHA1 dropped out of the default security level due to it no longer being considered sufficiently secure.

I guess I misunderstood.
In previously incarnations it seemed everything was enabled and the security level would limit to the defined level (if supplied). We would also use -tls:-tls1_1 etc which again gave the impressions that everything was enabled and we would limit using the string.

But I should have read the documentation more closely...

If an application doesn't set its own security callback the default callback is used.

DOPENSSL_TLS_SECURITY_LEVEL=level. If not set then 1 is used.

Level 1
Additionally, SSLv3, TLS 1.0, TLS 1.1 and DTLS 1.0 are all disabled at this level.

I was confused as there were no errors emitted to tell me I had a setting wrong and it just didn't seem to work (would connect then fail). Without your tribal knowledge I wouldn't have realised it was to do with the security level.

Thanks to everyone for your patience and very quick responses.
I'll just compile with DOPENSSL_TLS_SECURITY_LEVEL=0 and then min/max protocol level behave as expected without having to set SSL_CTX_set_cipher_list.

[chrispugmire]

So they've broken backward compatibility yet again, this causes a lot of people a lot of pain. And makes people reluctant to update to the latest version. Anyway for anyone wondering the functions to add to fix it are:

void SSL_CTX_set_security_level(SSL_CTX *ctx, int level);
void SSL_set_security_level(SSL *s, int level);

With level set to zero.

[t8m]

Without dropping support for obsolete TLS versions and insecure ciphers (at least in the default configuration) we would be making internet unsafe. Also effectively the 3.1.0 does not change things from 3.0.0 where SHA1 is already disabled in SECLEVEL > 0 and that hash is required for DTLS-1.0.