Bug#466477: bluepages.ibm.com

[Simon Josefsson]

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

>> 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
>
> This one works (and more than once) ;)

Great.  Maybe %COMPAT isn't even needed, could you try:

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

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.

>> 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.
>
> That has been my estimation of the failure

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

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

If that works, I think we have finally identified that the server does
not cope well with the cert_type extension.

>> NORMAL:%COMPAT:-VERS-TLS1.1:-VERS-TLS1.0
>
> I'll give that a shot on a test machine

Please do, it might save you some re-compiles...

>> 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.
>
> Indeed, it'd be nice to drop just the problematic extension, if feasible

I'm somewhat puzzled that openldap would send the OpenPGP extension
though -- gnutls-cli does because it supports TLS-OpenPGP, but I don't
think openldap does.  Maybe openldap doesn't.  And that instead openldap
just sends the server_name extension support, and that is the
problematic extension. Or the problem could be just _any_ extension.  If
so, I don't think there is a priority string that would disable all
extensions but still use, say, TLS 1.0.  Maybe we should look into
adding a flag like that...

/Simon