[Touch-packages] [Bug 1709193] Re: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer
** No longer affects: ssmtp (Ubuntu Trusty) ** No longer affects: ssmtp (Ubuntu Xenial) ** No longer affects: ssmtp (Ubuntu Zesty) ** No longer affects: ssmtp (Ubuntu Artful) ** No longer affects: gnutls26 (Ubuntu Xenial) ** No longer affects: gnutls26 (Ubuntu Zesty) ** No longer affects: gnutls26 (Ubuntu Artful) ** No longer affects: gnutls26 (Ubuntu) ** Changed in: gnutls26 (Ubuntu Trusty) Importance: Undecided => Medium ** Changed in: gnutls28 (Ubuntu Trusty) Importance: Undecided => Medium ** Changed in: gnutls28 (Ubuntu Xenial) Importance: Undecided => Medium ** Changed in: gnutls28 (Ubuntu Zesty) Importance: Undecided => Medium ** Changed in: gnutls28 (Ubuntu Artful) Importance: Undecided => Medium -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gnutls26 in Ubuntu. https://bugs.launchpad.net/bugs/1709193 Title: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer Status in gnutls28 package in Ubuntu: Fix Released Status in gnutls26 source package in Trusty: Fix Committed Status in gnutls28 source package in Trusty: Won't Fix Status in gnutls28 source package in Xenial: Fix Committed Status in gnutls28 source package in Zesty: Fix Released Status in gnutls28 source package in Artful: Fix Released Status in gnutls28 package in Debian: Fix Released Bug description: [Impact] Applications using GnuTLS OpenSSL compat layer [1] are be unable to use modern TLS versions (1.1 and 1.2) when relying on the SSLv23_{client,server}_method functions. There is an industry-wide push to use modern TLS versions, see [2] and [3] for example. The proposed fix changes the compat layer to use GnuTLS' "NORMAL" priority [4] instead of hard-coding which protocol versions and ciphers to enable. [Test Case] 1) Setup a mail submission server that uses StartTLS 2) Setup sSMTP (uses GnuTLS OpenSSL compat layer) to relay through the mail relay using StartTLS 3) Send an email while capturing with tcpdump/tshark 4) Inspect the submission connection (TCP/587) and look for the protocol version negotiated by the client. Without the fix, you should see TLSv1.0. With the fix, it should be TLSv1.2. Please see the original issue description for more details. [Regression Potential] Regression risk should be low since it's a backport of a simple fix that landed in Debian in April 2017. [References] 1: $ apt-cache rdepends libgnutls-openssl27 libgnutls-openssl27 Reverse Depends: libgnutls-dev libgnutls-dev zoneminder yaskkserv tf5 ssmtp snowdrop sngrep slrnpull slrn sipsak macopix-gtk2 gnss-sdr gkrellm freewheeling boinctui iputils-ping 2: https://lists.debian.org/debian-devel-announce/2017/08/msg4.html 3: https://blog.pcisecuritystandards.org/migrating-from-ssl-and-early-tls 4: https://gnutls.org/manual/html_node/Priority-Strings.html [Original issue description] sSMTP is limited to using TLSv1.0 and the "old" ciphers that come with it. Here's a packet capture when ssmtp connects to smtp.sdeziel.info:587 that offers TLSv1.0 and higher: $ tshark -ta -Vr submission.pcap | sed -n '/^Frame 14:/,/^Frame 15:/ p' | grep -E '^[[:space:]]+(Version|Cipher|Handshake Protocol)' Version: TLS 1.0 (0x0301) Handshake Protocol: Client Hello Version: TLS 1.0 (0x0301) Cipher Suites Length: 30 Cipher Suites (15 suites) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) Cipher Suite: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0041) Cipher Suite: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0084) Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039) Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0045) Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0088) Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016) Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032) Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038) Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA (0x0044) Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA (0x0087) Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013) I would expect ssmtp to use TLSv1.2 and a recent cipher like the openssl s_client is able to do: $ echo | openssl s_client -connect smtp.sdeziel.info:587 -starttls smtp 2>/dev/null | grep -E '^[[:space:]]+(Protocol|Cipher)' Protocol : TLSv1.2 Cipher:
[Touch-packages] [Bug 1709193] Re: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer
I agree with juliank's assessment in comment #22. The 2nd Trusty debdiff allows md5 to be used throughout the entire cert chain which is apparently not what Simon intended. I don't think it is the right approach. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gnutls26 in Ubuntu. https://bugs.launchpad.net/bugs/1709193 Title: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer Status in gnutls26 package in Ubuntu: Invalid Status in gnutls28 package in Ubuntu: Fix Released Status in gnutls26 source package in Trusty: Fix Committed Status in gnutls28 source package in Trusty: Won't Fix Status in ssmtp source package in Trusty: Invalid Status in gnutls26 source package in Xenial: Invalid Status in gnutls28 source package in Xenial: Fix Committed Status in ssmtp source package in Xenial: Invalid Status in gnutls26 source package in Zesty: Invalid Status in gnutls28 source package in Zesty: Fix Released Status in ssmtp source package in Zesty: Invalid Status in gnutls26 source package in Artful: Invalid Status in gnutls28 source package in Artful: Fix Released Status in ssmtp source package in Artful: Invalid Status in gnutls28 package in Debian: Fix Released Bug description: [Impact] Applications using GnuTLS OpenSSL compat layer [1] are be unable to use modern TLS versions (1.1 and 1.2) when relying on the SSLv23_{client,server}_method functions. There is an industry-wide push to use modern TLS versions, see [2] and [3] for example. The proposed fix changes the compat layer to use GnuTLS' "NORMAL" priority [4] instead of hard-coding which protocol versions and ciphers to enable. [Test Case] 1) Setup a mail submission server that uses StartTLS 2) Setup sSMTP (uses GnuTLS OpenSSL compat layer) to relay through the mail relay using StartTLS 3) Send an email while capturing with tcpdump/tshark 4) Inspect the submission connection (TCP/587) and look for the protocol version negotiated by the client. Without the fix, you should see TLSv1.0. With the fix, it should be TLSv1.2. Please see the original issue description for more details. [Regression Potential] Regression risk should be low since it's a backport of a simple fix that landed in Debian in April 2017. [References] 1: $ apt-cache rdepends libgnutls-openssl27 libgnutls-openssl27 Reverse Depends: libgnutls-dev libgnutls-dev zoneminder yaskkserv tf5 ssmtp snowdrop sngrep slrnpull slrn sipsak macopix-gtk2 gnss-sdr gkrellm freewheeling boinctui iputils-ping 2: https://lists.debian.org/debian-devel-announce/2017/08/msg4.html 3: https://blog.pcisecuritystandards.org/migrating-from-ssl-and-early-tls 4: https://gnutls.org/manual/html_node/Priority-Strings.html [Original issue description] sSMTP is limited to using TLSv1.0 and the "old" ciphers that come with it. Here's a packet capture when ssmtp connects to smtp.sdeziel.info:587 that offers TLSv1.0 and higher: $ tshark -ta -Vr submission.pcap | sed -n '/^Frame 14:/,/^Frame 15:/ p' | grep -E '^[[:space:]]+(Version|Cipher|Handshake Protocol)' Version: TLS 1.0 (0x0301) Handshake Protocol: Client Hello Version: TLS 1.0 (0x0301) Cipher Suites Length: 30 Cipher Suites (15 suites) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) Cipher Suite: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0041) Cipher Suite: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0084) Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039) Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0045) Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0088) Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016) Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032) Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038) Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA (0x0044) Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA (0x0087) Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013) I would expect ssmtp to use TLSv1.2 and a recent cipher like the openssl s_client is able to do: $ echo | openssl s_client -connect smtp.sdeziel.info:587 -starttls smtp 2>/dev/null | grep -E '^[[:space:]]+(Protocol|Cipher)' Protocol : TLSv1.2 Cipher: ECDHE-RSA-AES128-GCM-SHA256 Additional information: $ lsb_release -rd Description: Ubuntu 16.04.3 LTS Release: 16.04
[Touch-packages] [Bug 1709193] Re: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer
I see the NM one passes now, thanks for retrying it. The aria2 armhf problem reliably fails though. I guess I'll have to setup a QEMU VM for that arch and manually run the test to see what's going on. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gnutls26 in Ubuntu. https://bugs.launchpad.net/bugs/1709193 Title: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer Status in gnutls26 package in Ubuntu: Invalid Status in gnutls28 package in Ubuntu: Fix Released Status in gnutls26 source package in Trusty: Fix Committed Status in gnutls28 source package in Trusty: Won't Fix Status in ssmtp source package in Trusty: Invalid Status in gnutls26 source package in Xenial: Invalid Status in gnutls28 source package in Xenial: Fix Committed Status in ssmtp source package in Xenial: Invalid Status in gnutls26 source package in Zesty: Invalid Status in gnutls28 source package in Zesty: Fix Released Status in ssmtp source package in Zesty: Invalid Status in gnutls26 source package in Artful: Invalid Status in gnutls28 source package in Artful: Fix Released Status in ssmtp source package in Artful: Invalid Status in gnutls28 package in Debian: Fix Released Bug description: [Impact] Applications using GnuTLS OpenSSL compat layer [1] are be unable to use modern TLS versions (1.1 and 1.2) when relying on the SSLv23_{client,server}_method functions. There is an industry-wide push to use modern TLS versions, see [2] and [3] for example. The proposed fix changes the compat layer to use GnuTLS' "NORMAL" priority [4] instead of hard-coding which protocol versions and ciphers to enable. [Test Case] 1) Setup a mail submission server that uses StartTLS 2) Setup sSMTP (uses GnuTLS OpenSSL compat layer) to relay through the mail relay using StartTLS 3) Send an email while capturing with tcpdump/tshark 4) Inspect the submission connection (TCP/587) and look for the protocol version negotiated by the client. Without the fix, you should see TLSv1.0. With the fix, it should be TLSv1.2. Please see the original issue description for more details. [Regression Potential] Regression risk should be low since it's a backport of a simple fix that landed in Debian in April 2017. [References] 1: $ apt-cache rdepends libgnutls-openssl27 libgnutls-openssl27 Reverse Depends: libgnutls-dev libgnutls-dev zoneminder yaskkserv tf5 ssmtp snowdrop sngrep slrnpull slrn sipsak macopix-gtk2 gnss-sdr gkrellm freewheeling boinctui iputils-ping 2: https://lists.debian.org/debian-devel-announce/2017/08/msg4.html 3: https://blog.pcisecuritystandards.org/migrating-from-ssl-and-early-tls 4: https://gnutls.org/manual/html_node/Priority-Strings.html [Original issue description] sSMTP is limited to using TLSv1.0 and the "old" ciphers that come with it. Here's a packet capture when ssmtp connects to smtp.sdeziel.info:587 that offers TLSv1.0 and higher: $ tshark -ta -Vr submission.pcap | sed -n '/^Frame 14:/,/^Frame 15:/ p' | grep -E '^[[:space:]]+(Version|Cipher|Handshake Protocol)' Version: TLS 1.0 (0x0301) Handshake Protocol: Client Hello Version: TLS 1.0 (0x0301) Cipher Suites Length: 30 Cipher Suites (15 suites) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) Cipher Suite: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0041) Cipher Suite: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0084) Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039) Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0045) Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0088) Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016) Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032) Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038) Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA (0x0044) Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA (0x0087) Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013) I would expect ssmtp to use TLSv1.2 and a recent cipher like the openssl s_client is able to do: $ echo | openssl s_client -connect smtp.sdeziel.info:587 -starttls smtp 2>/dev/null | grep -E '^[[:space:]]+(Protocol|Cipher)' Protocol : TLSv1.2 Cipher: ECDHE-RSA-AES128-GCM-SHA256 Additional information: $ lsb_release -rd Description: Ubuntu 16.04.3 LTS Release: 16.04 $ apt-cache
[Touch-packages] [Bug 1709193] Re: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer
If you look at http://people.canonical.com/~ubuntu-archive/proposed- migration/xenial/update_excuses.html#gnutls28 you'll see that aria2 failed on armhf, and network-manager on amd64. network-manager looks like a temporary failure, I just retried that; and aria2 - well, it fails to read CA certificates, I'm not sure why, but that seems unrelated too. I just retried it, maybe it works now; but maybe it's a bug in aria2 missing a test dependency. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gnutls26 in Ubuntu. https://bugs.launchpad.net/bugs/1709193 Title: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer Status in gnutls26 package in Ubuntu: Invalid Status in gnutls28 package in Ubuntu: Fix Released Status in gnutls26 source package in Trusty: Fix Committed Status in gnutls28 source package in Trusty: Won't Fix Status in ssmtp source package in Trusty: Invalid Status in gnutls26 source package in Xenial: Invalid Status in gnutls28 source package in Xenial: Fix Committed Status in ssmtp source package in Xenial: Invalid Status in gnutls26 source package in Zesty: Invalid Status in gnutls28 source package in Zesty: Fix Released Status in ssmtp source package in Zesty: Invalid Status in gnutls26 source package in Artful: Invalid Status in gnutls28 source package in Artful: Fix Released Status in ssmtp source package in Artful: Invalid Status in gnutls28 package in Debian: Fix Released Bug description: [Impact] Applications using GnuTLS OpenSSL compat layer [1] are be unable to use modern TLS versions (1.1 and 1.2) when relying on the SSLv23_{client,server}_method functions. There is an industry-wide push to use modern TLS versions, see [2] and [3] for example. The proposed fix changes the compat layer to use GnuTLS' "NORMAL" priority [4] instead of hard-coding which protocol versions and ciphers to enable. [Test Case] 1) Setup a mail submission server that uses StartTLS 2) Setup sSMTP (uses GnuTLS OpenSSL compat layer) to relay through the mail relay using StartTLS 3) Send an email while capturing with tcpdump/tshark 4) Inspect the submission connection (TCP/587) and look for the protocol version negotiated by the client. Without the fix, you should see TLSv1.0. With the fix, it should be TLSv1.2. Please see the original issue description for more details. [Regression Potential] Regression risk should be low since it's a backport of a simple fix that landed in Debian in April 2017. [References] 1: $ apt-cache rdepends libgnutls-openssl27 libgnutls-openssl27 Reverse Depends: libgnutls-dev libgnutls-dev zoneminder yaskkserv tf5 ssmtp snowdrop sngrep slrnpull slrn sipsak macopix-gtk2 gnss-sdr gkrellm freewheeling boinctui iputils-ping 2: https://lists.debian.org/debian-devel-announce/2017/08/msg4.html 3: https://blog.pcisecuritystandards.org/migrating-from-ssl-and-early-tls 4: https://gnutls.org/manual/html_node/Priority-Strings.html [Original issue description] sSMTP is limited to using TLSv1.0 and the "old" ciphers that come with it. Here's a packet capture when ssmtp connects to smtp.sdeziel.info:587 that offers TLSv1.0 and higher: $ tshark -ta -Vr submission.pcap | sed -n '/^Frame 14:/,/^Frame 15:/ p' | grep -E '^[[:space:]]+(Version|Cipher|Handshake Protocol)' Version: TLS 1.0 (0x0301) Handshake Protocol: Client Hello Version: TLS 1.0 (0x0301) Cipher Suites Length: 30 Cipher Suites (15 suites) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) Cipher Suite: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0041) Cipher Suite: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0084) Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039) Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0045) Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0088) Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016) Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032) Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038) Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA (0x0044) Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA (0x0087) Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013) I would expect ssmtp to use TLSv1.2 and a recent cipher like the openssl s_client is able to do: $ echo | openssl s_client -connect smtp.sdeziel.info:587 -starttls
[Touch-packages] [Bug 1709193] Re: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer
You can also look at http://people.canonical.com/~ubuntu-archive /pending-sru.html of course, that lists all SRUs in any -proposed suite and mention regressions in autopkgtest in the left column. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gnutls26 in Ubuntu. https://bugs.launchpad.net/bugs/1709193 Title: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer Status in gnutls26 package in Ubuntu: Invalid Status in gnutls28 package in Ubuntu: Fix Released Status in gnutls26 source package in Trusty: Fix Committed Status in gnutls28 source package in Trusty: Won't Fix Status in ssmtp source package in Trusty: Invalid Status in gnutls26 source package in Xenial: Invalid Status in gnutls28 source package in Xenial: Fix Committed Status in ssmtp source package in Xenial: Invalid Status in gnutls26 source package in Zesty: Invalid Status in gnutls28 source package in Zesty: Fix Released Status in ssmtp source package in Zesty: Invalid Status in gnutls26 source package in Artful: Invalid Status in gnutls28 source package in Artful: Fix Released Status in ssmtp source package in Artful: Invalid Status in gnutls28 package in Debian: Fix Released Bug description: [Impact] Applications using GnuTLS OpenSSL compat layer [1] are be unable to use modern TLS versions (1.1 and 1.2) when relying on the SSLv23_{client,server}_method functions. There is an industry-wide push to use modern TLS versions, see [2] and [3] for example. The proposed fix changes the compat layer to use GnuTLS' "NORMAL" priority [4] instead of hard-coding which protocol versions and ciphers to enable. [Test Case] 1) Setup a mail submission server that uses StartTLS 2) Setup sSMTP (uses GnuTLS OpenSSL compat layer) to relay through the mail relay using StartTLS 3) Send an email while capturing with tcpdump/tshark 4) Inspect the submission connection (TCP/587) and look for the protocol version negotiated by the client. Without the fix, you should see TLSv1.0. With the fix, it should be TLSv1.2. Please see the original issue description for more details. [Regression Potential] Regression risk should be low since it's a backport of a simple fix that landed in Debian in April 2017. [References] 1: $ apt-cache rdepends libgnutls-openssl27 libgnutls-openssl27 Reverse Depends: libgnutls-dev libgnutls-dev zoneminder yaskkserv tf5 ssmtp snowdrop sngrep slrnpull slrn sipsak macopix-gtk2 gnss-sdr gkrellm freewheeling boinctui iputils-ping 2: https://lists.debian.org/debian-devel-announce/2017/08/msg4.html 3: https://blog.pcisecuritystandards.org/migrating-from-ssl-and-early-tls 4: https://gnutls.org/manual/html_node/Priority-Strings.html [Original issue description] sSMTP is limited to using TLSv1.0 and the "old" ciphers that come with it. Here's a packet capture when ssmtp connects to smtp.sdeziel.info:587 that offers TLSv1.0 and higher: $ tshark -ta -Vr submission.pcap | sed -n '/^Frame 14:/,/^Frame 15:/ p' | grep -E '^[[:space:]]+(Version|Cipher|Handshake Protocol)' Version: TLS 1.0 (0x0301) Handshake Protocol: Client Hello Version: TLS 1.0 (0x0301) Cipher Suites Length: 30 Cipher Suites (15 suites) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) Cipher Suite: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0041) Cipher Suite: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0084) Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039) Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0045) Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0088) Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016) Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032) Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038) Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA (0x0044) Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA (0x0087) Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013) I would expect ssmtp to use TLSv1.2 and a recent cipher like the openssl s_client is able to do: $ echo | openssl s_client -connect smtp.sdeziel.info:587 -starttls smtp 2>/dev/null | grep -E '^[[:space:]]+(Protocol|Cipher)' Protocol : TLSv1.2 Cipher: ECDHE-RSA-AES128-GCM-SHA256 Additional information: $ lsb_release -rd Description: Ubuntu 16.04.3 LTS Release: 16.04 $ apt-cache
[Touch-packages] [Bug 1709193] Re: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer
@juliank, thanks for the update. I wasn't aware of the autopkgtest failing for some reverse dependencies. Any pointers to those? I'm determined to see this one though, but on Monday ;) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gnutls26 in Ubuntu. https://bugs.launchpad.net/bugs/1709193 Title: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer Status in gnutls26 package in Ubuntu: Invalid Status in gnutls28 package in Ubuntu: Fix Released Status in gnutls26 source package in Trusty: Fix Committed Status in gnutls28 source package in Trusty: Won't Fix Status in ssmtp source package in Trusty: Invalid Status in gnutls26 source package in Xenial: Invalid Status in gnutls28 source package in Xenial: Fix Committed Status in ssmtp source package in Xenial: Invalid Status in gnutls26 source package in Zesty: Invalid Status in gnutls28 source package in Zesty: Fix Released Status in ssmtp source package in Zesty: Invalid Status in gnutls26 source package in Artful: Invalid Status in gnutls28 source package in Artful: Fix Released Status in ssmtp source package in Artful: Invalid Status in gnutls28 package in Debian: Fix Released Bug description: [Impact] Applications using GnuTLS OpenSSL compat layer [1] are be unable to use modern TLS versions (1.1 and 1.2) when relying on the SSLv23_{client,server}_method functions. There is an industry-wide push to use modern TLS versions, see [2] and [3] for example. The proposed fix changes the compat layer to use GnuTLS' "NORMAL" priority [4] instead of hard-coding which protocol versions and ciphers to enable. [Test Case] 1) Setup a mail submission server that uses StartTLS 2) Setup sSMTP (uses GnuTLS OpenSSL compat layer) to relay through the mail relay using StartTLS 3) Send an email while capturing with tcpdump/tshark 4) Inspect the submission connection (TCP/587) and look for the protocol version negotiated by the client. Without the fix, you should see TLSv1.0. With the fix, it should be TLSv1.2. Please see the original issue description for more details. [Regression Potential] Regression risk should be low since it's a backport of a simple fix that landed in Debian in April 2017. [References] 1: $ apt-cache rdepends libgnutls-openssl27 libgnutls-openssl27 Reverse Depends: libgnutls-dev libgnutls-dev zoneminder yaskkserv tf5 ssmtp snowdrop sngrep slrnpull slrn sipsak macopix-gtk2 gnss-sdr gkrellm freewheeling boinctui iputils-ping 2: https://lists.debian.org/debian-devel-announce/2017/08/msg4.html 3: https://blog.pcisecuritystandards.org/migrating-from-ssl-and-early-tls 4: https://gnutls.org/manual/html_node/Priority-Strings.html [Original issue description] sSMTP is limited to using TLSv1.0 and the "old" ciphers that come with it. Here's a packet capture when ssmtp connects to smtp.sdeziel.info:587 that offers TLSv1.0 and higher: $ tshark -ta -Vr submission.pcap | sed -n '/^Frame 14:/,/^Frame 15:/ p' | grep -E '^[[:space:]]+(Version|Cipher|Handshake Protocol)' Version: TLS 1.0 (0x0301) Handshake Protocol: Client Hello Version: TLS 1.0 (0x0301) Cipher Suites Length: 30 Cipher Suites (15 suites) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) Cipher Suite: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0041) Cipher Suite: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0084) Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039) Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0045) Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0088) Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016) Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032) Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038) Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA (0x0044) Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA (0x0087) Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013) I would expect ssmtp to use TLSv1.2 and a recent cipher like the openssl s_client is able to do: $ echo | openssl s_client -connect smtp.sdeziel.info:587 -starttls smtp 2>/dev/null | grep -E '^[[:space:]]+(Protocol|Cipher)' Protocol : TLSv1.2 Cipher: ECDHE-RSA-AES128-GCM-SHA256 Additional information: $ lsb_release -rd Description: Ubuntu 16.04.3 LTS Release: 16.04 $ apt-cache policy ssmtp
[Touch-packages] [Bug 1709193] Re: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer
@sdeziel we just hurried the zesty one up yesterday to make place for a new SRU in zesty. And now it is weekend, and I'm not sure, but I don't think updates are released during weekends. You could try pinging in #ubuntu-release on Monday. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gnutls26 in Ubuntu. https://bugs.launchpad.net/bugs/1709193 Title: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer Status in gnutls26 package in Ubuntu: Invalid Status in gnutls28 package in Ubuntu: Fix Released Status in gnutls26 source package in Trusty: Fix Committed Status in gnutls28 source package in Trusty: Won't Fix Status in ssmtp source package in Trusty: Invalid Status in gnutls26 source package in Xenial: Invalid Status in gnutls28 source package in Xenial: Fix Committed Status in ssmtp source package in Xenial: Invalid Status in gnutls26 source package in Zesty: Invalid Status in gnutls28 source package in Zesty: Fix Released Status in ssmtp source package in Zesty: Invalid Status in gnutls26 source package in Artful: Invalid Status in gnutls28 source package in Artful: Fix Released Status in ssmtp source package in Artful: Invalid Status in gnutls28 package in Debian: Fix Released Bug description: [Impact] Applications using GnuTLS OpenSSL compat layer [1] are be unable to use modern TLS versions (1.1 and 1.2) when relying on the SSLv23_{client,server}_method functions. There is an industry-wide push to use modern TLS versions, see [2] and [3] for example. The proposed fix changes the compat layer to use GnuTLS' "NORMAL" priority [4] instead of hard-coding which protocol versions and ciphers to enable. [Test Case] 1) Setup a mail submission server that uses StartTLS 2) Setup sSMTP (uses GnuTLS OpenSSL compat layer) to relay through the mail relay using StartTLS 3) Send an email while capturing with tcpdump/tshark 4) Inspect the submission connection (TCP/587) and look for the protocol version negotiated by the client. Without the fix, you should see TLSv1.0. With the fix, it should be TLSv1.2. Please see the original issue description for more details. [Regression Potential] Regression risk should be low since it's a backport of a simple fix that landed in Debian in April 2017. [References] 1: $ apt-cache rdepends libgnutls-openssl27 libgnutls-openssl27 Reverse Depends: libgnutls-dev libgnutls-dev zoneminder yaskkserv tf5 ssmtp snowdrop sngrep slrnpull slrn sipsak macopix-gtk2 gnss-sdr gkrellm freewheeling boinctui iputils-ping 2: https://lists.debian.org/debian-devel-announce/2017/08/msg4.html 3: https://blog.pcisecuritystandards.org/migrating-from-ssl-and-early-tls 4: https://gnutls.org/manual/html_node/Priority-Strings.html [Original issue description] sSMTP is limited to using TLSv1.0 and the "old" ciphers that come with it. Here's a packet capture when ssmtp connects to smtp.sdeziel.info:587 that offers TLSv1.0 and higher: $ tshark -ta -Vr submission.pcap | sed -n '/^Frame 14:/,/^Frame 15:/ p' | grep -E '^[[:space:]]+(Version|Cipher|Handshake Protocol)' Version: TLS 1.0 (0x0301) Handshake Protocol: Client Hello Version: TLS 1.0 (0x0301) Cipher Suites Length: 30 Cipher Suites (15 suites) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) Cipher Suite: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0041) Cipher Suite: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0084) Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039) Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0045) Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0088) Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016) Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032) Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038) Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA (0x0044) Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA (0x0087) Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013) I would expect ssmtp to use TLSv1.2 and a recent cipher like the openssl s_client is able to do: $ echo | openssl s_client -connect smtp.sdeziel.info:587 -starttls smtp 2>/dev/null | grep -E '^[[:space:]]+(Protocol|Cipher)' Protocol : TLSv1.2 Cipher: ECDHE-RSA-AES128-GCM-SHA256 Additional information: $ lsb_release -rd Description: Ubuntu 16.04.3
[Touch-packages] [Bug 1709193] Re: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer
@sdeziel One problem here probably being that the updates are stuck due to reverse dependencies failing autopkgtest and you not convincing people that these failures are unrelated. If you don't push hard on that kind of stuff, nothing really happens. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gnutls26 in Ubuntu. https://bugs.launchpad.net/bugs/1709193 Title: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer Status in gnutls26 package in Ubuntu: Invalid Status in gnutls28 package in Ubuntu: Fix Released Status in gnutls26 source package in Trusty: Fix Committed Status in gnutls28 source package in Trusty: Won't Fix Status in ssmtp source package in Trusty: Invalid Status in gnutls26 source package in Xenial: Invalid Status in gnutls28 source package in Xenial: Fix Committed Status in ssmtp source package in Xenial: Invalid Status in gnutls26 source package in Zesty: Invalid Status in gnutls28 source package in Zesty: Fix Released Status in ssmtp source package in Zesty: Invalid Status in gnutls26 source package in Artful: Invalid Status in gnutls28 source package in Artful: Fix Released Status in ssmtp source package in Artful: Invalid Status in gnutls28 package in Debian: Fix Released Bug description: [Impact] Applications using GnuTLS OpenSSL compat layer [1] are be unable to use modern TLS versions (1.1 and 1.2) when relying on the SSLv23_{client,server}_method functions. There is an industry-wide push to use modern TLS versions, see [2] and [3] for example. The proposed fix changes the compat layer to use GnuTLS' "NORMAL" priority [4] instead of hard-coding which protocol versions and ciphers to enable. [Test Case] 1) Setup a mail submission server that uses StartTLS 2) Setup sSMTP (uses GnuTLS OpenSSL compat layer) to relay through the mail relay using StartTLS 3) Send an email while capturing with tcpdump/tshark 4) Inspect the submission connection (TCP/587) and look for the protocol version negotiated by the client. Without the fix, you should see TLSv1.0. With the fix, it should be TLSv1.2. Please see the original issue description for more details. [Regression Potential] Regression risk should be low since it's a backport of a simple fix that landed in Debian in April 2017. [References] 1: $ apt-cache rdepends libgnutls-openssl27 libgnutls-openssl27 Reverse Depends: libgnutls-dev libgnutls-dev zoneminder yaskkserv tf5 ssmtp snowdrop sngrep slrnpull slrn sipsak macopix-gtk2 gnss-sdr gkrellm freewheeling boinctui iputils-ping 2: https://lists.debian.org/debian-devel-announce/2017/08/msg4.html 3: https://blog.pcisecuritystandards.org/migrating-from-ssl-and-early-tls 4: https://gnutls.org/manual/html_node/Priority-Strings.html [Original issue description] sSMTP is limited to using TLSv1.0 and the "old" ciphers that come with it. Here's a packet capture when ssmtp connects to smtp.sdeziel.info:587 that offers TLSv1.0 and higher: $ tshark -ta -Vr submission.pcap | sed -n '/^Frame 14:/,/^Frame 15:/ p' | grep -E '^[[:space:]]+(Version|Cipher|Handshake Protocol)' Version: TLS 1.0 (0x0301) Handshake Protocol: Client Hello Version: TLS 1.0 (0x0301) Cipher Suites Length: 30 Cipher Suites (15 suites) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) Cipher Suite: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0041) Cipher Suite: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0084) Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039) Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0045) Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0088) Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016) Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032) Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038) Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA (0x0044) Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA (0x0087) Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013) I would expect ssmtp to use TLSv1.2 and a recent cipher like the openssl s_client is able to do: $ echo | openssl s_client -connect smtp.sdeziel.info:587 -starttls smtp 2>/dev/null | grep -E '^[[:space:]]+(Protocol|Cipher)' Protocol : TLSv1.2 Cipher: ECDHE-RSA-AES128-GCM-SHA256 Additional information: $ lsb_release -rd Description:
[Touch-packages] [Bug 1709193] Re: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer
The Xenial fix is identical to what went in Artful and Zesty so it shouldn't be subject to any more review. The review was requested to check if the different fix proposed for Trusty was OK. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gnutls26 in Ubuntu. https://bugs.launchpad.net/bugs/1709193 Title: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer Status in gnutls26 package in Ubuntu: Invalid Status in gnutls28 package in Ubuntu: Fix Released Status in gnutls26 source package in Trusty: Fix Committed Status in gnutls28 source package in Trusty: Won't Fix Status in ssmtp source package in Trusty: Invalid Status in gnutls26 source package in Xenial: Invalid Status in gnutls28 source package in Xenial: Fix Committed Status in ssmtp source package in Xenial: Invalid Status in gnutls26 source package in Zesty: Invalid Status in gnutls28 source package in Zesty: Fix Released Status in ssmtp source package in Zesty: Invalid Status in gnutls26 source package in Artful: Invalid Status in gnutls28 source package in Artful: Fix Released Status in ssmtp source package in Artful: Invalid Status in gnutls28 package in Debian: Fix Released Bug description: [Impact] Applications using GnuTLS OpenSSL compat layer [1] are be unable to use modern TLS versions (1.1 and 1.2) when relying on the SSLv23_{client,server}_method functions. There is an industry-wide push to use modern TLS versions, see [2] and [3] for example. The proposed fix changes the compat layer to use GnuTLS' "NORMAL" priority [4] instead of hard-coding which protocol versions and ciphers to enable. [Test Case] 1) Setup a mail submission server that uses StartTLS 2) Setup sSMTP (uses GnuTLS OpenSSL compat layer) to relay through the mail relay using StartTLS 3) Send an email while capturing with tcpdump/tshark 4) Inspect the submission connection (TCP/587) and look for the protocol version negotiated by the client. Without the fix, you should see TLSv1.0. With the fix, it should be TLSv1.2. Please see the original issue description for more details. [Regression Potential] Regression risk should be low since it's a backport of a simple fix that landed in Debian in April 2017. [References] 1: $ apt-cache rdepends libgnutls-openssl27 libgnutls-openssl27 Reverse Depends: libgnutls-dev libgnutls-dev zoneminder yaskkserv tf5 ssmtp snowdrop sngrep slrnpull slrn sipsak macopix-gtk2 gnss-sdr gkrellm freewheeling boinctui iputils-ping 2: https://lists.debian.org/debian-devel-announce/2017/08/msg4.html 3: https://blog.pcisecuritystandards.org/migrating-from-ssl-and-early-tls 4: https://gnutls.org/manual/html_node/Priority-Strings.html [Original issue description] sSMTP is limited to using TLSv1.0 and the "old" ciphers that come with it. Here's a packet capture when ssmtp connects to smtp.sdeziel.info:587 that offers TLSv1.0 and higher: $ tshark -ta -Vr submission.pcap | sed -n '/^Frame 14:/,/^Frame 15:/ p' | grep -E '^[[:space:]]+(Version|Cipher|Handshake Protocol)' Version: TLS 1.0 (0x0301) Handshake Protocol: Client Hello Version: TLS 1.0 (0x0301) Cipher Suites Length: 30 Cipher Suites (15 suites) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) Cipher Suite: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0041) Cipher Suite: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0084) Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039) Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0045) Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0088) Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016) Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032) Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038) Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA (0x0044) Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA (0x0087) Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013) I would expect ssmtp to use TLSv1.2 and a recent cipher like the openssl s_client is able to do: $ echo | openssl s_client -connect smtp.sdeziel.info:587 -starttls smtp 2>/dev/null | grep -E '^[[:space:]]+(Protocol|Cipher)' Protocol : TLSv1.2 Cipher: ECDHE-RSA-AES128-GCM-SHA256 Additional information: $ lsb_release -rd Description: Ubuntu 16.04.3 LTS Release: 16.04 $ apt-cache policy
[Touch-packages] [Bug 1709193] Re: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer
Ignore my last comment. You were asking about Xenial but it was the Trusty SRU that was blocked on ubuntu-security review. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gnutls26 in Ubuntu. https://bugs.launchpad.net/bugs/1709193 Title: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer Status in gnutls26 package in Ubuntu: Invalid Status in gnutls28 package in Ubuntu: Fix Released Status in gnutls26 source package in Trusty: Fix Committed Status in gnutls28 source package in Trusty: Won't Fix Status in ssmtp source package in Trusty: Invalid Status in gnutls26 source package in Xenial: Invalid Status in gnutls28 source package in Xenial: Fix Committed Status in ssmtp source package in Xenial: Invalid Status in gnutls26 source package in Zesty: Invalid Status in gnutls28 source package in Zesty: Fix Released Status in ssmtp source package in Zesty: Invalid Status in gnutls26 source package in Artful: Invalid Status in gnutls28 source package in Artful: Fix Released Status in ssmtp source package in Artful: Invalid Status in gnutls28 package in Debian: Fix Released Bug description: [Impact] Applications using GnuTLS OpenSSL compat layer [1] are be unable to use modern TLS versions (1.1 and 1.2) when relying on the SSLv23_{client,server}_method functions. There is an industry-wide push to use modern TLS versions, see [2] and [3] for example. The proposed fix changes the compat layer to use GnuTLS' "NORMAL" priority [4] instead of hard-coding which protocol versions and ciphers to enable. [Test Case] 1) Setup a mail submission server that uses StartTLS 2) Setup sSMTP (uses GnuTLS OpenSSL compat layer) to relay through the mail relay using StartTLS 3) Send an email while capturing with tcpdump/tshark 4) Inspect the submission connection (TCP/587) and look for the protocol version negotiated by the client. Without the fix, you should see TLSv1.0. With the fix, it should be TLSv1.2. Please see the original issue description for more details. [Regression Potential] Regression risk should be low since it's a backport of a simple fix that landed in Debian in April 2017. [References] 1: $ apt-cache rdepends libgnutls-openssl27 libgnutls-openssl27 Reverse Depends: libgnutls-dev libgnutls-dev zoneminder yaskkserv tf5 ssmtp snowdrop sngrep slrnpull slrn sipsak macopix-gtk2 gnss-sdr gkrellm freewheeling boinctui iputils-ping 2: https://lists.debian.org/debian-devel-announce/2017/08/msg4.html 3: https://blog.pcisecuritystandards.org/migrating-from-ssl-and-early-tls 4: https://gnutls.org/manual/html_node/Priority-Strings.html [Original issue description] sSMTP is limited to using TLSv1.0 and the "old" ciphers that come with it. Here's a packet capture when ssmtp connects to smtp.sdeziel.info:587 that offers TLSv1.0 and higher: $ tshark -ta -Vr submission.pcap | sed -n '/^Frame 14:/,/^Frame 15:/ p' | grep -E '^[[:space:]]+(Version|Cipher|Handshake Protocol)' Version: TLS 1.0 (0x0301) Handshake Protocol: Client Hello Version: TLS 1.0 (0x0301) Cipher Suites Length: 30 Cipher Suites (15 suites) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) Cipher Suite: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0041) Cipher Suite: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0084) Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039) Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0045) Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0088) Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016) Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032) Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038) Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA (0x0044) Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA (0x0087) Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013) I would expect ssmtp to use TLSv1.2 and a recent cipher like the openssl s_client is able to do: $ echo | openssl s_client -connect smtp.sdeziel.info:587 -starttls smtp 2>/dev/null | grep -E '^[[:space:]]+(Protocol|Cipher)' Protocol : TLSv1.2 Cipher: ECDHE-RSA-AES128-GCM-SHA256 Additional information: $ lsb_release -rd Description: Ubuntu 16.04.3 LTS Release: 16.04 $ apt-cache policy ssmtp libgnutls-openssl27 ssmtp: Installed: 2.64-8ubuntu1
[Touch-packages] [Bug 1709193] Re: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer
@sdeziel ubuntu-security was asked to comment on it a few days ago. I've just freed up enough to take a look. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gnutls26 in Ubuntu. https://bugs.launchpad.net/bugs/1709193 Title: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer Status in gnutls26 package in Ubuntu: Invalid Status in gnutls28 package in Ubuntu: Fix Released Status in gnutls26 source package in Trusty: Fix Committed Status in gnutls28 source package in Trusty: Won't Fix Status in ssmtp source package in Trusty: Invalid Status in gnutls26 source package in Xenial: Invalid Status in gnutls28 source package in Xenial: Fix Committed Status in ssmtp source package in Xenial: Invalid Status in gnutls26 source package in Zesty: Invalid Status in gnutls28 source package in Zesty: Fix Released Status in ssmtp source package in Zesty: Invalid Status in gnutls26 source package in Artful: Invalid Status in gnutls28 source package in Artful: Fix Released Status in ssmtp source package in Artful: Invalid Status in gnutls28 package in Debian: Fix Released Bug description: [Impact] Applications using GnuTLS OpenSSL compat layer [1] are be unable to use modern TLS versions (1.1 and 1.2) when relying on the SSLv23_{client,server}_method functions. There is an industry-wide push to use modern TLS versions, see [2] and [3] for example. The proposed fix changes the compat layer to use GnuTLS' "NORMAL" priority [4] instead of hard-coding which protocol versions and ciphers to enable. [Test Case] 1) Setup a mail submission server that uses StartTLS 2) Setup sSMTP (uses GnuTLS OpenSSL compat layer) to relay through the mail relay using StartTLS 3) Send an email while capturing with tcpdump/tshark 4) Inspect the submission connection (TCP/587) and look for the protocol version negotiated by the client. Without the fix, you should see TLSv1.0. With the fix, it should be TLSv1.2. Please see the original issue description for more details. [Regression Potential] Regression risk should be low since it's a backport of a simple fix that landed in Debian in April 2017. [References] 1: $ apt-cache rdepends libgnutls-openssl27 libgnutls-openssl27 Reverse Depends: libgnutls-dev libgnutls-dev zoneminder yaskkserv tf5 ssmtp snowdrop sngrep slrnpull slrn sipsak macopix-gtk2 gnss-sdr gkrellm freewheeling boinctui iputils-ping 2: https://lists.debian.org/debian-devel-announce/2017/08/msg4.html 3: https://blog.pcisecuritystandards.org/migrating-from-ssl-and-early-tls 4: https://gnutls.org/manual/html_node/Priority-Strings.html [Original issue description] sSMTP is limited to using TLSv1.0 and the "old" ciphers that come with it. Here's a packet capture when ssmtp connects to smtp.sdeziel.info:587 that offers TLSv1.0 and higher: $ tshark -ta -Vr submission.pcap | sed -n '/^Frame 14:/,/^Frame 15:/ p' | grep -E '^[[:space:]]+(Version|Cipher|Handshake Protocol)' Version: TLS 1.0 (0x0301) Handshake Protocol: Client Hello Version: TLS 1.0 (0x0301) Cipher Suites Length: 30 Cipher Suites (15 suites) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) Cipher Suite: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0041) Cipher Suite: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0084) Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039) Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0045) Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0088) Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016) Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032) Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038) Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA (0x0044) Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA (0x0087) Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013) I would expect ssmtp to use TLSv1.2 and a recent cipher like the openssl s_client is able to do: $ echo | openssl s_client -connect smtp.sdeziel.info:587 -starttls smtp 2>/dev/null | grep -E '^[[:space:]]+(Protocol|Cipher)' Protocol : TLSv1.2 Cipher: ECDHE-RSA-AES128-GCM-SHA256 Additional information: $ lsb_release -rd Description: Ubuntu 16.04.3 LTS Release: 16.04 $ apt-cache policy ssmtp libgnutls-openssl27 ssmtp: Installed: 2.64-8ubuntu1 Candidate:
[Touch-packages] [Bug 1709193] Re: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer
It's been a while since the Xenial -proposed package have been successfully validated. Is there anything preventing it from entering -updates? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gnutls26 in Ubuntu. https://bugs.launchpad.net/bugs/1709193 Title: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer Status in gnutls26 package in Ubuntu: Invalid Status in gnutls28 package in Ubuntu: Fix Released Status in gnutls26 source package in Trusty: Fix Committed Status in gnutls28 source package in Trusty: Won't Fix Status in ssmtp source package in Trusty: Invalid Status in gnutls26 source package in Xenial: Invalid Status in gnutls28 source package in Xenial: Fix Committed Status in ssmtp source package in Xenial: Invalid Status in gnutls26 source package in Zesty: Invalid Status in gnutls28 source package in Zesty: Fix Released Status in ssmtp source package in Zesty: Invalid Status in gnutls26 source package in Artful: Invalid Status in gnutls28 source package in Artful: Fix Released Status in ssmtp source package in Artful: Invalid Status in gnutls28 package in Debian: Fix Released Bug description: [Impact] Applications using GnuTLS OpenSSL compat layer [1] are be unable to use modern TLS versions (1.1 and 1.2) when relying on the SSLv23_{client,server}_method functions. There is an industry-wide push to use modern TLS versions, see [2] and [3] for example. The proposed fix changes the compat layer to use GnuTLS' "NORMAL" priority [4] instead of hard-coding which protocol versions and ciphers to enable. [Test Case] 1) Setup a mail submission server that uses StartTLS 2) Setup sSMTP (uses GnuTLS OpenSSL compat layer) to relay through the mail relay using StartTLS 3) Send an email while capturing with tcpdump/tshark 4) Inspect the submission connection (TCP/587) and look for the protocol version negotiated by the client. Without the fix, you should see TLSv1.0. With the fix, it should be TLSv1.2. Please see the original issue description for more details. [Regression Potential] Regression risk should be low since it's a backport of a simple fix that landed in Debian in April 2017. [References] 1: $ apt-cache rdepends libgnutls-openssl27 libgnutls-openssl27 Reverse Depends: libgnutls-dev libgnutls-dev zoneminder yaskkserv tf5 ssmtp snowdrop sngrep slrnpull slrn sipsak macopix-gtk2 gnss-sdr gkrellm freewheeling boinctui iputils-ping 2: https://lists.debian.org/debian-devel-announce/2017/08/msg4.html 3: https://blog.pcisecuritystandards.org/migrating-from-ssl-and-early-tls 4: https://gnutls.org/manual/html_node/Priority-Strings.html [Original issue description] sSMTP is limited to using TLSv1.0 and the "old" ciphers that come with it. Here's a packet capture when ssmtp connects to smtp.sdeziel.info:587 that offers TLSv1.0 and higher: $ tshark -ta -Vr submission.pcap | sed -n '/^Frame 14:/,/^Frame 15:/ p' | grep -E '^[[:space:]]+(Version|Cipher|Handshake Protocol)' Version: TLS 1.0 (0x0301) Handshake Protocol: Client Hello Version: TLS 1.0 (0x0301) Cipher Suites Length: 30 Cipher Suites (15 suites) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) Cipher Suite: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0041) Cipher Suite: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0084) Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039) Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0045) Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0088) Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016) Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032) Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038) Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA (0x0044) Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA (0x0087) Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013) I would expect ssmtp to use TLSv1.2 and a recent cipher like the openssl s_client is able to do: $ echo | openssl s_client -connect smtp.sdeziel.info:587 -starttls smtp 2>/dev/null | grep -E '^[[:space:]]+(Protocol|Cipher)' Protocol : TLSv1.2 Cipher: ECDHE-RSA-AES128-GCM-SHA256 Additional information: $ lsb_release -rd Description: Ubuntu 16.04.3 LTS Release: 16.04 $ apt-cache policy ssmtp libgnutls-openssl27 ssmtp: Installed:
[Touch-packages] [Bug 1709193] Re: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer
@ubuntu-security -- could we have an oppinion on this patch which is enabling %VERIFY_ALLOW_SIGN_RSA_MD5 for trusty. Looking to understand if this is overly broad and therefore a security issue. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gnutls26 in Ubuntu. https://bugs.launchpad.net/bugs/1709193 Title: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer Status in gnutls26 package in Ubuntu: Invalid Status in gnutls28 package in Ubuntu: Fix Released Status in gnutls26 source package in Trusty: Fix Committed Status in gnutls28 source package in Trusty: Won't Fix Status in ssmtp source package in Trusty: Invalid Status in gnutls26 source package in Xenial: Invalid Status in gnutls28 source package in Xenial: Fix Committed Status in ssmtp source package in Xenial: Invalid Status in gnutls26 source package in Zesty: Invalid Status in gnutls28 source package in Zesty: Fix Released Status in ssmtp source package in Zesty: Invalid Status in gnutls26 source package in Artful: Invalid Status in gnutls28 source package in Artful: Fix Released Status in ssmtp source package in Artful: Invalid Status in gnutls28 package in Debian: Fix Released Bug description: [Impact] Applications using GnuTLS OpenSSL compat layer [1] are be unable to use modern TLS versions (1.1 and 1.2) when relying on the SSLv23_{client,server}_method functions. There is an industry-wide push to use modern TLS versions, see [2] and [3] for example. The proposed fix changes the compat layer to use GnuTLS' "NORMAL" priority [4] instead of hard-coding which protocol versions and ciphers to enable. [Test Case] 1) Setup a mail submission server that uses StartTLS 2) Setup sSMTP (uses GnuTLS OpenSSL compat layer) to relay through the mail relay using StartTLS 3) Send an email while capturing with tcpdump/tshark 4) Inspect the submission connection (TCP/587) and look for the protocol version negotiated by the client. Without the fix, you should see TLSv1.0. With the fix, it should be TLSv1.2. Please see the original issue description for more details. [Regression Potential] Regression risk should be low since it's a backport of a simple fix that landed in Debian in April 2017. [References] 1: $ apt-cache rdepends libgnutls-openssl27 libgnutls-openssl27 Reverse Depends: libgnutls-dev libgnutls-dev zoneminder yaskkserv tf5 ssmtp snowdrop sngrep slrnpull slrn sipsak macopix-gtk2 gnss-sdr gkrellm freewheeling boinctui iputils-ping 2: https://lists.debian.org/debian-devel-announce/2017/08/msg4.html 3: https://blog.pcisecuritystandards.org/migrating-from-ssl-and-early-tls 4: https://gnutls.org/manual/html_node/Priority-Strings.html [Original issue description] sSMTP is limited to using TLSv1.0 and the "old" ciphers that come with it. Here's a packet capture when ssmtp connects to smtp.sdeziel.info:587 that offers TLSv1.0 and higher: $ tshark -ta -Vr submission.pcap | sed -n '/^Frame 14:/,/^Frame 15:/ p' | grep -E '^[[:space:]]+(Version|Cipher|Handshake Protocol)' Version: TLS 1.0 (0x0301) Handshake Protocol: Client Hello Version: TLS 1.0 (0x0301) Cipher Suites Length: 30 Cipher Suites (15 suites) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) Cipher Suite: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0041) Cipher Suite: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0084) Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039) Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0045) Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0088) Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016) Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032) Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038) Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA (0x0044) Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA (0x0087) Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013) I would expect ssmtp to use TLSv1.2 and a recent cipher like the openssl s_client is able to do: $ echo | openssl s_client -connect smtp.sdeziel.info:587 -starttls smtp 2>/dev/null | grep -E '^[[:space:]]+(Protocol|Cipher)' Protocol : TLSv1.2 Cipher: ECDHE-RSA-AES128-GCM-SHA256 Additional information: $ lsb_release -rd Description: Ubuntu 16.04.3 LTS Release: 16.04 $ apt-cache
[Touch-packages] [Bug 1709193] Re: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer
So, I believe the proposed 2nd trusty might accidentally allow MD5 everywhere, when the problem only is root certificates with MD5 self signatures. I believe this might be related: https://gitlab.com/gnutls/gnutls/commit/b93ae1abf1b84fdc094f2474f1b2e4848081810e But I'm not sure if it fixes the issue and if any other patches are needed from 2.12.24. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gnutls26 in Ubuntu. https://bugs.launchpad.net/bugs/1709193 Title: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer Status in gnutls26 package in Ubuntu: Invalid Status in gnutls28 package in Ubuntu: Fix Released Status in gnutls26 source package in Trusty: Fix Committed Status in gnutls28 source package in Trusty: Won't Fix Status in ssmtp source package in Trusty: Invalid Status in gnutls26 source package in Xenial: Invalid Status in gnutls28 source package in Xenial: Fix Committed Status in ssmtp source package in Xenial: Invalid Status in gnutls26 source package in Zesty: Invalid Status in gnutls28 source package in Zesty: Fix Released Status in ssmtp source package in Zesty: Invalid Status in gnutls26 source package in Artful: Invalid Status in gnutls28 source package in Artful: Fix Released Status in ssmtp source package in Artful: Invalid Status in gnutls28 package in Debian: Fix Released Bug description: [Impact] Applications using GnuTLS OpenSSL compat layer [1] are be unable to use modern TLS versions (1.1 and 1.2) when relying on the SSLv23_{client,server}_method functions. There is an industry-wide push to use modern TLS versions, see [2] and [3] for example. The proposed fix changes the compat layer to use GnuTLS' "NORMAL" priority [4] instead of hard-coding which protocol versions and ciphers to enable. [Test Case] 1) Setup a mail submission server that uses StartTLS 2) Setup sSMTP (uses GnuTLS OpenSSL compat layer) to relay through the mail relay using StartTLS 3) Send an email while capturing with tcpdump/tshark 4) Inspect the submission connection (TCP/587) and look for the protocol version negotiated by the client. Without the fix, you should see TLSv1.0. With the fix, it should be TLSv1.2. Please see the original issue description for more details. [Regression Potential] Regression risk should be low since it's a backport of a simple fix that landed in Debian in April 2017. [References] 1: $ apt-cache rdepends libgnutls-openssl27 libgnutls-openssl27 Reverse Depends: libgnutls-dev libgnutls-dev zoneminder yaskkserv tf5 ssmtp snowdrop sngrep slrnpull slrn sipsak macopix-gtk2 gnss-sdr gkrellm freewheeling boinctui iputils-ping 2: https://lists.debian.org/debian-devel-announce/2017/08/msg4.html 3: https://blog.pcisecuritystandards.org/migrating-from-ssl-and-early-tls 4: https://gnutls.org/manual/html_node/Priority-Strings.html [Original issue description] sSMTP is limited to using TLSv1.0 and the "old" ciphers that come with it. Here's a packet capture when ssmtp connects to smtp.sdeziel.info:587 that offers TLSv1.0 and higher: $ tshark -ta -Vr submission.pcap | sed -n '/^Frame 14:/,/^Frame 15:/ p' | grep -E '^[[:space:]]+(Version|Cipher|Handshake Protocol)' Version: TLS 1.0 (0x0301) Handshake Protocol: Client Hello Version: TLS 1.0 (0x0301) Cipher Suites Length: 30 Cipher Suites (15 suites) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) Cipher Suite: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0041) Cipher Suite: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0084) Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039) Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0045) Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0088) Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016) Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032) Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038) Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA (0x0044) Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA (0x0087) Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013) I would expect ssmtp to use TLSv1.2 and a recent cipher like the openssl s_client is able to do: $ echo | openssl s_client -connect smtp.sdeziel.info:587 -starttls smtp 2>/dev/null | grep -E '^[[:space:]]+(Protocol|Cipher)' Protocol : TLSv1.2 Cipher
[Touch-packages] [Bug 1709193] Re: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer
This bug was fixed in the package gnutls28 - 3.5.6-4ubuntu4.2 --- gnutls28 (3.5.6-4ubuntu4.2) zesty; urgency=medium * use_normal_priority_for_openssl_sslv23.diff by Andreas Metzler: OpenSSL wrapper: SSLv23_*_method translates to NORMAL GnuTLS priority, which includes TLS1.2 support. (LP: #1709193) -- Simon DezielThu, 10 Aug 2017 12:47:14 + ** Changed in: gnutls28 (Ubuntu Zesty) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gnutls26 in Ubuntu. https://bugs.launchpad.net/bugs/1709193 Title: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer Status in gnutls26 package in Ubuntu: Invalid Status in gnutls28 package in Ubuntu: Fix Released Status in gnutls26 source package in Trusty: Fix Committed Status in gnutls28 source package in Trusty: Won't Fix Status in ssmtp source package in Trusty: Invalid Status in gnutls26 source package in Xenial: Invalid Status in gnutls28 source package in Xenial: Fix Committed Status in ssmtp source package in Xenial: Invalid Status in gnutls26 source package in Zesty: Invalid Status in gnutls28 source package in Zesty: Fix Released Status in ssmtp source package in Zesty: Invalid Status in gnutls26 source package in Artful: Invalid Status in gnutls28 source package in Artful: Fix Released Status in ssmtp source package in Artful: Invalid Status in gnutls28 package in Debian: Fix Released Bug description: [Impact] Applications using GnuTLS OpenSSL compat layer [1] are be unable to use modern TLS versions (1.1 and 1.2) when relying on the SSLv23_{client,server}_method functions. There is an industry-wide push to use modern TLS versions, see [2] and [3] for example. The proposed fix changes the compat layer to use GnuTLS' "NORMAL" priority [4] instead of hard-coding which protocol versions and ciphers to enable. [Test Case] 1) Setup a mail submission server that uses StartTLS 2) Setup sSMTP (uses GnuTLS OpenSSL compat layer) to relay through the mail relay using StartTLS 3) Send an email while capturing with tcpdump/tshark 4) Inspect the submission connection (TCP/587) and look for the protocol version negotiated by the client. Without the fix, you should see TLSv1.0. With the fix, it should be TLSv1.2. Please see the original issue description for more details. [Regression Potential] Regression risk should be low since it's a backport of a simple fix that landed in Debian in April 2017. [References] 1: $ apt-cache rdepends libgnutls-openssl27 libgnutls-openssl27 Reverse Depends: libgnutls-dev libgnutls-dev zoneminder yaskkserv tf5 ssmtp snowdrop sngrep slrnpull slrn sipsak macopix-gtk2 gnss-sdr gkrellm freewheeling boinctui iputils-ping 2: https://lists.debian.org/debian-devel-announce/2017/08/msg4.html 3: https://blog.pcisecuritystandards.org/migrating-from-ssl-and-early-tls 4: https://gnutls.org/manual/html_node/Priority-Strings.html [Original issue description] sSMTP is limited to using TLSv1.0 and the "old" ciphers that come with it. Here's a packet capture when ssmtp connects to smtp.sdeziel.info:587 that offers TLSv1.0 and higher: $ tshark -ta -Vr submission.pcap | sed -n '/^Frame 14:/,/^Frame 15:/ p' | grep -E '^[[:space:]]+(Version|Cipher|Handshake Protocol)' Version: TLS 1.0 (0x0301) Handshake Protocol: Client Hello Version: TLS 1.0 (0x0301) Cipher Suites Length: 30 Cipher Suites (15 suites) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) Cipher Suite: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0041) Cipher Suite: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0084) Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039) Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0045) Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0088) Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016) Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032) Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038) Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA (0x0044) Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA (0x0087) Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013) I would expect ssmtp to use TLSv1.2 and a recent cipher like the openssl s_client is able to do: $ echo | openssl s_client -connect
[Touch-packages] [Bug 1709193] Re: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer
On Truty with 2.12.23-12ubuntu2.9, the sSMTP client would abort the StartTLS connection complaining it didn't support the signature algorithm in use. When validating I used a mail relay with a RSA-SHA256 cert signed by CAcert.org. CAcert.org is (self-signed) RSA-MD5. It turned out that Trusty also needed the GnuTLS priority string to include %VERIFY_ALLOW_SIGN_RSA_MD5 to support that use case and avoid the regression. It's unclear to me why only gnutls26 needed this since I used the exact same test case for all 3 distro versions. The version 2 of the debdiff for Trusty was tested with certificates chains including MD5, SHA1 and SHA256 certificates and revealed no problem and fixed the regression previously found. ** Patch added: "lp1709193-14.04-version2.debdiff" https://bugs.launchpad.net/debian/+source/gnutls28/+bug/1709193/+attachment/4936464/+files/lp1709193-14.04-version2.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gnutls26 in Ubuntu. https://bugs.launchpad.net/bugs/1709193 Title: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer Status in gnutls26 package in Ubuntu: Invalid Status in gnutls28 package in Ubuntu: Fix Released Status in gnutls26 source package in Trusty: Fix Committed Status in gnutls28 source package in Trusty: Won't Fix Status in ssmtp source package in Trusty: Invalid Status in gnutls26 source package in Xenial: Invalid Status in gnutls28 source package in Xenial: Fix Committed Status in ssmtp source package in Xenial: Invalid Status in gnutls26 source package in Zesty: Invalid Status in gnutls28 source package in Zesty: Fix Committed Status in ssmtp source package in Zesty: Invalid Status in gnutls26 source package in Artful: Invalid Status in gnutls28 source package in Artful: Fix Released Status in ssmtp source package in Artful: Invalid Status in gnutls28 package in Debian: Fix Released Bug description: [Impact] Applications using GnuTLS OpenSSL compat layer [1] are be unable to use modern TLS versions (1.1 and 1.2) when relying on the SSLv23_{client,server}_method functions. There is an industry-wide push to use modern TLS versions, see [2] and [3] for example. The proposed fix changes the compat layer to use GnuTLS' "NORMAL" priority [4] instead of hard-coding which protocol versions and ciphers to enable. [Test Case] 1) Setup a mail submission server that uses StartTLS 2) Setup sSMTP (uses GnuTLS OpenSSL compat layer) to relay through the mail relay using StartTLS 3) Send an email while capturing with tcpdump/tshark 4) Inspect the submission connection (TCP/587) and look for the protocol version negotiated by the client. Without the fix, you should see TLSv1.0. With the fix, it should be TLSv1.2. Please see the original issue description for more details. [Regression Potential] Regression risk should be low since it's a backport of a simple fix that landed in Debian in April 2017. [References] 1: $ apt-cache rdepends libgnutls-openssl27 libgnutls-openssl27 Reverse Depends: libgnutls-dev libgnutls-dev zoneminder yaskkserv tf5 ssmtp snowdrop sngrep slrnpull slrn sipsak macopix-gtk2 gnss-sdr gkrellm freewheeling boinctui iputils-ping 2: https://lists.debian.org/debian-devel-announce/2017/08/msg4.html 3: https://blog.pcisecuritystandards.org/migrating-from-ssl-and-early-tls 4: https://gnutls.org/manual/html_node/Priority-Strings.html [Original issue description] sSMTP is limited to using TLSv1.0 and the "old" ciphers that come with it. Here's a packet capture when ssmtp connects to smtp.sdeziel.info:587 that offers TLSv1.0 and higher: $ tshark -ta -Vr submission.pcap | sed -n '/^Frame 14:/,/^Frame 15:/ p' | grep -E '^[[:space:]]+(Version|Cipher|Handshake Protocol)' Version: TLS 1.0 (0x0301) Handshake Protocol: Client Hello Version: TLS 1.0 (0x0301) Cipher Suites Length: 30 Cipher Suites (15 suites) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) Cipher Suite: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0041) Cipher Suite: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0084) Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039) Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0045) Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0088) Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016) Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032) Cipher
[Touch-packages] [Bug 1709193] Re: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer
The trusty-proposed version (2.12.23-12ubuntu2.9) doesn't work and introduces a regression preventing successful TLS/SSL connections. I'll check if there is an easy fix for gnutls26. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gnutls26 in Ubuntu. https://bugs.launchpad.net/bugs/1709193 Title: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer Status in gnutls26 package in Ubuntu: Invalid Status in gnutls28 package in Ubuntu: Fix Released Status in gnutls26 source package in Trusty: Fix Committed Status in gnutls28 source package in Trusty: Won't Fix Status in ssmtp source package in Trusty: Invalid Status in gnutls26 source package in Xenial: Invalid Status in gnutls28 source package in Xenial: Fix Committed Status in ssmtp source package in Xenial: Invalid Status in gnutls26 source package in Zesty: Invalid Status in gnutls28 source package in Zesty: Fix Committed Status in ssmtp source package in Zesty: Invalid Status in gnutls26 source package in Artful: Invalid Status in gnutls28 source package in Artful: Fix Released Status in ssmtp source package in Artful: Invalid Status in gnutls28 package in Debian: Fix Released Bug description: [Impact] Applications using GnuTLS OpenSSL compat layer [1] are be unable to use modern TLS versions (1.1 and 1.2) when relying on the SSLv23_{client,server}_method functions. There is an industry-wide push to use modern TLS versions, see [2] and [3] for example. The proposed fix changes the compat layer to use GnuTLS' "NORMAL" priority [4] instead of hard-coding which protocol versions and ciphers to enable. [Test Case] 1) Setup a mail submission server that uses StartTLS 2) Setup sSMTP (uses GnuTLS OpenSSL compat layer) to relay through the mail relay using StartTLS 3) Send an email while capturing with tcpdump/tshark 4) Inspect the submission connection (TCP/587) and look for the protocol version negotiated by the client. Without the fix, you should see TLSv1.0. With the fix, it should be TLSv1.2. Please see the original issue description for more details. [Regression Potential] Regression risk should be low since it's a backport of a simple fix that landed in Debian in April 2017. [References] 1: $ apt-cache rdepends libgnutls-openssl27 libgnutls-openssl27 Reverse Depends: libgnutls-dev libgnutls-dev zoneminder yaskkserv tf5 ssmtp snowdrop sngrep slrnpull slrn sipsak macopix-gtk2 gnss-sdr gkrellm freewheeling boinctui iputils-ping 2: https://lists.debian.org/debian-devel-announce/2017/08/msg4.html 3: https://blog.pcisecuritystandards.org/migrating-from-ssl-and-early-tls 4: https://gnutls.org/manual/html_node/Priority-Strings.html [Original issue description] sSMTP is limited to using TLSv1.0 and the "old" ciphers that come with it. Here's a packet capture when ssmtp connects to smtp.sdeziel.info:587 that offers TLSv1.0 and higher: $ tshark -ta -Vr submission.pcap | sed -n '/^Frame 14:/,/^Frame 15:/ p' | grep -E '^[[:space:]]+(Version|Cipher|Handshake Protocol)' Version: TLS 1.0 (0x0301) Handshake Protocol: Client Hello Version: TLS 1.0 (0x0301) Cipher Suites Length: 30 Cipher Suites (15 suites) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) Cipher Suite: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0041) Cipher Suite: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0084) Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039) Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0045) Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0088) Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016) Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032) Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038) Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA (0x0044) Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA (0x0087) Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013) I would expect ssmtp to use TLSv1.2 and a recent cipher like the openssl s_client is able to do: $ echo | openssl s_client -connect smtp.sdeziel.info:587 -starttls smtp 2>/dev/null | grep -E '^[[:space:]]+(Protocol|Cipher)' Protocol : TLSv1.2 Cipher: ECDHE-RSA-AES128-GCM-SHA256 Additional information: $ lsb_release -rd Description: Ubuntu 16.04.3 LTS Release: 16.04 $ apt-cache policy ssmtp
[Touch-packages] [Bug 1709193] Re: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer
Verified on Zesty with: $ apt-cache policy libgnutls-openssl27:amd64 libgnutls-openssl27: Installed: 3.5.6-4ubuntu4.2 Candidate: 3.5.6-4ubuntu4.2 Version table: *** 3.5.6-4ubuntu4.2 500 500 http://archive.ubuntu.com/ubuntu zesty-proposed/main amd64 Packages 100 /var/lib/dpkg/status 3.5.6-4ubuntu4.1 500 500 http://archive.ubuntu.com/ubuntu zesty-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu zesty-security/main amd64 Packages 3.5.6-4ubuntu4 500 500 http://archive.ubuntu.com/ubuntu zesty/main amd64 Packages ** Tags removed: verification-done-xenial verification-needed-zesty ** Tags added: verification-done-zesty verification-needed-xenial ** Tags removed: verification-needed-trusty verification-needed-xenial ** Tags added: verification-done-xenial verification-failed-trusty -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gnutls26 in Ubuntu. https://bugs.launchpad.net/bugs/1709193 Title: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer Status in gnutls26 package in Ubuntu: Invalid Status in gnutls28 package in Ubuntu: Fix Released Status in gnutls26 source package in Trusty: Fix Committed Status in gnutls28 source package in Trusty: Won't Fix Status in ssmtp source package in Trusty: Invalid Status in gnutls26 source package in Xenial: Invalid Status in gnutls28 source package in Xenial: Fix Committed Status in ssmtp source package in Xenial: Invalid Status in gnutls26 source package in Zesty: Invalid Status in gnutls28 source package in Zesty: Fix Committed Status in ssmtp source package in Zesty: Invalid Status in gnutls26 source package in Artful: Invalid Status in gnutls28 source package in Artful: Fix Released Status in ssmtp source package in Artful: Invalid Status in gnutls28 package in Debian: Fix Released Bug description: [Impact] Applications using GnuTLS OpenSSL compat layer [1] are be unable to use modern TLS versions (1.1 and 1.2) when relying on the SSLv23_{client,server}_method functions. There is an industry-wide push to use modern TLS versions, see [2] and [3] for example. The proposed fix changes the compat layer to use GnuTLS' "NORMAL" priority [4] instead of hard-coding which protocol versions and ciphers to enable. [Test Case] 1) Setup a mail submission server that uses StartTLS 2) Setup sSMTP (uses GnuTLS OpenSSL compat layer) to relay through the mail relay using StartTLS 3) Send an email while capturing with tcpdump/tshark 4) Inspect the submission connection (TCP/587) and look for the protocol version negotiated by the client. Without the fix, you should see TLSv1.0. With the fix, it should be TLSv1.2. Please see the original issue description for more details. [Regression Potential] Regression risk should be low since it's a backport of a simple fix that landed in Debian in April 2017. [References] 1: $ apt-cache rdepends libgnutls-openssl27 libgnutls-openssl27 Reverse Depends: libgnutls-dev libgnutls-dev zoneminder yaskkserv tf5 ssmtp snowdrop sngrep slrnpull slrn sipsak macopix-gtk2 gnss-sdr gkrellm freewheeling boinctui iputils-ping 2: https://lists.debian.org/debian-devel-announce/2017/08/msg4.html 3: https://blog.pcisecuritystandards.org/migrating-from-ssl-and-early-tls 4: https://gnutls.org/manual/html_node/Priority-Strings.html [Original issue description] sSMTP is limited to using TLSv1.0 and the "old" ciphers that come with it. Here's a packet capture when ssmtp connects to smtp.sdeziel.info:587 that offers TLSv1.0 and higher: $ tshark -ta -Vr submission.pcap | sed -n '/^Frame 14:/,/^Frame 15:/ p' | grep -E '^[[:space:]]+(Version|Cipher|Handshake Protocol)' Version: TLS 1.0 (0x0301) Handshake Protocol: Client Hello Version: TLS 1.0 (0x0301) Cipher Suites Length: 30 Cipher Suites (15 suites) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) Cipher Suite: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0041) Cipher Suite: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0084) Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039) Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0045) Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0088) Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016) Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032) Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA
[Touch-packages] [Bug 1709193] Re: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer
Verified on Xenial with: $ apt-cache policy libgnutls-openssl27:amd64 libgnutls-openssl27: Installed: 3.4.10-4ubuntu1.4 Candidate: 3.4.10-4ubuntu1.4 Version table: *** 3.4.10-4ubuntu1.4 500 500 http://archive.ubuntu.com/ubuntu xenial-proposed/main amd64 Packages 100 /var/lib/dpkg/status 3.4.10-4ubuntu1.3 500 500 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu xenial-security/main amd64 Packages 3.4.10-4ubuntu1 500 500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages ** Tags removed: verification-needed-xenial ** Tags added: verification-done-xenial -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gnutls26 in Ubuntu. https://bugs.launchpad.net/bugs/1709193 Title: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer Status in gnutls26 package in Ubuntu: Invalid Status in gnutls28 package in Ubuntu: Fix Released Status in gnutls26 source package in Trusty: Fix Committed Status in gnutls28 source package in Trusty: Won't Fix Status in ssmtp source package in Trusty: Invalid Status in gnutls26 source package in Xenial: Invalid Status in gnutls28 source package in Xenial: Fix Committed Status in ssmtp source package in Xenial: Invalid Status in gnutls26 source package in Zesty: Invalid Status in gnutls28 source package in Zesty: Fix Committed Status in ssmtp source package in Zesty: Invalid Status in gnutls26 source package in Artful: Invalid Status in gnutls28 source package in Artful: Fix Released Status in ssmtp source package in Artful: Invalid Status in gnutls28 package in Debian: Fix Released Bug description: [Impact] Applications using GnuTLS OpenSSL compat layer [1] are be unable to use modern TLS versions (1.1 and 1.2) when relying on the SSLv23_{client,server}_method functions. There is an industry-wide push to use modern TLS versions, see [2] and [3] for example. The proposed fix changes the compat layer to use GnuTLS' "NORMAL" priority [4] instead of hard-coding which protocol versions and ciphers to enable. [Test Case] 1) Setup a mail submission server that uses StartTLS 2) Setup sSMTP (uses GnuTLS OpenSSL compat layer) to relay through the mail relay using StartTLS 3) Send an email while capturing with tcpdump/tshark 4) Inspect the submission connection (TCP/587) and look for the protocol version negotiated by the client. Without the fix, you should see TLSv1.0. With the fix, it should be TLSv1.2. Please see the original issue description for more details. [Regression Potential] Regression risk should be low since it's a backport of a simple fix that landed in Debian in April 2017. [References] 1: $ apt-cache rdepends libgnutls-openssl27 libgnutls-openssl27 Reverse Depends: libgnutls-dev libgnutls-dev zoneminder yaskkserv tf5 ssmtp snowdrop sngrep slrnpull slrn sipsak macopix-gtk2 gnss-sdr gkrellm freewheeling boinctui iputils-ping 2: https://lists.debian.org/debian-devel-announce/2017/08/msg4.html 3: https://blog.pcisecuritystandards.org/migrating-from-ssl-and-early-tls 4: https://gnutls.org/manual/html_node/Priority-Strings.html [Original issue description] sSMTP is limited to using TLSv1.0 and the "old" ciphers that come with it. Here's a packet capture when ssmtp connects to smtp.sdeziel.info:587 that offers TLSv1.0 and higher: $ tshark -ta -Vr submission.pcap | sed -n '/^Frame 14:/,/^Frame 15:/ p' | grep -E '^[[:space:]]+(Version|Cipher|Handshake Protocol)' Version: TLS 1.0 (0x0301) Handshake Protocol: Client Hello Version: TLS 1.0 (0x0301) Cipher Suites Length: 30 Cipher Suites (15 suites) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) Cipher Suite: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0041) Cipher Suite: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0084) Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039) Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0045) Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0088) Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016) Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032) Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038) Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA (0x0044) Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA (0x0087)
[Touch-packages] [Bug 1709193] Re: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer
Hello Simon, or anyone else affected, Accepted gnutls28 into zesty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/gnutls28/3.5.6-4ubuntu4.2 in a few hours, and then in the -proposed repository. Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-zesty to verification-done-zesty. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-zesty. In either case, details of your testing will help us make a better decision. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance! ** Changed in: gnutls28 (Ubuntu Zesty) Status: In Progress => Fix Committed ** Tags added: verification-needed verification-needed-zesty ** Changed in: gnutls28 (Ubuntu Xenial) Status: In Progress => Fix Committed ** Tags added: verification-needed-xenial -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gnutls26 in Ubuntu. https://bugs.launchpad.net/bugs/1709193 Title: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer Status in gnutls26 package in Ubuntu: Invalid Status in gnutls28 package in Ubuntu: Fix Released Status in gnutls26 source package in Trusty: Fix Committed Status in gnutls28 source package in Trusty: Won't Fix Status in ssmtp source package in Trusty: Invalid Status in gnutls26 source package in Xenial: Invalid Status in gnutls28 source package in Xenial: Fix Committed Status in ssmtp source package in Xenial: Invalid Status in gnutls26 source package in Zesty: Invalid Status in gnutls28 source package in Zesty: Fix Committed Status in ssmtp source package in Zesty: Invalid Status in gnutls26 source package in Artful: Invalid Status in gnutls28 source package in Artful: Fix Released Status in ssmtp source package in Artful: Invalid Status in gnutls28 package in Debian: Fix Released Bug description: [Impact] Applications using GnuTLS OpenSSL compat layer [1] are be unable to use modern TLS versions (1.1 and 1.2) when relying on the SSLv23_{client,server}_method functions. There is an industry-wide push to use modern TLS versions, see [2] and [3] for example. The proposed fix changes the compat layer to use GnuTLS' "NORMAL" priority [4] instead of hard-coding which protocol versions and ciphers to enable. [Test Case] 1) Setup a mail submission server that uses StartTLS 2) Setup sSMTP (uses GnuTLS OpenSSL compat layer) to relay through the mail relay using StartTLS 3) Send an email while capturing with tcpdump/tshark 4) Inspect the submission connection (TCP/587) and look for the protocol version negotiated by the client. Without the fix, you should see TLSv1.0. With the fix, it should be TLSv1.2. Please see the original issue description for more details. [Regression Potential] Regression risk should be low since it's a backport of a simple fix that landed in Debian in April 2017. [References] 1: $ apt-cache rdepends libgnutls-openssl27 libgnutls-openssl27 Reverse Depends: libgnutls-dev libgnutls-dev zoneminder yaskkserv tf5 ssmtp snowdrop sngrep slrnpull slrn sipsak macopix-gtk2 gnss-sdr gkrellm freewheeling boinctui iputils-ping 2: https://lists.debian.org/debian-devel-announce/2017/08/msg4.html 3: https://blog.pcisecuritystandards.org/migrating-from-ssl-and-early-tls 4: https://gnutls.org/manual/html_node/Priority-Strings.html [Original issue description] sSMTP is limited to using TLSv1.0 and the "old" ciphers that come with it. Here's a packet capture when ssmtp connects to smtp.sdeziel.info:587 that offers TLSv1.0 and higher: $ tshark -ta -Vr submission.pcap | sed -n '/^Frame 14:/,/^Frame 15:/ p' | grep -E '^[[:space:]]+(Version|Cipher|Handshake Protocol)' Version: TLS 1.0 (0x0301) Handshake Protocol: Client Hello Version: TLS 1.0 (0x0301) Cipher Suites Length: 30 Cipher Suites (15 suites) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) Cipher Suite: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0041) Cipher Suite: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0084) Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
[Touch-packages] [Bug 1709193] Re: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer
This bug was fixed in the package gnutls28 - 3.5.8-6ubuntu2 --- gnutls28 (3.5.8-6ubuntu2) artful; urgency=medium * use_normal_priority_for_openssl_sslv23.diff by Andreas Metzler: OpenSSL wrapper: SSLv23_*_method translates to NORMAL GnuTLS priority, which includes TLS1.2 support. (LP: #1709193) -- Simon DezielThu, 10 Aug 2017 00:34:06 + ** Changed in: gnutls28 (Ubuntu Artful) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gnutls26 in Ubuntu. https://bugs.launchpad.net/bugs/1709193 Title: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer Status in gnutls26 package in Ubuntu: Invalid Status in gnutls28 package in Ubuntu: Fix Released Status in gnutls26 source package in Trusty: In Progress Status in gnutls28 source package in Trusty: Won't Fix Status in ssmtp source package in Trusty: Invalid Status in gnutls26 source package in Xenial: Invalid Status in gnutls28 source package in Xenial: In Progress Status in ssmtp source package in Xenial: Invalid Status in gnutls26 source package in Zesty: Invalid Status in gnutls28 source package in Zesty: In Progress Status in ssmtp source package in Zesty: Invalid Status in gnutls26 source package in Artful: Invalid Status in gnutls28 source package in Artful: Fix Released Status in ssmtp source package in Artful: Invalid Status in gnutls28 package in Debian: Fix Released Bug description: [Impact] Applications using GnuTLS OpenSSL compat layer [1] are be unable to use modern TLS versions (1.1 and 1.2) when relying on the SSLv23_{client,server}_method functions. There is an industry-wide push to use modern TLS versions, see [2] and [3] for example. The proposed fix changes the compat layer to use GnuTLS' "NORMAL" priority [4] instead of hard-coding which protocol versions and ciphers to enable. [Test Case] 1) Setup a mail submission server that uses StartTLS 2) Setup sSMTP (uses GnuTLS OpenSSL compat layer) to relay through the mail relay using StartTLS 3) Send an email while capturing with tcpdump/tshark 4) Inspect the submission connection (TCP/587) and look for the protocol version negotiated by the client. Without the fix, you should see TLSv1.0. With the fix, it should be TLSv1.2. Please see the original issue description for more details. [Regression Potential] Regression risk should be low since it's a backport of a simple fix that landed in Debian in April 2017. [References] 1: $ apt-cache rdepends libgnutls-openssl27 libgnutls-openssl27 Reverse Depends: libgnutls-dev libgnutls-dev zoneminder yaskkserv tf5 ssmtp snowdrop sngrep slrnpull slrn sipsak macopix-gtk2 gnss-sdr gkrellm freewheeling boinctui iputils-ping 2: https://lists.debian.org/debian-devel-announce/2017/08/msg4.html 3: https://blog.pcisecuritystandards.org/migrating-from-ssl-and-early-tls 4: https://gnutls.org/manual/html_node/Priority-Strings.html [Original issue description] sSMTP is limited to using TLSv1.0 and the "old" ciphers that come with it. Here's a packet capture when ssmtp connects to smtp.sdeziel.info:587 that offers TLSv1.0 and higher: $ tshark -ta -Vr submission.pcap | sed -n '/^Frame 14:/,/^Frame 15:/ p' | grep -E '^[[:space:]]+(Version|Cipher|Handshake Protocol)' Version: TLS 1.0 (0x0301) Handshake Protocol: Client Hello Version: TLS 1.0 (0x0301) Cipher Suites Length: 30 Cipher Suites (15 suites) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) Cipher Suite: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0041) Cipher Suite: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0084) Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039) Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0045) Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0088) Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016) Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032) Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038) Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA (0x0044) Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA (0x0087) Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013) I would expect ssmtp to use TLSv1.2 and a recent cipher like the openssl s_client is able to do: $ echo | openssl s_client -connect
[Touch-packages] [Bug 1709193] Re: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer
** Description changed: + [Impact] + + Applications using GnuTLS OpenSSL compat layer [1] are be unable to use + modern TLS versions (1.1 and 1.2) when relying on the + SSLv23_{client,server}_method functions. + + There is an industry-wide push to use modern TLS versions, see [2] and + [3] for example. + + The proposed fix changes the compat layer to use GnuTLS' "NORMAL" + priority [4] instead of hard-coding which protocol versions and ciphers + to enable. + + [Test Case] + + 1) Setup a mail submission server that uses StartTLS + 2) Setup sSMTP (uses GnuTLS OpenSSL compat layer) to relay +through the mail relay using StartTLS + 3) Send an email while capturing with tcpdump/tshark + 4) Inspect the submission connection (TCP/587) and look for the protocol +version negotiated by the client. + + Without the fix, you should see TLSv1.0. With the fix, it should be + TLSv1.2. + + Please see the original issue description for more details. + + [Regression Potential] + + Regression risk should be low since it's a backport of a simple fix that + landed in Debian in April 2017. + + [References] + + 1: $ apt-cache rdepends libgnutls-openssl27 + libgnutls-openssl27 + Reverse Depends: + libgnutls-dev + libgnutls-dev + zoneminder + yaskkserv + tf5 + ssmtp + snowdrop + sngrep + slrnpull + slrn + sipsak + macopix-gtk2 + gnss-sdr + gkrellm + freewheeling + boinctui + iputils-ping + + 2: https://lists.debian.org/debian-devel-announce/2017/08/msg4.html + 3: https://blog.pcisecuritystandards.org/migrating-from-ssl-and-early-tls + 4: https://gnutls.org/manual/html_node/Priority-Strings.html + + + [Original issue description] + sSMTP is limited to using TLSv1.0 and the "old" ciphers that come with it. Here's a packet capture when ssmtp connects to smtp.sdeziel.info:587 that offers TLSv1.0 and higher: $ tshark -ta -Vr submission.pcap | sed -n '/^Frame 14:/,/^Frame 15:/ p' | grep -E '^[[:space:]]+(Version|Cipher|Handshake Protocol)' - Version: TLS 1.0 (0x0301) - Handshake Protocol: Client Hello - Version: TLS 1.0 (0x0301) - Cipher Suites Length: 30 - Cipher Suites (15 suites) - Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) - Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) - Cipher Suite: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0041) - Cipher Suite: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0084) - Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a) - Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033) - Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039) - Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0045) - Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0088) - Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016) - Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032) - Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038) - Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA (0x0044) - Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA (0x0087) - Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013) + Version: TLS 1.0 (0x0301) + Handshake Protocol: Client Hello + Version: TLS 1.0 (0x0301) + Cipher Suites Length: 30 + Cipher Suites (15 suites) + Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) + Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) + Cipher Suite: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0041) + Cipher Suite: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0084) + Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a) + Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033) + Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039) + Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0045) + Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0088) + Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016) + Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032) + Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038) + Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA (0x0044) + Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA (0x0087) + Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013) I would expect ssmtp to use TLSv1.2 and a recent cipher like the openssl s_client is able to do: $ echo | openssl s_client -connect smtp.sdeziel.info:587 -starttls smtp 2>/dev/null | grep -E '^[[:space:]]+(Protocol|Cipher)' - Protocol : TLSv1.2 - Cipher: ECDHE-RSA-AES128-GCM-SHA256 - + Protocol : TLSv1.2
[Touch-packages] [Bug 1709193] Re: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer
ACK on the trusty, xenial and zesty debdiffs. Uploaded for processing by the SRU team. Thanks! ** Changed in: gnutls26 (Ubuntu Trusty) Status: Confirmed => In Progress ** Changed in: gnutls28 (Ubuntu Xenial) Status: Confirmed => In Progress ** Changed in: gnutls28 (Ubuntu Zesty) Status: Confirmed => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gnutls26 in Ubuntu. https://bugs.launchpad.net/bugs/1709193 Title: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer Status in gnutls26 package in Ubuntu: Invalid Status in gnutls28 package in Ubuntu: Fix Committed Status in gnutls26 source package in Trusty: In Progress Status in gnutls28 source package in Trusty: Won't Fix Status in ssmtp source package in Trusty: Invalid Status in gnutls26 source package in Xenial: Invalid Status in gnutls28 source package in Xenial: In Progress Status in ssmtp source package in Xenial: Invalid Status in gnutls26 source package in Zesty: Invalid Status in gnutls28 source package in Zesty: In Progress Status in ssmtp source package in Zesty: Invalid Status in gnutls26 source package in Artful: Invalid Status in gnutls28 source package in Artful: Fix Committed Status in ssmtp source package in Artful: Invalid Status in gnutls28 package in Debian: Fix Released Bug description: sSMTP is limited to using TLSv1.0 and the "old" ciphers that come with it. Here's a packet capture when ssmtp connects to smtp.sdeziel.info:587 that offers TLSv1.0 and higher: $ tshark -ta -Vr submission.pcap | sed -n '/^Frame 14:/,/^Frame 15:/ p' | grep -E '^[[:space:]]+(Version|Cipher|Handshake Protocol)' Version: TLS 1.0 (0x0301) Handshake Protocol: Client Hello Version: TLS 1.0 (0x0301) Cipher Suites Length: 30 Cipher Suites (15 suites) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) Cipher Suite: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0041) Cipher Suite: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0084) Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039) Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0045) Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0088) Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016) Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032) Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038) Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA (0x0044) Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA (0x0087) Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013) I would expect ssmtp to use TLSv1.2 and a recent cipher like the openssl s_client is able to do: $ echo | openssl s_client -connect smtp.sdeziel.info:587 -starttls smtp 2>/dev/null | grep -E '^[[:space:]]+(Protocol|Cipher)' Protocol : TLSv1.2 Cipher: ECDHE-RSA-AES128-GCM-SHA256 Additional information: $ lsb_release -rd Description: Ubuntu 16.04.3 LTS Release: 16.04 $ apt-cache policy ssmtp libgnutls-openssl27 ssmtp: Installed: 2.64-8ubuntu1 Candidate: 2.64-8ubuntu1 Version table: *** 2.64-8ubuntu1 500 500 http://archive.ubuntu.com/ubuntu xenial/universe amd64 Packages 100 /var/lib/dpkg/status libgnutls-openssl27: Installed: 3.4.10-4ubuntu1.3 Candidate: 3.4.10-4ubuntu1.3 Version table: *** 3.4.10-4ubuntu1.3 500 500 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu xenial-security/main amd64 Packages 100 /var/lib/dpkg/status 3.4.10-4ubuntu1 500 500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: ssmtp 2.64-8ubuntu1 [modified: etc/ssmtp/revaliases] ProcVersionSignature: Ubuntu 4.4.0-89.112-generic 4.4.76 Uname: Linux 4.4.0-89-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.10 Architecture: amd64 Date: Mon Aug 7 18:13:33 2017 ProcEnviron: TERM=xterm PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: ssmtp UpgradeStatus: No upgrade log present (probably fresh install) modified.conffile..etc.ssmtp.revaliases: [modified] mtime.conffile..etc.ssmtp.revaliases: 2017-08-05T13:44:06.274302 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnutls26/+bug/1709193/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to :
[Touch-packages] [Bug 1709193] Re: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer
ACK on the artful debdiff. I've uploaded it now with a slight adjustment to put the bug numbers in the patch tags. Thanks! ** Changed in: gnutls28 (Ubuntu Artful) Status: Confirmed => Fix Committed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gnutls26 in Ubuntu. https://bugs.launchpad.net/bugs/1709193 Title: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer Status in gnutls26 package in Ubuntu: Invalid Status in gnutls28 package in Ubuntu: Fix Committed Status in gnutls26 source package in Trusty: Confirmed Status in gnutls28 source package in Trusty: Won't Fix Status in ssmtp source package in Trusty: Invalid Status in gnutls26 source package in Xenial: Invalid Status in gnutls28 source package in Xenial: Confirmed Status in ssmtp source package in Xenial: Invalid Status in gnutls26 source package in Zesty: Invalid Status in gnutls28 source package in Zesty: Confirmed Status in ssmtp source package in Zesty: Invalid Status in gnutls26 source package in Artful: Invalid Status in gnutls28 source package in Artful: Fix Committed Status in ssmtp source package in Artful: Invalid Status in gnutls28 package in Debian: Fix Released Bug description: sSMTP is limited to using TLSv1.0 and the "old" ciphers that come with it. Here's a packet capture when ssmtp connects to smtp.sdeziel.info:587 that offers TLSv1.0 and higher: $ tshark -ta -Vr submission.pcap | sed -n '/^Frame 14:/,/^Frame 15:/ p' | grep -E '^[[:space:]]+(Version|Cipher|Handshake Protocol)' Version: TLS 1.0 (0x0301) Handshake Protocol: Client Hello Version: TLS 1.0 (0x0301) Cipher Suites Length: 30 Cipher Suites (15 suites) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) Cipher Suite: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0041) Cipher Suite: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0084) Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039) Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0045) Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0088) Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016) Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032) Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038) Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA (0x0044) Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA (0x0087) Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013) I would expect ssmtp to use TLSv1.2 and a recent cipher like the openssl s_client is able to do: $ echo | openssl s_client -connect smtp.sdeziel.info:587 -starttls smtp 2>/dev/null | grep -E '^[[:space:]]+(Protocol|Cipher)' Protocol : TLSv1.2 Cipher: ECDHE-RSA-AES128-GCM-SHA256 Additional information: $ lsb_release -rd Description: Ubuntu 16.04.3 LTS Release: 16.04 $ apt-cache policy ssmtp libgnutls-openssl27 ssmtp: Installed: 2.64-8ubuntu1 Candidate: 2.64-8ubuntu1 Version table: *** 2.64-8ubuntu1 500 500 http://archive.ubuntu.com/ubuntu xenial/universe amd64 Packages 100 /var/lib/dpkg/status libgnutls-openssl27: Installed: 3.4.10-4ubuntu1.3 Candidate: 3.4.10-4ubuntu1.3 Version table: *** 3.4.10-4ubuntu1.3 500 500 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu xenial-security/main amd64 Packages 100 /var/lib/dpkg/status 3.4.10-4ubuntu1 500 500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: ssmtp 2.64-8ubuntu1 [modified: etc/ssmtp/revaliases] ProcVersionSignature: Ubuntu 4.4.0-89.112-generic 4.4.76 Uname: Linux 4.4.0-89-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.10 Architecture: amd64 Date: Mon Aug 7 18:13:33 2017 ProcEnviron: TERM=xterm PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: ssmtp UpgradeStatus: No upgrade log present (probably fresh install) modified.conffile..etc.ssmtp.revaliases: [modified] mtime.conffile..etc.ssmtp.revaliases: 2017-08-05T13:44:06.274302 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnutls26/+bug/1709193/+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 1709193] Re: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer
** Also affects: ssmtp (Ubuntu Artful) Importance: Undecided Status: Invalid ** Also affects: gnutls26 (Ubuntu Artful) Importance: Undecided Status: New ** Also affects: gnutls28 (Ubuntu Artful) Importance: Undecided Status: New ** Also affects: ssmtp (Ubuntu Trusty) Importance: Undecided Status: New ** Also affects: gnutls26 (Ubuntu Trusty) Importance: Undecided Status: New ** Also affects: gnutls28 (Ubuntu Trusty) Importance: Undecided Status: New ** Also affects: ssmtp (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: gnutls26 (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: gnutls28 (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: ssmtp (Ubuntu Zesty) Importance: Undecided Status: New ** Also affects: gnutls26 (Ubuntu Zesty) Importance: Undecided Status: New ** Also affects: gnutls28 (Ubuntu Zesty) Importance: Undecided Status: New ** Changed in: gnutls26 (Ubuntu Trusty) Status: New => Confirmed ** Changed in: gnutls26 (Ubuntu Xenial) Status: New => Invalid ** Changed in: gnutls26 (Ubuntu Zesty) Status: New => Invalid ** Changed in: gnutls26 (Ubuntu Artful) Status: New => Invalid ** Changed in: ssmtp (Ubuntu Trusty) Status: New => Invalid ** Changed in: ssmtp (Ubuntu Xenial) Status: New => Invalid ** No longer affects: ssmtp (Ubuntu) ** Changed in: ssmtp (Ubuntu Zesty) Status: New => Invalid ** Changed in: gnutls28 (Ubuntu Trusty) Status: New => Won't Fix ** Changed in: gnutls28 (Ubuntu Xenial) Status: New => Confirmed ** Changed in: gnutls28 (Ubuntu Zesty) Status: New => Confirmed ** Changed in: gnutls28 (Ubuntu Artful) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gnutls26 in Ubuntu. https://bugs.launchpad.net/bugs/1709193 Title: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer Status in gnutls26 package in Ubuntu: Invalid Status in gnutls28 package in Ubuntu: Confirmed Status in gnutls26 source package in Trusty: Confirmed Status in gnutls28 source package in Trusty: Won't Fix Status in ssmtp source package in Trusty: Invalid Status in gnutls26 source package in Xenial: Invalid Status in gnutls28 source package in Xenial: Confirmed Status in ssmtp source package in Xenial: Invalid Status in gnutls26 source package in Zesty: Invalid Status in gnutls28 source package in Zesty: Confirmed Status in ssmtp source package in Zesty: Invalid Status in gnutls26 source package in Artful: Invalid Status in gnutls28 source package in Artful: Confirmed Status in ssmtp source package in Artful: Invalid Status in gnutls28 package in Debian: Fix Released Bug description: sSMTP is limited to using TLSv1.0 and the "old" ciphers that come with it. Here's a packet capture when ssmtp connects to smtp.sdeziel.info:587 that offers TLSv1.0 and higher: $ tshark -ta -Vr submission.pcap | sed -n '/^Frame 14:/,/^Frame 15:/ p' | grep -E '^[[:space:]]+(Version|Cipher|Handshake Protocol)' Version: TLS 1.0 (0x0301) Handshake Protocol: Client Hello Version: TLS 1.0 (0x0301) Cipher Suites Length: 30 Cipher Suites (15 suites) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) Cipher Suite: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0041) Cipher Suite: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0084) Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039) Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0045) Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0088) Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016) Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032) Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038) Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA (0x0044) Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA (0x0087) Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013) I would expect ssmtp to use TLSv1.2 and a recent cipher like the openssl s_client is able to do: $ echo | openssl s_client -connect smtp.sdeziel.info:587 -starttls smtp 2>/dev/null | grep -E '^[[:space:]]+(Protocol|Cipher)' Protocol : TLSv1.2 Cipher: ECDHE-RSA-AES128-GCM-SHA256 Additional information: $ lsb_release -rd Description: Ubuntu 16.04.3 LTS Release: 16.04 $ apt-cache policy
[Touch-packages] [Bug 1709193] Re: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer
** Changed in: gnutls28 (Debian) Status: Unknown => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gnutls26 in Ubuntu. https://bugs.launchpad.net/bugs/1709193 Title: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer Status in gnutls26 package in Ubuntu: New Status in gnutls28 package in Ubuntu: New Status in ssmtp package in Ubuntu: Invalid Status in gnutls28 package in Debian: Fix Released Bug description: sSMTP is limited to using TLSv1.0 and the "old" ciphers that come with it. Here's a packet capture when ssmtp connects to smtp.sdeziel.info:587 that offers TLSv1.0 and higher: $ tshark -ta -Vr submission.pcap | sed -n '/^Frame 14:/,/^Frame 15:/ p' | grep -E '^[[:space:]]+(Version|Cipher|Handshake Protocol)' Version: TLS 1.0 (0x0301) Handshake Protocol: Client Hello Version: TLS 1.0 (0x0301) Cipher Suites Length: 30 Cipher Suites (15 suites) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) Cipher Suite: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0041) Cipher Suite: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0084) Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039) Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0045) Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0088) Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016) Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032) Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038) Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA (0x0044) Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA (0x0087) Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013) I would expect ssmtp to use TLSv1.2 and a recent cipher like the openssl s_client is able to do: $ echo | openssl s_client -connect smtp.sdeziel.info:587 -starttls smtp 2>/dev/null | grep -E '^[[:space:]]+(Protocol|Cipher)' Protocol : TLSv1.2 Cipher: ECDHE-RSA-AES128-GCM-SHA256 Additional information: $ lsb_release -rd Description: Ubuntu 16.04.3 LTS Release: 16.04 $ apt-cache policy ssmtp libgnutls-openssl27 ssmtp: Installed: 2.64-8ubuntu1 Candidate: 2.64-8ubuntu1 Version table: *** 2.64-8ubuntu1 500 500 http://archive.ubuntu.com/ubuntu xenial/universe amd64 Packages 100 /var/lib/dpkg/status libgnutls-openssl27: Installed: 3.4.10-4ubuntu1.3 Candidate: 3.4.10-4ubuntu1.3 Version table: *** 3.4.10-4ubuntu1.3 500 500 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu xenial-security/main amd64 Packages 100 /var/lib/dpkg/status 3.4.10-4ubuntu1 500 500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: ssmtp 2.64-8ubuntu1 [modified: etc/ssmtp/revaliases] ProcVersionSignature: Ubuntu 4.4.0-89.112-generic 4.4.76 Uname: Linux 4.4.0-89-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.10 Architecture: amd64 Date: Mon Aug 7 18:13:33 2017 ProcEnviron: TERM=xterm PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: ssmtp UpgradeStatus: No upgrade log present (probably fresh install) modified.conffile..etc.ssmtp.revaliases: [modified] mtime.conffile..etc.ssmtp.revaliases: 2017-08-05T13:44:06.274302 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnutls26/+bug/1709193/+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 1709193] Re: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer
** Patch added: "lp1709193-14.04.debdiff" https://bugs.launchpad.net/ubuntu/+source/gnutls26/+bug/1709193/+attachment/4930182/+files/lp1709193-14.04.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gnutls26 in Ubuntu. https://bugs.launchpad.net/bugs/1709193 Title: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer Status in gnutls26 package in Ubuntu: New Status in gnutls28 package in Ubuntu: New Status in ssmtp package in Ubuntu: Invalid Status in gnutls28 package in Debian: Unknown Bug description: sSMTP is limited to using TLSv1.0 and the "old" ciphers that come with it. Here's a packet capture when ssmtp connects to smtp.sdeziel.info:587 that offers TLSv1.0 and higher: $ tshark -ta -Vr submission.pcap | sed -n '/^Frame 14:/,/^Frame 15:/ p' | grep -E '^[[:space:]]+(Version|Cipher|Handshake Protocol)' Version: TLS 1.0 (0x0301) Handshake Protocol: Client Hello Version: TLS 1.0 (0x0301) Cipher Suites Length: 30 Cipher Suites (15 suites) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) Cipher Suite: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0041) Cipher Suite: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0084) Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039) Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0045) Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0088) Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016) Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032) Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038) Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA (0x0044) Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA (0x0087) Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013) I would expect ssmtp to use TLSv1.2 and a recent cipher like the openssl s_client is able to do: $ echo | openssl s_client -connect smtp.sdeziel.info:587 -starttls smtp 2>/dev/null | grep -E '^[[:space:]]+(Protocol|Cipher)' Protocol : TLSv1.2 Cipher: ECDHE-RSA-AES128-GCM-SHA256 Additional information: $ lsb_release -rd Description: Ubuntu 16.04.3 LTS Release: 16.04 $ apt-cache policy ssmtp libgnutls-openssl27 ssmtp: Installed: 2.64-8ubuntu1 Candidate: 2.64-8ubuntu1 Version table: *** 2.64-8ubuntu1 500 500 http://archive.ubuntu.com/ubuntu xenial/universe amd64 Packages 100 /var/lib/dpkg/status libgnutls-openssl27: Installed: 3.4.10-4ubuntu1.3 Candidate: 3.4.10-4ubuntu1.3 Version table: *** 3.4.10-4ubuntu1.3 500 500 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu xenial-security/main amd64 Packages 100 /var/lib/dpkg/status 3.4.10-4ubuntu1 500 500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: ssmtp 2.64-8ubuntu1 [modified: etc/ssmtp/revaliases] ProcVersionSignature: Ubuntu 4.4.0-89.112-generic 4.4.76 Uname: Linux 4.4.0-89-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.10 Architecture: amd64 Date: Mon Aug 7 18:13:33 2017 ProcEnviron: TERM=xterm PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: ssmtp UpgradeStatus: No upgrade log present (probably fresh install) modified.conffile..etc.ssmtp.revaliases: [modified] mtime.conffile..etc.ssmtp.revaliases: 2017-08-05T13:44:06.274302 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnutls26/+bug/1709193/+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 1709193] Re: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer
** Patch added: "lp1709193-17.04.debdiff" https://bugs.launchpad.net/ubuntu/+source/gnutls28/+bug/1709193/+attachment/4930181/+files/lp1709193-17.04.debdiff ** Also affects: gnutls26 (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gnutls26 in Ubuntu. https://bugs.launchpad.net/bugs/1709193 Title: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer Status in gnutls26 package in Ubuntu: New Status in gnutls28 package in Ubuntu: New Status in ssmtp package in Ubuntu: Invalid Status in gnutls28 package in Debian: Unknown Bug description: sSMTP is limited to using TLSv1.0 and the "old" ciphers that come with it. Here's a packet capture when ssmtp connects to smtp.sdeziel.info:587 that offers TLSv1.0 and higher: $ tshark -ta -Vr submission.pcap | sed -n '/^Frame 14:/,/^Frame 15:/ p' | grep -E '^[[:space:]]+(Version|Cipher|Handshake Protocol)' Version: TLS 1.0 (0x0301) Handshake Protocol: Client Hello Version: TLS 1.0 (0x0301) Cipher Suites Length: 30 Cipher Suites (15 suites) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) Cipher Suite: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0041) Cipher Suite: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0084) Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039) Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0045) Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0088) Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016) Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032) Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038) Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA (0x0044) Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA (0x0087) Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013) I would expect ssmtp to use TLSv1.2 and a recent cipher like the openssl s_client is able to do: $ echo | openssl s_client -connect smtp.sdeziel.info:587 -starttls smtp 2>/dev/null | grep -E '^[[:space:]]+(Protocol|Cipher)' Protocol : TLSv1.2 Cipher: ECDHE-RSA-AES128-GCM-SHA256 Additional information: $ lsb_release -rd Description: Ubuntu 16.04.3 LTS Release: 16.04 $ apt-cache policy ssmtp libgnutls-openssl27 ssmtp: Installed: 2.64-8ubuntu1 Candidate: 2.64-8ubuntu1 Version table: *** 2.64-8ubuntu1 500 500 http://archive.ubuntu.com/ubuntu xenial/universe amd64 Packages 100 /var/lib/dpkg/status libgnutls-openssl27: Installed: 3.4.10-4ubuntu1.3 Candidate: 3.4.10-4ubuntu1.3 Version table: *** 3.4.10-4ubuntu1.3 500 500 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu xenial-security/main amd64 Packages 100 /var/lib/dpkg/status 3.4.10-4ubuntu1 500 500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: ssmtp 2.64-8ubuntu1 [modified: etc/ssmtp/revaliases] ProcVersionSignature: Ubuntu 4.4.0-89.112-generic 4.4.76 Uname: Linux 4.4.0-89-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.10 Architecture: amd64 Date: Mon Aug 7 18:13:33 2017 ProcEnviron: TERM=xterm PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: ssmtp UpgradeStatus: No upgrade log present (probably fresh install) modified.conffile..etc.ssmtp.revaliases: [modified] mtime.conffile..etc.ssmtp.revaliases: 2017-08-05T13:44:06.274302 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnutls26/+bug/1709193/+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