Bug#466477: bluepages.ibm.com
Simon Josefsson
simon at josefsson.org
Sun Oct 12 18:43:03 UTC 2008
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
More information about the Pkg-gnutls-maint
mailing list