[Touch-packages] [Bug 1709193] Re: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer

[Mathew Hodson]

** 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

[Tyler Hicks]

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

[Simon Déziel]

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

[Julian Andres Klode]

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

[Julian Andres Klode]

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

[Simon Déziel]

@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

[Julian Andres Klode]

@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

[Julian Andres Klode]

@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

[Simon Déziel]

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

[Tyler Hicks]

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

[Tyler Hicks]

@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

[Simon Déziel]

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

[Andy Whitcroft]

@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

[Julian Andres Klode]

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

[Launchpad Bug Tracker]

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 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

[Simon Déziel]

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

[Simon Déziel]

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

[Simon Déziel]

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

[Simon Déziel]

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

[Brian Murray]

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

[Launchpad Bug Tracker]

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 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

[Simon Déziel]

** 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

[Marc Deslauriers]

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

[Marc Deslauriers]

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

[Marc Deslauriers]

** 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

[Bug Watch Updater]

** 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

[Simon Déziel]

** 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

[Simon Déziel]

** 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