Bug#466477: bluepages.ibm.com

[Simon Josefsson]

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

> On Sun, 12 Oct 2008, Simon Josefsson wrote:
>
>> gnutls-cli -p 636 bluepages.ibm.com -d 4711 --priority NORMAL:-VERS-TLS1.1:-VERS-TLS1.0
>
> works

Ok, that means SSL 3.0 works.

>> No need to post logs if that works.  You may need to transfer some
>> application data to trigger the record padding problem though, so you
>> might not see failures with gnutls-cli if you remove %COMPAT.
>
> So the final test would need a modified ldap.conf and an actual query
> (not just the simple gnutls-client) ?

Sending just some garbage might be enough: if you get a error from the
LDAP code, all is fine, but if the TLS library disconnects you, then the
TLS code doesn't handle record padding.

>> It is possible to disable the CERT_TYPE extension by using a priority of
>> -CTYPE-OPENPGP.  So would this work:
>>
>> gnutls-cli -p 636 bluepages.ibm.com -d 4711 --priority NORMAL:-VERS-TLS1.1:-CTYPE-OPENPGP
>
> *** Fatal error: A TLS packet with unexpected length was received.
> *** Handshake has failed
> GNUTLS ERROR: A TLS packet with unexpected length was received.

So either the problem is TLS 1.0 or the server_name extension.

>> If so, maybe you could try to enable TLS 1.1 as well:
>>
>> gnutls-cli -p 636 bluepages.ibm.com -d 4711 --priority NORMAL:-CTYPE-OPENPGP
>
> *** Fatal error: A TLS packet with unexpected length was received.
> *** Handshake has failed
> GNUTLS ERROR: A TLS packet with unexpected length was received.

Since the previous test failed, that is expected.

/Simon