Bug#842120: tf5: TLSv1.1/1.2 cipher suites not functioning

[Russ Allbery]

Justin Coffman  writes:

> I tried my hand at generating a patch, but the patched version didn't
> exhibit behavior any different than current. I guess my GnuTLS-fu is not
> strong enough.

> The gotcha (I think) is in the way GnuTLS shims the SSLv23_client_method
> in its OpenSSL compatibility layer. The only other available shim is
> TLSv1_client_method, which seems to behave exactly the same way as it
> does currently.

Yeah, I took a quick look, and indeed, this is a mess.  All of the ways of
initializing the context in the compatibility layer enable at most TLS 1.0
and the SSL_CTX_set_cipher_list() function is stubbed out completely
(since GnuTLS uses a different syntax for cipher strings).

I suspect this would require fully porting tf5 to GnuTLS.  :(  Or fixing
the compat layer to not be as stupid about ciphers.

-- 
Russ Allbery (r...@debian.org)   

Bug#842120: tf5: TLSv1.1/1.2 cipher suites not functioning

[Justin Coffman]

>> Justin Coffman  writes:
>>
>> Package: tf5
>> Version: 5.0beta8-5+b1
>> Severity: important
>>
>> TinyFugue, when compiled from upstream source against OpenSSL, is 
>> capable of the full set of expected ciphersuites (up to and including 
>> TLSv1.2), such as those utilizing AES-GCM and EC Diffie-Hellman. The 
>> version packaged in Debian, compiled against GnuTLS, is only capable 
>> of
>> SSLv3/TLSv1 negotiation, and only then with servers that do not 
>> require (EC)DH negotiation. This could render the client unusable for 
>> servers that enforce more modern security policies.
>>
>> TinyFugue when compiled against OpenSSL:
>> % Connected to (unnamed1) using cipher ECDHE-RSA-AES128-GCM-SHA256.
>>
>> TinyFugue when compiled against GnuTLS, same site:
>> % Connected to (unnamed1) using cipher RSA_AES_128_CBC_SHA1.

> Unfortunately, it can't be compiled against OpenSSL and included in Debian 
> since the licenses conflict.  (Which is why it's built against
> GnuTLS.)  It's GPL without any license exception, so such a package would be 
> rejected by Debian ftpmaster.
>
> Sadly, upstream was contacted about this in the past and doesn't feel the 
> problem warrants the effort required to correct this, so there's basically no 
> chance that an OpenSSL build will be possible in Debian.
>
> Presumably there's some way to make GnuTLS negotiate the correct ciphers, but 
> unfortunately I don't know what it is off-hand, and probably won't have time 
> in the near future to do the necessary research.  Patches welcome!
>
> -- 
> Russ Allbery (r...@debian.org)   >

I tried my hand at generating a patch, but the patched version didn't exhibit 
behavior any different than current. I guess my GnuTLS-fu is not strong enough.

The gotcha (I think) is in the way GnuTLS shims the SSLv23_client_method in its 
OpenSSL compatibility layer. The only other available shim is 
TLSv1_client_method, which seems to behave exactly the same way as it does 
currently.

Bug#842120: tf5: TLSv1.1/1.2 cipher suites not functioning

[Russ Allbery]

Control: tags -1 help

Justin Coffman  writes:

> Package: tf5
> Version: 5.0beta8-5+b1
> Severity: important

> TinyFugue, when compiled from upstream source against OpenSSL, is
> capable of the full set of expected ciphersuites (up to and including
> TLSv1.2), such as those utilizing AES-GCM and EC Diffie-Hellman. The
> version packaged in Debian, compiled against GnuTLS, is only capable of
> SSLv3/TLSv1 negotiation, and only then with servers that do not require
> (EC)DH negotiation. This could render the client unusable for servers
> that enforce more modern security policies.

> TinyFugue when compiled against OpenSSL:
> % Connected to (unnamed1) using cipher ECDHE-RSA-AES128-GCM-SHA256.

> TinyFugue when compiled against GnuTLS, same site:
> % Connected to (unnamed1) using cipher RSA_AES_128_CBC_SHA1.

Unfortunately, it can't be compiled against OpenSSL and included in
Debian since the licenses conflict.  (Which is why it's built against
GnuTLS.)  It's GPL without any license exception, so such a package would
be rejected by Debian ftpmaster.

Sadly, upstream was contacted about this in the past and doesn't feel the
problem warrants the effort required to correct this, so there's basically
no chance that an OpenSSL build will be possible in Debian.

Presumably there's some way to make GnuTLS negotiate the correct ciphers,
but unfortunately I don't know what it is off-hand, and probably won't
have time in the near future to do the necessary research.  Patches
welcome!

-- 
Russ Allbery (r...@debian.org)   

Bug#842120: tf5: TLSv1.1/1.2 cipher suites not functioning

[Justin Coffman]

Package: tf5
Version: 5.0beta8-5+b1
Severity: important

TinyFugue, when compiled from upstream source against OpenSSL, is capable of 
the full set of expected 
ciphersuites (up to and including TLSv1.2), such as those utilizing AES-GCM and 
EC Diffie-Hellman. The 
version packaged in Debian, compiled against GnuTLS, is only capable of 
SSLv3/TLSv1 negotiation, and only 
then with servers that do not require (EC)DH negotiation. This could render the 
client unusable for servers 
that enforce more modern security policies.

TinyFugue when compiled against OpenSSL:
% Connected to (unnamed1) using cipher ECDHE-RSA-AES128-GCM-SHA256.

TinyFugue when compiled against GnuTLS, same site:
% Connected to (unnamed1) using cipher RSA_AES_128_CBC_SHA1.

-- System Information:
Debian Release: 8.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages tf5 depends on:
ii  libc62.19-18+deb8u6
ii  libgnutls-openssl27  3.3.8-6+deb8u3
ii  libpcre3 2:8.35-3.3+deb8u4
ii  libtinfo55.9+20140913-1+b1
ii  zlib1g   1:1.2.8.dfsg-2+b1

tf5 recommends no packages.

Versions of packages tf5 suggests:
pn  spell  

-- no debconf information