[Pkg-gnutls-maint] Bug#466477: Bug#466477: Bug#466477: libgnutls26: Failure to talk with IBM ldap/http servers

[Marc F. Clemente]

Simon Josefsson wrote:
> Thanks for reporting this, I've solved it with patch:
> http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=08fe3bfac8e12e6154dce6a834cdf838eeac3b05

I tried to install the patch, but I had problems.  I found socket_bye at 
lines 655 and 719.  I commented both instances out, and recompiled.  It 
still crashes, but it does not give the backtrace.

> Your problem is quite similar to <http://bugs.debian.org/429183>.

I had not seen that bug report, because it was for gnutls13 and it is a 
bit old.  Let me give you a bit more history.  I use debian unstable and 
I run an exim mail server (mail.mclemente.net).  The mail server 
receives mail from a MS Exchange server.  On 3/29/08 and on 4/14/08, I 
did upgrades.  Right after the 4/14/08 upgrade, exim stopped receiving 
mail from the Exchange server (A TLS packet with unexpected length was 
received.)  I had not messed with the exchange server in months.  I also 
started getting the same error when other servers on the internet tried 
to use TLS.  Some of my MUAs (Thunderbird and Seamonkey) kept working, 
but the Outlook Mobile on my Treo stopped working.

At first, I thought the problem was with libgnutls13, because on 4/14/08 
it was upgraded from 2.0.4-3 to 2.0.4-3+b1.  But then I realized that 
exim uses libgnutls26.  But libgnutls26 did not get upgraded.  I 
downgraded libgnutls13 anyway, but that made no difference.  Then I 
purged libgnutls13, and that made no difference either.

So I still think the problem is in the library.  The gnutls-cli bug is 
just incidental (and separate).  It makes debugging the library problem 
more difficult.  My problem is very reproducible, but at this moment, I 
don't know how to fix it.  I am sure my upgrade on 4/14/08 is the 
culprit, but I don't know what to downgrade.

I figured out that Thunderbird (which works) uses 
DHE_RSA_AES_256_CBC_SHA1, whatever that means.  MS Exchange and MS 
Outlook Mobile use RSA_ARCFOUR_MD5.  Maybe the problem is with the cipher?

So, assuming that gnutls-cli is just broken, I try to use openssl, and I 
get somewhere:

wcrg-server:~> openssl s_client -connect mail3.mclemente.net:25 
-starttls smtp -cipher EXP-RC4-MD5
CONNECTED(00000003)
14906:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake 
failure:s23_lib.c:188:

Exit 1
wcrg-server:~> openssl s_client -connect mail3.mclemente.net:25 
-starttls smtp -cipher DHE-RSA-AES256-SHA
CONNECTED(00000003)
depth=0 /CN=mail.mclemente.net
verify error:num=18:self signed certificate
verify return:1
depth=0 /CN=mail.mclemente.net
verify return:1
---
Certificate chain
  0 s:/CN=mail.mclemente.net
    i:/CN=mail.mclemente.net
---
Server certificate
-----BEGIN CERTIFICATE-----
...
...
...
-----END CERTIFICATE-----
subject=/CN=mail.mclemente.net
issuer=/CN=mail.mclemente.net
---
Acceptable client certificate CA names
...
...
...
---
SSL handshake has read 20515 bytes and written 291 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 1024 bit
Compression: NONE
Expansion: NONE
SSL-Session:
     Protocol  : TLSv1
     Cipher    : DHE-RSA-AES256-SHA
     Session-ID: ...
     Session-ID-ctx:
     Master-Key: ...
     Key-Arg   : None
     Start Time: 1208550271
     Timeout   : 300 (sec)
     Verify return code: 18 (self signed certificate)
---
250 HELP
quit
221 mail3.mclemente.net closing connection
closed

The problem is not with the openssl client, because the following 
command works.

wcrg-server:~> openssl s_client -connect e31.co.us.ibm.com:25 -starttls 
smtp -cipher EXP-RC4-MD5

But to confuse things some, the following command also works.

wcrg-server:~> openssl s_client -connect mail3.mclemente.net:25 
-starttls smtp -cipher RC4-MD5

> However, your problem seems different from the original report in this
> bug: that problem (if it was a real problem, the original reporter
> hasn't replied and we can't reproduce it) appears to be in the library
> and not in gnutls-cli.

So maybe my problem is different.  As far as I can tell, the bug is in 
the library (or a dependency). EXP-RC4-MD5 is a no-go, but other ciphers 
are ok.

Where do I go form here?  You (or anybody else) is welcome to use my 
server (mail3.mclemente.net) for testing.  Let me know what I have to do 
to help resolve my issue.  In my spare time, I will try and downgrade 
some packages to see what happens.

Thanks,
Marc