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? _______________________________________________ Gnutls-help mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnutls-help
