[Group.of.nepali.translators] [Bug 1709193] Re: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer
there's a new upload for trusty, for bug 1444656 closing this one ** Changed in: gnutls26 (Ubuntu Trusty) Status: Fix Committed => Won't Fix -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs 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: Won't Fix Status in gnutls28 source package in Trusty: Won't Fix Status in gnutls28 source package in Xenial: Fix Released 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: 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 xen
[Group.of.nepali.translators] [Bug 1709193] Re: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer
This bug was fixed in the package gnutls28 - 3.4.10-4ubuntu1.4 --- gnutls28 (3.4.10-4ubuntu1.4) xenial; 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 Deziel Mon, 07 Aug 2017 23:04:43 + ** Changed in: gnutls28 (Ubuntu Xenial) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs 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 Released 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: 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: ***
[Group.of.nepali.translators] [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 नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs 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
[Group.of.nepali.translators] [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 Deziel Thu, 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 नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs 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 -co
[Group.of.nepali.translators] [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 Deziel Thu, 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 नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs 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 s
[Group.of.nepali.translators] [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 नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs 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: 1