Bug#466477: bluepages.ibm.com

[Simon Josefsson]

Simon Josefsson <simon at josefsson.org> writes:

>>> 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...

I was wrong, it doesn't work like that.  GnuTLS doesn't send the
server_name extension by default, the application needs to call
gnutls_server_name_set explicitly to enable it.  For gnutls-cli, you can
use --disable-extensions to avoid sending the server name:

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

To disable both cert_type and server_name use:

gnutls-cli -d 4711 -p 443 yxa.extundo.com --priority NORMAL:-VERS-TLS1.1:-CTYPE-OPENPGP --disable-extensions

Maybe TLS 1.1 isn't the problem, if so this should work:

gnutls-cli -d 4711 -p 443 yxa.extundo.com --priority NORMAL:-CTYPE-OPENPGP --disable-extensions

I really hope one of these commands work.  I think it would mean we
understand the server's bug, and know how to work around it without
resorting to falling back to SSL 3.0.

/Simon