id,summary,reporter,owner,description,type,status,priority,component,resolution,keywords,cc,component_version,os,os_version 7864,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."" ",Bug report,closed,normal,FileZilla Client,fixed,"ClientHello, TLSv1.2",,,Windows,Windows 7