[Touch-packages] [Bug 1864689] Re: openssl in 20.04 can't connect to site that was fine in 19.10 and is fine in Chrome and Firefox
This bug affects me too, with a client certificate that now "magically"
does not match the requirements.
Ironically, the error message says only:
OpenSSL error error:140AB18E:SSL routines:SSL_CTX_use_certificate:ca md
too weak, (no key found, wrong pass phrase, or wrong file format?)
although there was no MD5 signature involved at all. So, even when you
know that with OpenSSL 1.1, an "SSL security level" has been introduced,
and that Ubuntu has set that level to 2, it is hard to find that it
deprecates SHA1 now (see
https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_security_level.html).
Thus, even for more knowledgable people than me this is a major hassle
to find and/or fix. I wonder why Ubuntu has chosen to raise the level
that high considering that the documentation page contains a clear
warning indication:
"WARNING at this time setting the security level higher than 1 for
general internet use is likely to cause considerable interoperability
issues and is not recommended. This is because the SHA1 algorithm is
very widely used in certificates and will be rejected at levels higher
than 1 because it only offers 80 bits of security."
I think that this is an extremely unwise choice for an OS to make.
That being said, here is the fix (also hard to find):
In /etc/ssl/openssl.cnf, add this line before the start of the file:
openssl_conf = default_conf
At the end of the file, add these lines:
[default_conf]
ssl_conf = ssl_sect
[ssl_sect]
system_default = system_default_sect
[system_default_sect]
CipherString = DEFAULT:@SECLEVEL=1
This will bring down the SSL security level to the former level of 1.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssl in Ubuntu.
https://bugs.launchpad.net/bugs/1864689
Title:
openssl in 20.04 can't connect to site that was fine in 19.10 and is
fine in Chrome and Firefox
Status in OpenSSL:
Unknown
Status in openssl package in Ubuntu:
Confirmed
Bug description:
openssl in Ubuntu 20.04 (focal) refuses to connect to a web site that
openssl in Ubuntu 19.10 (eoan), Chrome, and Firefox are all happy to
connect to.
Reproduce with: `curl -v https://www.toodledo.com/'
or: `openssl s_client -connect www.toodledo.com:443`
or: `python3 -c 'import requests;
requests.get("https://www.toodledo.com/;)'`
or: `wget https://www.toodledo.com/`
These worked in Ubuntu 19.10 and don't work in 20.04.
I've tried all sorts of things to debug this further and I've just run
into walls. I hope someone who understands more about this stuff will
be able to figure it out.
ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: openssl 1.1.1d-2ubuntu3
ProcVersionSignature: Ubuntu 5.4.0-14.17-generic 5.4.18
Uname: Linux 5.4.0-14-generic x86_64
ApportVersion: 2.20.11-0ubuntu18
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Tue Feb 25 13:01:22 2020
InstallationDate: Installed on 2019-08-16 (192 days ago)
InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416)
SourcePackage: openssl
UpgradeStatus: Upgraded to focal on 2020-01-31 (25 days ago)
To manage notifications about this bug go to:
https://bugs.launchpad.net/openssl/+bug/1864689/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1872443] Re: /etc/securetty missing: dovecot not working
I cannot tell if this is a problem in whatever version of Debian, since I do not use it. Even with Ubuntu being derived from Debian at some point between 18.04 where /etc/securetty was delivered with package login and 20.04 where the whole package is unavailable. I think that is an interdependence between multiple packages, but I am not quite in the position to point at where (or even if) the problem could be fixed in Debian. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to shadow in Ubuntu. https://bugs.launchpad.net/bugs/1872443 Title: /etc/securetty missing: dovecot not working Status in shadow package in Ubuntu: New Bug description: With Ubuntu 20.04 Focal Fossa, /etc/securetty is missing from the "login" package (4.8.1-1ubuntu4). This leads to errors such as in /var/log/mail.log when a dovecot auth is tried: Apr 13 13:08:17 venus dovecot[10588]: imap-login: Login: user=, method=PLAIN, rip=192.168.123.1, lip=192.168.123.188, mpid=12200, TLS, TLSv1.2 with cipher ECDHE-E CDSA-AES256-GCM-SHA384 (256/256 bits) Apr 13 13:08:18 venus auth[12195]: pam_unix(dovecot:auth): Couldn't open /etc/secure tty: No such file or directory Apr 13 13:08:18 venus auth[12195]: pam_unix(dovecot:auth): Couldn't open /etc/secure tty: No such file or directory Apr 13 13:08:18 venus dovecot[10588]: imap-login: Login: user=, method=PLAIN, rip=192.168.123.1, lip=192.168.123.188, mpid=12202, TLS, TLSv1.2 with cipher ECDHE-E CDSA-AES256-GCM-SHA384 (256/256 bits) It seems that pam_unix still needs /etc/securetty, but login no longer provides it. There was a similar bug in debian that seems to be related: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931899 To my understanding, this is a problem between pam and login packages in 20.04. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1872443/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1872443] Re: /etc/securetty missing: dovecot not working
At least, in 18.04, the file /etc/securetty was in package login... -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to shadow in Ubuntu. https://bugs.launchpad.net/bugs/1872443 Title: /etc/securetty missing: dovecot not working Status in shadow package in Ubuntu: New Bug description: With Ubuntu 20.04 Focal Fossa, /etc/securetty is missing from the "login" package (4.8.1-1ubuntu4). This leads to errors such as in /var/log/mail.log when a dovecot auth is tried: Apr 13 13:08:17 venus dovecot[10588]: imap-login: Login: user=, method=PLAIN, rip=192.168.123.1, lip=192.168.123.188, mpid=12200, TLS, TLSv1.2 with cipher ECDHE-E CDSA-AES256-GCM-SHA384 (256/256 bits) Apr 13 13:08:18 venus auth[12195]: pam_unix(dovecot:auth): Couldn't open /etc/secure tty: No such file or directory Apr 13 13:08:18 venus auth[12195]: pam_unix(dovecot:auth): Couldn't open /etc/secure tty: No such file or directory Apr 13 13:08:18 venus dovecot[10588]: imap-login: Login: user=, method=PLAIN, rip=192.168.123.1, lip=192.168.123.188, mpid=12202, TLS, TLSv1.2 with cipher ECDHE-E CDSA-AES256-GCM-SHA384 (256/256 bits) It seems that pam_unix still needs /etc/securetty, but login no longer provides it. There was a similar bug in debian that seems to be related: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931899 To my understanding, this is a problem between pam and login packages in 20.04. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1872443/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1872443] [NEW] /etc/securetty missing: dovecot not working
Public bug reported: With Ubuntu 20.04 Focal Fossa, /etc/securetty is missing from the "login" package (4.8.1-1ubuntu4). This leads to errors such as in /var/log/mail.log when a dovecot auth is tried: Apr 13 13:08:17 venus dovecot[10588]: imap-login: Login: user=, method=PLAIN, rip=192.168.123.1, lip=192.168.123.188, mpid=12200, TLS, TLSv1.2 with cipher ECDHE-E CDSA-AES256-GCM-SHA384 (256/256 bits) Apr 13 13:08:18 venus auth[12195]: pam_unix(dovecot:auth): Couldn't open /etc/secure tty: No such file or directory Apr 13 13:08:18 venus auth[12195]: pam_unix(dovecot:auth): Couldn't open /etc/secure tty: No such file or directory Apr 13 13:08:18 venus dovecot[10588]: imap-login: Login: user=, method=PLAIN, rip=192.168.123.1, lip=192.168.123.188, mpid=12202, TLS, TLSv1.2 with cipher ECDHE-E CDSA-AES256-GCM-SHA384 (256/256 bits) It seems that pam_unix still needs /etc/securetty, but login no longer provides it. There was a similar bug in debian that seems to be related: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931899 To my understanding, this is a problem between pam and login packages in 20.04. ** Affects: shadow (Ubuntu) Importance: Undecided Status: New ** Tags: dovecot login pam securetty -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to shadow in Ubuntu. https://bugs.launchpad.net/bugs/1872443 Title: /etc/securetty missing: dovecot not working Status in shadow package in Ubuntu: New Bug description: With Ubuntu 20.04 Focal Fossa, /etc/securetty is missing from the "login" package (4.8.1-1ubuntu4). This leads to errors such as in /var/log/mail.log when a dovecot auth is tried: Apr 13 13:08:17 venus dovecot[10588]: imap-login: Login: user=, method=PLAIN, rip=192.168.123.1, lip=192.168.123.188, mpid=12200, TLS, TLSv1.2 with cipher ECDHE-E CDSA-AES256-GCM-SHA384 (256/256 bits) Apr 13 13:08:18 venus auth[12195]: pam_unix(dovecot:auth): Couldn't open /etc/secure tty: No such file or directory Apr 13 13:08:18 venus auth[12195]: pam_unix(dovecot:auth): Couldn't open /etc/secure tty: No such file or directory Apr 13 13:08:18 venus dovecot[10588]: imap-login: Login: user=, method=PLAIN, rip=192.168.123.1, lip=192.168.123.188, mpid=12202, TLS, TLSv1.2 with cipher ECDHE-E CDSA-AES256-GCM-SHA384 (256/256 bits) It seems that pam_unix still needs /etc/securetty, but login no longer provides it. There was a similar bug in debian that seems to be related: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931899 To my understanding, this is a problem between pam and login packages in 20.04. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1872443/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1867784] Re: "systemctl status ..." in Focal does not show any process output
Never mind. My fault. The journal was gone, so nothing could be shown. ** Changed in: systemd (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1867784 Title: "systemctl status ..." in Focal does not show any process output Status in systemd package in Ubuntu: Invalid Bug description: Software versions: # lsb_release -rd Description:Ubuntu Focal Fossa (development branch) Release:20.04 # apt-cache policy systemd systemd: Installed: 244.3-1ubuntu1 Candidate: 244.3-1ubuntu1 Version table: *** 244.3-1ubuntu1 500 500 http://de.archive.ubuntu.com/ubuntu focal/main amd64 Packages 100 /var/lib/dpkg/status When I issue "systemctl status apache2" (or for any other service for that matter) in Focal, the last few lines of output are not shown any more: # systemctl status apache2 ● apache2.service - The Apache HTTP Server Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor prese> Drop-In: /etc/systemd/system/apache2.service.d └─override.conf Active: active (running) since Tue 2020-03-17 13:34:42 CET; 1h 43min ago Docs: https://httpd.apache.org/docs/2.4/ Main PID: 283994 (apache2) Tasks: 55 (limit: 9451) Memory: 27.3M CGroup: /system.slice/apache2.service ├─283994 /usr/sbin/apache2 -k start ├─283997 /usr/sbin/apache2 -k start └─283998 /usr/sbin/apache2 -k start # With Bionic (18.04), the last few log lines were shown as described in the systemctl man page: #systemctl status apache2 ● apache2.service - The Apache HTTP Server Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: enab Drop-In: /lib/systemd/system/apache2.service.d └─apache2-systemd.conf /etc/systemd/system/apache2.service.d └─override.conf Active: active (running) since Tue 2020-03-03 23:01:13 CET; 1 weeks 6 days ago Process: 1255 ExecReload=/usr/sbin/apachectl graceful (code=exited, status=0/SUCCE Main PID: 11522 (/usr/sbin/apach) Tasks: 15 (limit: 4915) CGroup: /system.slice/apache2.service ├─ 1280 /usr/sbin/apache2 -k start ├─ 6459 /usr/sbin/apache2 -k start └─11522 /usr/sbin/apache2 -k start Mar 13 06:25:27 fatty.xy.de systemd[1]: Reloading The Apache HTTP Server. Mar 13 06:25:27 fatty.xy.de systemd[1]: Reloaded The Apache HTTP Server. Mar 14 06:25:27 fatty.xy.de systemd[1]: Reloading The Apache HTTP Server. Mar 14 06:25:27 fatty.xy.de systemd[1]: Reloaded The Apache HTTP Server. Mar 15 06:25:27 fatty.xy.de systemd[1]: Reloading The Apache HTTP Server. Mar 15 06:25:27 fatty.xy.de systemd[1]: Reloaded The Apache HTTP Server. Mar 16 06:25:28 fatty.xy.de systemd[1]: Reloading The Apache HTTP Server. Mar 16 06:25:28 fatty.xy.de systemd[1]: Reloaded The Apache HTTP Server. Mar 17 06:25:27 fatty.xy.de systemd[1]: Reloading The Apache HTTP Server. Mar 17 06:25:27 fatty.xy.de systemd[1]: Reloaded The Apache HTTP Server. # I do not know if this was an upstream systemd change, however it seems wrong. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1867784/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1867784] [NEW] "systemctl status ..." in Focal does not show any process output
Public bug reported: Software versions: # lsb_release -rd Description:Ubuntu Focal Fossa (development branch) Release:20.04 # apt-cache policy systemd systemd: Installed: 244.3-1ubuntu1 Candidate: 244.3-1ubuntu1 Version table: *** 244.3-1ubuntu1 500 500 http://de.archive.ubuntu.com/ubuntu focal/main amd64 Packages 100 /var/lib/dpkg/status When I issue "systemctl status apache2" (or for any other service for that matter) in Focal, the last few lines of output are not shown any more: # systemctl status apache2 ● apache2.service - The Apache HTTP Server Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor prese> Drop-In: /etc/systemd/system/apache2.service.d └─override.conf Active: active (running) since Tue 2020-03-17 13:34:42 CET; 1h 43min ago Docs: https://httpd.apache.org/docs/2.4/ Main PID: 283994 (apache2) Tasks: 55 (limit: 9451) Memory: 27.3M CGroup: /system.slice/apache2.service ├─283994 /usr/sbin/apache2 -k start ├─283997 /usr/sbin/apache2 -k start └─283998 /usr/sbin/apache2 -k start # With Bionic (18.04), the last few log lines were shown as described in the systemctl man page: #systemctl status apache2 ● apache2.service - The Apache HTTP Server Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: enab Drop-In: /lib/systemd/system/apache2.service.d └─apache2-systemd.conf /etc/systemd/system/apache2.service.d └─override.conf Active: active (running) since Tue 2020-03-03 23:01:13 CET; 1 weeks 6 days ago Process: 1255 ExecReload=/usr/sbin/apachectl graceful (code=exited, status=0/SUCCE Main PID: 11522 (/usr/sbin/apach) Tasks: 15 (limit: 4915) CGroup: /system.slice/apache2.service ├─ 1280 /usr/sbin/apache2 -k start ├─ 6459 /usr/sbin/apache2 -k start └─11522 /usr/sbin/apache2 -k start Mar 13 06:25:27 fatty.xy.de systemd[1]: Reloading The Apache HTTP Server. Mar 13 06:25:27 fatty.xy.de systemd[1]: Reloaded The Apache HTTP Server. Mar 14 06:25:27 fatty.xy.de systemd[1]: Reloading The Apache HTTP Server. Mar 14 06:25:27 fatty.xy.de systemd[1]: Reloaded The Apache HTTP Server. Mar 15 06:25:27 fatty.xy.de systemd[1]: Reloading The Apache HTTP Server. Mar 15 06:25:27 fatty.xy.de systemd[1]: Reloaded The Apache HTTP Server. Mar 16 06:25:28 fatty.xy.de systemd[1]: Reloading The Apache HTTP Server. Mar 16 06:25:28 fatty.xy.de systemd[1]: Reloaded The Apache HTTP Server. Mar 17 06:25:27 fatty.xy.de systemd[1]: Reloading The Apache HTTP Server. Mar 17 06:25:27 fatty.xy.de systemd[1]: Reloaded The Apache HTTP Server. # I do not know if this was an upstream systemd change, however it seems wrong. ** Affects: systemd (Ubuntu) Importance: Undecided Status: New ** Tags: focal status systemd -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1867784 Title: "systemctl status ..." in Focal does not show any process output Status in systemd package in Ubuntu: New Bug description: Software versions: # lsb_release -rd Description:Ubuntu Focal Fossa (development branch) Release:20.04 # apt-cache policy systemd systemd: Installed: 244.3-1ubuntu1 Candidate: 244.3-1ubuntu1 Version table: *** 244.3-1ubuntu1 500 500 http://de.archive.ubuntu.com/ubuntu focal/main amd64 Packages 100 /var/lib/dpkg/status When I issue "systemctl status apache2" (or for any other service for that matter) in Focal, the last few lines of output are not shown any more: # systemctl status apache2 ● apache2.service - The Apache HTTP Server Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor prese> Drop-In: /etc/systemd/system/apache2.service.d └─override.conf Active: active (running) since Tue 2020-03-17 13:34:42 CET; 1h 43min ago Docs: https://httpd.apache.org/docs/2.4/ Main PID: 283994 (apache2) Tasks: 55 (limit: 9451) Memory: 27.3M CGroup: /system.slice/apache2.service ├─283994 /usr/sbin/apache2 -k start ├─283997 /usr/sbin/apache2 -k start └─283998 /usr/sbin/apache2 -k start # With Bionic (18.04), the last few log lines were shown as described in the systemctl man page: #systemctl status apache2 ● apache2.service - The Apache HTTP Server Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: enab Drop-In: /lib/systemd/system/apache2.service.d └─apache2-systemd.conf /etc/systemd/system/apache2.service.d └─override.conf Active: active (running) since Tue 2020-03-03 23:01:13 CET; 1 weeks 6 days ago Process: 1255 ExecReload=/usr/sbin/apachectl graceful
[Touch-packages] [Bug 1865204] Re: Multiple packages broke with openssl 1.1.1 upgrade
** Description changed: While I welcome the adding of security features by upgrading vital packages like openssl, there are at least two packages that I know of which ran fine with libssl 1.1.0 and do not with libssl 1.1.1. This bug has been introduced with the migration from openssl 1.1.0 to 1.1.1 in one of the last point releases. - 1. stunnel4 3:5.44-1ubuntu3 stunnel4 breaks with openssl 1.1.1 (which supports TLS 1.3). I get errors when a Windows stunnel client connects to the stunnel4 daemon: Feb 20 14:10:03 peterpan.neverland stunnel[24427]: LOG3[0]: s_connect: connect ::1:3128 : Connection refused (111) This can be fixed when I manually add "MaxProtocol = TLSv1.2" to /etc/ssl/openssl.conf, showing that TLS 1.3 introduced by openssl 1.1.1 is the culprit. stunnel4 needs an update. At least for stunnel4, another fix would be to specify "sslVersion = TLSv1.2" in its config file. - 2. pure-ftpd 1.0.46-1build1 Same thing here. You cannot connect once you use "tls=2" or higher if openssl 1.1.1 with TLS 1.3 is active. Only fix here I found is to limit - the max protocol. pure-ftpd itself has no means of solving that problem, - at least not in the bionic version. + the max protocol in openssl for all applications. pure-ftpd itself has + no means of controlling the TLS version, at least not in the bionic + version of it. + + I use Ubuntu Server 18.04.04 LTS, BTW and openssl was + 1.1.1-1ubuntu2.1~18.04.5. - I use Ubuntu Server 18.04.04 LTS, BTW and openssl was 1.1.1-1ubuntu2.1~18.04.5. + Both problems could be fixed by backporting stunnel4 and pure-ftpd packages from Focal Fossa. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1865204 Title: Multiple packages broke with openssl 1.1.1 upgrade Status in openssl package in Ubuntu: New Bug description: While I welcome the adding of security features by upgrading vital packages like openssl, there are at least two packages that I know of which ran fine with libssl 1.1.0 and do not with libssl 1.1.1. This bug has been introduced with the migration from openssl 1.1.0 to 1.1.1 in one of the last point releases. 1. stunnel4 3:5.44-1ubuntu3 stunnel4 breaks with openssl 1.1.1 (which supports TLS 1.3). I get errors when a Windows stunnel client connects to the stunnel4 daemon: Feb 20 14:10:03 peterpan.neverland stunnel[24427]: LOG3[0]: s_connect: connect ::1:3128 : Connection refused (111) This can be fixed when I manually add "MaxProtocol = TLSv1.2" to /etc/ssl/openssl.conf, showing that TLS 1.3 introduced by openssl 1.1.1 is the culprit. stunnel4 needs an update. At least for stunnel4, another fix would be to specify "sslVersion = TLSv1.2" in its config file. 2. pure-ftpd 1.0.46-1build1 Same thing here. You cannot connect once you use "tls=2" or higher if openssl 1.1.1 with TLS 1.3 is active. Only fix here I found is to limit the max protocol in openssl for all applications. pure-ftpd itself has no means of controlling the TLS version, at least not in the bionic version of it. I use Ubuntu Server 18.04.04 LTS, BTW and openssl was 1.1.1-1ubuntu2.1~18.04.5. Both problems could be fixed by backporting stunnel4 and pure-ftpd packages from Focal Fossa. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1865204/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1865204] [NEW] Multiple packages broke with openssl 1.1.1 upgrade
Public bug reported: While I welcome the adding of security features by upgrading vital packages like openssl, there are at least two packages that I know of which ran fine with libssl 1.1.0 and do not with libssl 1.1.1. This bug has been introduced with the migration from openssl 1.1.0 to 1.1.1 in one of the last point releases. 1. stunnel4 3:5.44-1ubuntu3 stunnel4 breaks with openssl 1.1.1 (which supports TLS 1.3). I get errors when a Windows stunnel client connects to the stunnel4 daemon: Feb 20 14:10:03 peterpan.neverland stunnel[24427]: LOG3[0]: s_connect: connect ::1:3128 : Connection refused (111) This can be fixed when I manually add "MaxProtocol = TLSv1.2" to /etc/ssl/openssl.conf, showing that TLS 1.3 introduced by openssl 1.1.1 is the culprit. stunnel4 needs an update. At least for stunnel4, another fix would be to specify "sslVersion = TLSv1.2" in its config file. 2. pure-ftpd 1.0.46-1build1 Same thing here. You cannot connect once you use "tls=2" or higher if openssl 1.1.1 with TLS 1.3 is active. Only fix here I found is to limit the max protocol. pure-ftpd itself has no means of solving that problem, at least not in the bionic version. I use Ubuntu Server 18.04.04 LTS, BTW and openssl was 1.1.1-1ubuntu2.1~18.04.5. ** Affects: openssl (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1865204 Title: Multiple packages broke with openssl 1.1.1 upgrade Status in openssl package in Ubuntu: New Bug description: While I welcome the adding of security features by upgrading vital packages like openssl, there are at least two packages that I know of which ran fine with libssl 1.1.0 and do not with libssl 1.1.1. This bug has been introduced with the migration from openssl 1.1.0 to 1.1.1 in one of the last point releases. 1. stunnel4 3:5.44-1ubuntu3 stunnel4 breaks with openssl 1.1.1 (which supports TLS 1.3). I get errors when a Windows stunnel client connects to the stunnel4 daemon: Feb 20 14:10:03 peterpan.neverland stunnel[24427]: LOG3[0]: s_connect: connect ::1:3128 : Connection refused (111) This can be fixed when I manually add "MaxProtocol = TLSv1.2" to /etc/ssl/openssl.conf, showing that TLS 1.3 introduced by openssl 1.1.1 is the culprit. stunnel4 needs an update. At least for stunnel4, another fix would be to specify "sslVersion = TLSv1.2" in its config file. 2. pure-ftpd 1.0.46-1build1 Same thing here. You cannot connect once you use "tls=2" or higher if openssl 1.1.1 with TLS 1.3 is active. Only fix here I found is to limit the max protocol. pure-ftpd itself has no means of solving that problem, at least not in the bionic version. I use Ubuntu Server 18.04.04 LTS, BTW and openssl was 1.1.1-1ubuntu2.1~18.04.5. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1865204/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1797386] Re: [SRU] OpenSSL 1.1.1 to 18.04 LTS
Hi, good idea in theory, but I want to add my 2cents: Please coordinate this update with ALL affected packages, like apache2 and nginx. My reason is: I just tried the PPA and found that nginx works with TLS 1.3 after that right out of the box. HOWEVER, there is a problem: openssl 1.1.1 has changed the way the cipher suites are configured - the ones for TLS 1.3 are configured separately, see here: https://github.com/openssl/openssl/commit/f865b08143b453962ad4afccd69e698d13c60f77 Nginx on the other hand has chosen to not support that new configuration at all, see: https://trac.nginx.org/nginx/ticket/1529 That means that the predefined order of TLS 1.3 is: TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256 and cannot be changed - it took me hours to find that out since the Nginx 1.15 documentation does not tell you that the TLS 1.3 ciphers cannot be changed by ssl_ciphers, but are silently ignored. The default set and order of ciphersuites may suit your needs or not - matter-of-fact it makes my SSLLabs score worse because of the AES128 cipher used. I have tried to apply othe defaults in /etc/ssl/openssl.conf but they do not seem to work for nginx. Neither could I just disable TLS 1.3 in order to restore the old behaviour other than to restore OpenSSL 1.1.0 by using "ppa-purge ppa:ci-train-ppa- service/3473". King regards, Uwe ** Bug watch added: trac.nginx.org/nginx/ #1529 http://trac.nginx.org/nginx/ticket/1529 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1797386 Title: [SRU] OpenSSL 1.1.1 to 18.04 LTS Status in openssl package in Ubuntu: In Progress Status in libio-socket-ssl-perl source package in Bionic: New Status in libnet-ssleay-perl source package in Bionic: New Status in nova source package in Bionic: New Status in openssl source package in Bionic: New Status in python-cryptography source package in Bionic: New Status in python2.7 source package in Bionic: New Status in python3.6 source package in Bionic: New Status in python3.7 source package in Bionic: New Status in r-cran-openssl source package in Bionic: Fix Committed Status in ruby-openssl source package in Bionic: Fix Committed Status in ruby2.5 source package in Bionic: New Bug description: [Impact] * OpenSSL 1.1.1 is an LTS release upstream, which will continue to receive security support for much longer than 1.1.0 series will. * OpenSSL 1.1.1 comes with support for TLS v1.3 which is expected to be rapidly adopted due to increased set of supported hashes & algoes, as well as improved handshake [re-]negotiation. * OpenSSL 1.1.1 comes with improved hw-acceleration capabilities. * OpenSSL 1.1.1 is ABI/API compatible with 1.1.0, however some software is sensitive to the negotiation handshake and may either need patches/improvements or clamp-down to maximum v1.2. [Test Case] * Rebuild all reverse dependencies * Execute autopkg tests for all of them * Clamp down to TLS v1.2 software that does not support TLS v1.3 (e.g. mongodb) * Backport TLS v1.3 support patches, where applicable [Regression Potential] * Connectivity interop is the biggest issues which will be unavoidable with introducing TLS v1.3. However, tests on cosmic demonstrate that curl/nginx/google-chrome/mozilla-firefox connect and negotiate TLS v1.3 without issues. * Mitigation of discovered connectivity issues will be possible by clamping down to TLS v1.2 in either server-side or client-side software or by backporting relevant support fixes * Notable changes are listed here https://wiki.openssl.org/index.php/TLS1.3 * Most common connectivity issues so far: - client verifies SNI in TLSv1.3 mode, yet client doesn't set hostname. Solution is client change to set hostname, or to clamp down the client to TLSv1.2. - session negotiation is different in TLSv1.3, existing client code may fail to create/negotiate/resume session. Clients need to learn how to use session callback. * This update bundles python 3.6 and 3.7 point releases [Other Info] * Previous FFe for OpenSSL in 18.10 is at https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1793092 * TLS v1.3 support in NSS is expected to make it to 18.04 via security updates * TLS v1.3 support in GnuTLS is expected to be available in 19.04 * Test OpenSSL is being prepared in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3473 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1797386/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
