[gnutls-help] The signature_algorithms extension and login.live.com
Mark Doliner
mark at kingant.net
Wed Sep 10 20:43:06 CEST 2014
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.
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.
This priority string works: SECURE128:+SIGN-RSA-SHA1
Is that weird? Is TCP RST the appropriate server response? This isn't
a major problem for me... part of my motivation for mentioning it here
is that I thought it might be interesting to you.
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?
More information about the Gnutls-help
mailing list