FileZilla client does not support SSL 3 or TLS 1.0

[Darron]

FileZilla client 3.2.7.1 sends a client hello specifying support for TLS 1.1 only. This means that servers that only support TLS 1.0 cannot negotiate a connection.

Neither SSL 3.0 or TLS 1.0 is considered seriously insecure at this time, and they are much more widely deployed than TLS 1.1, so they should be supported.

Details:

From the TLS 1.1 RFC:

Appendix E. Backward Compatibility with SSL

For historical reasons and in order to avoid a profligate consumption
of reserved port numbers, application protocols that are secured by
TLS 1.1, TLS 1.0, SSL 3.0, and SSL 2.0 all frequently share the same
connection port. For example, the https protocol (HTTP secured by
SSL or TLS) uses port 443 regardless of which security protocol it is
using. Thus, some mechanism must be determined to distinguish and
negotiate among the various protocols.

TLS versions 1.1 and 1.0, and SSL 3.0 are very similar; thus,
supporting both is easy. TLS clients who wish to negotiate with such
older servers SHOULD send client hello messages using the SSL 3.0
record format and client hello structure, sending {3, 2} for the
version field to note that they support TLS 1.1. If the server
supports only TLS 1.0 or SSL 3.0, it will respond with a downrev 3.0
server hello; if it supports TLS 1.1 it will respond with a TLS 1.1
server hello. The negotiation then proceeds as appropriate for the
negotiated protocol.

Similarly, a TLS 1.1 server that wishes to interoperate with TLS 1.0
or SSL 3.0 clients SHOULD accept SSL 3.0 client hello messages and
respond with a SSL 3.0 server hello if an SSL 3.0 client hello with a
version field of {3, 0} is received, denoting that this client does
not support TLS. Similarly, if a SSL 3.0 or TLS 1.0 hello with a
version field of {3, 1} is received, the server SHOULD respond with a
TLS 1.0 hello with a version field of {3, 1}.

From a WireShark packet capture:

Frame 8 (126 bytes on wire, 126 bytes captured)

Ethernet II, Src: CompalIn_88:54:36 (00:1b:38:88:54:36), Dst: Cisco_fb:b8:00 (00:14:f1:fb:b8:00)
Internet Protocol, Src: 10.20.69.248 (10.20.69.248), Dst: 10.20.239.21 (10.20.239.21)
Transmission Control Protocol, Src Port: gsi (1850), Dst Port: 11932 (11932), Seq: 11, Ack: 81, Len: 72
Secure Socket Layer

SSL Record Layer: Handshake Protocol: Client Hello

Content Type: Handshake (22)
Version: TLS 1.1 (0x0302) <-- This is the lowest version supported.
Length: 67
Handshake Protocol: Client Hello

Handshake Type: Client Hello (1)
Length: 63
Version: TLS 1.1 (0x0302) <-- And this is the preferred version.
Random
Session ID Length: 0
Cipher Suites Length: 24
Cipher Suites (12 suites)
Compression Methods Length: 1
Compression Methods (1 method)

[Tim Kosse]

Please read the specifications more carefully.

Preferred version != negotiated version.

Both client as server both send their highest supported (and thus preferred) versions in their Hello. The negotiated version is the lower of both should both parties accept.

[Darron]

I have read the TLS 1.1 and 1.2 RFC's carefully, but I think that I interpreted the 1.1 requirements on the TLS Record version (as distinct from the hello version) differently than you do.

I have found the following section of RFC 5246 (TLS 1.2):

Earlier versions of the TLS specification were not fully clear on
what the record layer version number (TLSPlaintext.version) should
contain when sending ClientHello (i.e., before it is known which
version of the protocol will be employed). Thus, TLS servers
compliant with this specification MUST accept any value {03,XX} as
the record layer version number for ClientHello.

TLS clients that wish to negotiate with older servers MAY send any
value {03,XX} as the record layer version number. Typical values
would be {03,00}, the lowest version number supported by the client,
and the value of ClientHello.client_version. No single value will
guarantee interoperability with all old servers, but this is a
complex topic beyond the scope of this document.

I interpret this, when combined with the above quoted text from TLS 1.1, as saying:

• The original intent was for clients to send a record version of {03,00}, but this was not clear enough.
• Our TLS library vendor is more strict about the record version number than allowed by TLS 1.2. We are communicating with them about this issue.

I believe that if FileZilla is changed to send a client hello with a record version of {03,00} and a hello version of {03,02} it will work with a larger variety of servers, even though such servers are not quite completely compliant.

[Tim Kosse]

I see.

This has been discussed already by the GnuTLS developers, see ​http://thread.gmane.org/gmane.network.gnutls.general/1544/focus=3424

This is actually a weakness of the TLS procotol since the highly important hello message are already encapsulated in a different, versioned layer.

This is also mentioned in the specifications for TLS 1.2:

Earlier versions of the TLS specification were not fully clear on
what the record layer version number (TLSPlaintext.version) should
contain when sending ClientHello (i.e., before it is known which
version of the protocol will be employed). Thus, TLS servers
compliant with this specification MUST accept any value {03,XX} as
the record layer version number for ClientHello.

TLS clients that wish to negotiate with older servers MAY send any
value {03,XX} as the record layer version number. Typical values
would be {03,00}, the lowest version number supported by the client,
and the value of ClientHello.client_version. No single value will
guarantee interoperability with all old servers, but this is a
complex topic beyond the scope of this document.

To be on the safe side, better upgrade your server so that it's checking the version in accordance to RFC 5246.

As workaround, you can try replacing the call to gnutls_set_default_priority in src/engine/tlssocket.cpp:81 with the following:
gnutls_priority_set_direct(m_session, "NORMAL:%SSL3_RECORD_VERSION", NULL);

Unfortunately this workaround won't work with all servers, there are others with require a minimum record layer version > 3.0

In short, adding support for a server requiring record layer version of 3.0 would break support for other servers.