Default to TLS v1.2 in all TLS libraries in 20.04 LTS

Project Discussion Foundations
, ,
1

https://blog.surgut.co.uk/2019/08/how-to-disable-tls-10-and-tls-11-on.html

Although one can disable TLS 1.0 and 1.1 locally today, it’s unlikely people will do that. It is no longer a sensible default to keep TLS 1.0 and 1.1 enabled by default.

Other vendor announced that they will be disabling client support for TLS 1.0 and 1.1 in spring 2020. I would like to align with them, and set compiled in default to TLS v1.2 in all the libraries. The API/ABI will be preserved and one would be able to turn TLS 1.0/1.1 back on, using config files or API calls as needed.

Are you ready for TLS v1.2?

2 Likes
2

Was this change made in Ubuntu 20.04? It acts like it.

How can I revert this change so I can continue to provide a TLS 1.0/1.1 service for e.g. old Android phones?

3

Hello Oliver / xnox,
Any updates on the issue?
I am also facing the same problem.
We have an old windows application which supports only TLS1 and now its not working.
How can we enable TSL 1.0 on our server manually?
I have tried “SSLProtocol +TLSv1 +TLSv1.1” in Apache config but it doesn’t work.

Please help.

4

Blog post with details coming up soon.

Yes, this is now in place for OpenSSL, GnuTLS, NSS. We default to strong keys and TLSv1.2 minimum.

To revert:

  • OpenSSL set Cipher String to lower seclevel from 2 to 1, like so: DEFAULT@SECLEVEL=1
  • GnuTLS create overrides file and set priority string to: NORMAL
  • NSS lower the min protocol version
5

Like many I was also hit by the seclevel change. I’m sure the blog post will explain the tecnical details but essentially in openssl you can enable tls versions and additionally there is a concept of security levels. Contrary to the default in ubuntu 20.04 tls 1.0 and 1.1 are only allowed on security level <2 instead of <4. Also the default security level of 1 was raised to 2.

This disables tls < 1.2 in qt since there is no way (i checked the source code, they make it impossible) to change the security level/cipher string. That gives the strange situation where the qt api lets you force the tls version to 1.0 but in that case you essentially break everything. It gives you a nice socket error -1 (qt does not know how to handle the error thrown by openssl).

Since ubuntu changed defaults I do not expect qt to fix this upstream. My suggestions would be change the default QSslConfiguration to Tls1_2OrLater (if not already) and append @SECLEVEL=1 to the cipher string if TLS1_0 or TLS1_1 is requested. Another possibility would be to undefine unsupported tls versions so that compiling software that uses invalid configuration fails.

Another side note: In ubuntu 20.04 it is also impossible by default to use “sha1” certificates. This should be no issue since they were deprecated some years ago, but some inhouse ca might still use them.

6

This gratuitously breaks evolution-ews to Exchange 2010 servers. Nobody cares about using old TLS versions on a desktop OS. It’s paranoia that inconveniences users for no benefit.

7

OpenSSL set Cipher String to lower seclevel from 2 to 1, like so: DEFAULT@SECLEVEL=1

Can this be done systemwide? I made an attempt but didn’t get anywhere.

