Signature Algorithms extension of ClientHello incomplete.

[Jim Heit]

FileZilla Client sends a TLSv1.2 (RFC 5246) ClientHello. TLSv1.2 requires servers to accept a Signature Algorithms extension on a ClientHello message, and gives the client the option to omit it if it desires the default (usually SHA1/RSA--see the RFC). FileZilla (using GnuTLS) is sending only one Signature Algorithms extension value--SHA512/RSA (6/1). This will cause a TLSV1.2 aware server to reject the ClientHello if it does not posses a SHA512/RSA signed certificate. Originally I thought this was a GnuTLS problem, so I sent this e-mail to them:

"Hello,
I have been working on the implementation of the TLS 1.2 protocol. TLS 1.2 requires servers to handle the Signature Algorithms extension to the ClientHello handshake message. My reading of RFC 5246 (7.4.1.4.1.) indicates that if client presents the extension (it can be omitted) it should include all hash/signature algorithm pairs the client is willing to process. While running the latest version of FileZilla, which uses GnuTLS 2.10.4, the only proposed Signature Algorithm is {SHA512,RSA}. If I stick with the RFC, the handshake will fail, as my {SHA1,RSA} signed certificate is not in the list.
I’m not saying Microsoft is always right (in this case I think they are), but IE8/Win7 sends 7 Signature Algorithms in the extension: {SHA256,RSA},{SHA384,RSA},{SHA1,RSA},{SHA256,ECDSA},{SHA384,ECDSA},{SHA1,ECDSA},{SHA1,DSA}."

The response I received from the GnuTLS developers was this:

"Hello,
This is a configuration issue. Filezilla for some reason unknown to me only enables 256-bit ciphersuites and signature algorithms. If you use gnutls-cli with your server you'll see that gnutls sends all options."

[janus]

Actually, the RFC does not require RSA,SHA1. This combination is just the default. Not supporting the default is perfectly fine (as filezilla does). On the other hand, it makes no much sense for filezilla to restrict to 256-bit ciphersuites.

[Jim Heit]

Yes, that combination is the default depending on the negotiated key exchange algorithm IF the signature algorithms extension IS NOT used. Here is a direct quote from the RFC "If the client supports only the default hash and signature algorithms (listed in this section), it MAY omit the signature_algorithms extension. If the client does not support the default algorithms, or supports other hash and signature algorithms (and is willing to use them for verifying messages sent by the server. i.e., server certificates and server key exchange), it MUST send the signature_algoritms extension, listing the algorithms it is willing to accept."
If you send the extension you MUST specify all the algorithms you are willing to accept. With your flawed interpretation there is no way to specify that you do not want to accept RSA,SHA1.

[Tim Kosse]

Will be fixed in the next version.