[gnutls-help] The signature_algorithms extension and login.live.com

Nikos Mavrogiannopoulos nmav at gnutls.org
Thu Sep 11 12:02:29 CEST 2014


On Wed, Sep 10, 2014 at 8:43 PM, Mark Doliner <mark at kingant.net> wrote:
> Hi! I work on the instant messaging program Pidgin. I'm fiddling with
> the priority string that we pass to gnutls_priority_init(), trying to
> find a value that disables weaker ciphers while remaining compatible
> with the majority of servers.

Well, I'd suggest in using each versions NORMAL:%COMPAT option in that
case (or gnutls_priority_set_default()). The ciphers are prioritized
by security margin and remain compatible with the majority if not all
of the servers (I think your use case is the exact reason for the
default settings).

> I'm seeing weirdness trying to connect to login.live.com. You might be
> able to test the below priority strings using this command:
>> gnutls-cli --priority "<PRIORITY STRING>" login.live.com
> But note that on my version of Ubuntu, at least, gnutls-cli is linked
> against GnuTLS 2.12.23, which is old and has different behavior than
> 3.2.11.
>
> Anyway. So login.live.com.
> This priority string works: NORMAL
> This priority string does not work: SECURE128
> The remote server sends TCP RST and does not continue TLS negotiation.
> The server seems to be picky about the signature algorithms that we
> advertise. Specifically it seems to need SIGN-RSA-SHA1.

The SECURE128 in latest versions disables support for SHA1 as
signature algorithm (its strength is estimated to less than 80 bits).
So if the server only supports SHA1, it would require it.

> This priority string works: SECURE128:+SIGN-RSA-SHA1
> Is that weird? Is TCP RST the appropriate server response?

Not really, I'd expect an alert there; but there are cases where some
unexpected code path is executed on the server, and you may see some
inappropriate closures.

> Related question:
> RFC5246 section 7.4.1.4.1. Signature Algorithms says "this extension
> is not meaningful for TLS versions prior to 1.2. Clients MUST NOT
> offer it if they are offering prior versions." However it looks like
> GnuTLS sends the signature algorithms extension even when it sends a
> version of SSL 3.0. Seems like it should only send the extension when
> version is TLS 1.2 or higher. Is that a bug? Am I misinterpreting the
> spec?

Does this happen with the gnutls 3.x versions or is it only in 2.12.x?

regards,
Nikos



More information about the Gnutls-help mailing list