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

[Nikos Mavrogiannopoulos]

On Thu, 2014-09-11 at 16:44 -0700, Mark Doliner wrote:
> On Thu, Sep 11, 2014 at 3:02 AM, Nikos Mavrogiannopoulos
> <nmav at gnutls.org> wrote:
> > 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).
> 
> Hmm, yeah, using NORMAL is very reasonable. I would certainly prefer
> if we could use the default, but it does seem like we can improve
> things slightly by using a custom string. I checked in a change to our
> development branch for now to use a custom string. Assuming no one has
> problems with it I think it's likely we'll release it at some point.
> But I don't have strong feelings either way and I could be persuaded
> to switch back to NORMAL.
> The string I used is:
> SECURE192:+SECURE128:-RSA:+RSA:+SIGN-RSA-SHA1:-DHE-DSS:-VERS-SSL3.0
> I wrote a really long comment explaining my reasoning, if you're curious:
> https://hg.pidgin.im/pidgin/main/rev/76a2a6d75768

Hello,
 It seems reasonable, although the "-RSA:+RSA" looks like a typo.
I'll just note that if custom strings are used it may make sense to
allow the user to switch to the normal level (I haven't checked if
that's already possible), because there always are obscure servers that
have old or strange configurations. If on the other hand you communicate
with a small set of servers that you know that string is ok, then that
may not make much sense (then you only need to care about the ssl
interceptors used in some companies).

> >> 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?
> If I'm interpreting Wireshark correctly, yes. I see it happen with
> GnuTLS 2.12.23, 3.2.11, 3.2.17, and 3.3.7.

I've tried the following:
./gnutls-cli localhost --priority NORMAL:-VERS-TLS1.2
and there is no signature algorithms extension present. Note that the
version to be negotiated is in the "Handshake Protocol: Client Hello"
part of the packet. The version in the record layer is to indicate the
format of the record packet.

regards,
Nikos