Bug#466477: bluepages.ibm.com

[Simon Josefsson]

Richard A Nelson <cowboy at debian.org> writes:

> On Sat, 11 Oct 2008, Simon Josefsson wrote:
>
>> I believe we may be close to understanding this entire bug report now.
>
> Cool ;)

At least I understand the three _other_ problems reported in this bug
now...

>> The remaining step is to check whether bluepages.ibm.com exhibits either
>> one of the two last problems.  However, the server isn't accessible on
>> the Internet.  Richard, can you test these two commands?
>>
>> gnutls-cli -p 636 bluepages.ibm.com -d 4711 --priority NORMAL:-VERS-TLS1.1
>
> I had one success, out of >dozen tries - the rest returned
>
> *** Fatal error: A TLS packet with unexpected length was received.
> *** Handshake has failed
>
>> gnutls-cli -p 636 bluepages.ibm.com -d 4711 --priority NORMAL:%COMPAT
>
> no success at all
>
> *** Fatal error: A TLS packet with unexpected length was received.
> *** Handshake has failed

Ok.  The random success is interesting.  Could you try this:

gnutls-cli -p 636 bluepages.ibm.com -d 4711 --priority NORMAL:%COMPAT:-VERS-TLS1.1

Maybe it doesn't like TLS 1.1 _and_ doesn't like record padding.  later:
Reading your logs suggests this will not work, record padding is only
effective after handshake is complete.

Btw, could you also try this command:

gnutls-cli -p 636 bluepages.ibm.com -d 4711 --priority NORMAL:%COMPAT:-VERS-TLS1.1:-VERS-TLS1.0

That forces SSL 3.0.

If that doesn't work, try:

gnutls-cli -p 636 bluepages.ibm.com -d 4711 --priority NORMAL:%COMPAT:-VERS-TLS1.1:-VERS-TLS1.0 --disable-extensions

That was claimed to work before in this bug report, but using somewhat
different parameters.

Please post logs of these three commands.

>> If neither of them succeeds, please post the output from both commands.
>> Then we'll have to continue debug the problem...
>
> Attached

This suggest there is a pretty fundamental problem, the server
disconnects after seeing client hello.  Maybe the CERT_TYPE or the
SERVER_NAME extension triggers the bug.

>> If either of these commands succeeds, let us know which.  If so, I
>> believe that shows the server to be buggy, and that you now know of a
>> workaround.  Then we can close the bug.
>
> Well, the problem with, were it so - is the bug would then need to
> re-assigned to openldap such that we have a way to specify the
> workaround in the slapd.conf and ldap.conf files

I believe that's fixed already, use 'TLSCipherSuite' with a GnuTLS
priority string.

However, I'd like to understand why GnuTLS can't connect to the server
first.

>> I really hope we can close this report.
>
> Ditto, for the nonce, I've had to resorted to rebuilding openldap against
> openssl :(

Olivier Eymere said he was able to connect to the server using SSL 3.0,
so I think you should be able to use openldap+gnutls with a priority
string such as:

NORMAL:%COMPAT:-VERS-TLS1.1:-VERS-TLS1.0

However, maybe the problem is with some extension.  Then maybe disabling
that extension should be sufficient, and you don't need to disable TLS
1.0.

/Simon