I’m really tearing my hair out about this for months now, I can’t find the solution anywhere (and the people who may know probably have no interest in TLS 1.0 & 1.1 anymore — but I can’t avoid it.

8

Yes it can be, quite trivially.

NB! This significantly decreases security & privacy and enables protocols and key sizes that are no longer deemed secure, and must not be used in production any more. Use at your own risk of getting hacked and all of your private data stolen.

--- /etc/ssl/openssl.cnf        2020-07-01 12:30:10.966775346 +0100
+++ /etc/ssl/openssl.cnf        2020-07-01 12:30:30.714978507 +0100
@@ -11,6 +11,8 @@
 # defined.
 HOME                   = .
 
+openssl_conf = default_conf
+
 # Extra OBJECT IDENTIFIER info:
 #oid_file              = $ENV::HOME/.oid
 oid_section            = new_oids
@@ -349,3 +351,11 @@
 ess_cert_id_alg                = sha1  # algorithm to compute certificate
                                # identifier (optional, default: sha1)
 
+[default_conf]
+ssl_conf = ssl_sect
+
+[ssl_sect]
+system_default = system_default_sect
+
+[system_default_sect]
+CipherString = DEFAULT@SECLEVEL=1

Note how the openssl_conf stanza has to be at the very top of the file, without a section. And how default_conf sections are appended at the end. This is a diff against stock /etc/ssl/openssl.cnf which is the default system-wide config file which will be parsed by openssl.

However, you can also create that as a separate config file and use environmental variable OPENSSL_CONF = /path/to/patched/seclevel1-openssl.cnf and use that in individual service units, daemons, apps. To allow things on per-app/per-user/per-daemon basis.

Note that it’s best to actually upgrade your clients & servers to support TLSv1.2.

Similarly for GnuTLS one can create

$ cat /etc/gnutls/config
[overrides]
default-priority-string = NORMAL

Or you use export GNUTLS_SYSTEM_PRIORITY_FILE=/path/to/gnutls/override-normal-config

Again, this significantly reduces security and increase risk of your data being stolen.

Normallly, the GnuTLS priority string is

NORMAL:-VERS-ALL:+VERS-TLS1.3:+VERS-TLS1.2:+VERS-DTLS1.2:%PROFILE_MEDIUM

Let me know if this helps, and if you have any issues do provide all the details, all the file paths, all the config files contents. It’s quite easy to make a typo, and things not working as expected.

2 Likes
9

Thanks, I managed! That was really helpful.

1 Like
10

Thank you very much, this was surprising hard information to find.
The usage of the ENV variable is an excellent suggestion, limits the lower security to a particular connection only.

11

Hello, I have tried every possible solution to enable TLS 1.0, 1.1 and 1.2 on this version of desktop.
Nothing is working.

Does anyone out there have a proper foolproof solution to enable lower versions of TLS on 20.04?

I cannot use my VMView Horizon Client any longer due to this restriction.

I understand that having an SSL certificate on the connection server would be a proper solution, but I do not have the ability to make this possible.

Any help would be appreciated.

12

what are the error messages? what libraries and settings does VMView use?

1 Like
13

Started running into this change since the last OpenSSL update in Ubuntu 20.04.2 last week. Been trying to apply the changes in config to /etc/ssl/openssl.cnf to no avail. also tried applying context.

my way of testing is either running

openssl s_client -connect google.com:443

or while I program on python trying a imaplib.IMAP4_SSL connection to a mail server say “outlook.office365.com”

connection times out.

Is there a way for me to check if openssl is taking the configuration I setup ?

14

Both google.com and outlook.office365.com support TLSv1.2 and work correctly without any modifications to any gnutls or openssl settings on any Ubuntu release.

Hanging connections are never a symptom of miscofigured or incompatible openssl or gnutls connectivity. They always fail quickly and loudly.

You should not need to modify any changes to openssl or gnutls to talk to google.com or outlook.office365.com.

Hanging connections are usually an indicator of issues with DNS resolution, default gateway, routes, firewalls.

Please try resolvectl query google.com and mtr google.com as the first step to figure out if DNS is resolving things correctly, and if gateway & routes can connect correctly to google.com and there are no issues with your ip address; gateway; routes; firewalls between yourself and google.

When I run openssl s_client -connect google.com:443 it connects extremely quickly, like instantly. If it hangs and you see no messages it is not yet a TLS issue, but networking connectivity one.

You can further try things like this openssl s_client -tls1_3 -connect google.com:443 and openssl s_client -tls1_2 -connect google.com:443 to check if firewalls in your network explicitly block the particular versions of TLS. If they do block one but not the other, it is an indication of a potentially bad actor in your network that are trying to prohibit perfect forward secrecy connections on your network.

2 Likes
15

Thanks for the prompt reply.

Tried

resolvectl query google.com

and responded quickly. but traceroute to google.com hangs and testing connection via openssl s_client -tls1_2 -connect google.com:443 and openssl s_client -tls1_2 -connect google.com:443 just hangs to no response too.

but with your indications then it would be a firewall issue now I do not have a very complicated setup just my ISP provided equipment. Looked for anything that would seem to be checking on SSL cypher rules on the router and modem but nothing.

This is not a production environment. It is a development testing machine and I wanted to lower the SSL default seclevel to 1 the changes to the openssl.cnf do not work.

I appreciate your spying eye on this issue. I will see about testing on another server in another connection.

16

one will not tls with google.com unless traceroute to google.com starts working.

even with uncomplicated setups one might have missconfigured things preventing communication.

for example, most of ISP provided equipment by default can have DNS impersonators and firewalls that do phishing detection but also break TLS connectivity. You might need to change settings in your router, or sometimes even login to your ISP account to disable DNS masquerading that they at times do.

None of your issues are yet related to the topic of this thread in any way =) as with or without any changes to any configs communication with google.com should work fine.

1 Like
17

Could this be an MTU issue? This is fairly common in some ISP-type connections, results in connection hangs and eventual timeouts, and tends to be exposed when the size of protocol handshakes change.

18

EXCELLENT WORK - SORRY FOR THE ALL CAPS - I’M MENTALLY IMPAIRED AS WE ALL ARE
I’M RUNNING UBUNTU 20.04.5 AND HAVE THE TLS ISSUE - I’VE AN IMPORTANT DOMAIN THAT IS HOSTED ON IONOS - THEY REQUIRE TLSv1.2. OR IS IT POSSIBLE TO TRICK THEM WITH TLSv1 ??
IT APPEARS THAT YOU GUYS ARE INSERTING COMMANDS TO UBUNTU VIA THE TERMINAL?
I’VE RUN PROGRAMS ON THE TERMINAL BEFORE - AN INTENTION REPEATER THAT IS MAGICAL
THANK YOU KINDLY