TLS Error on FileZilla 1.2 (solved)

[CrimpOn]

I have heard back from the camera engineers. I had complained, "The product FTP setup includes an option slider for SFTP (on or off). But the camera attempts a TLS connection for FTP in both settings." FIX IT.
Their response was, "We're doing things the best way. No matter what the slider says, we ALWAYS attempt an SFTP connection, and if it fails, then we switch to regular FTP. The customer gets the most secure connection possible." This is similar to the behavior of modern web browsers that always attempt an https connection first, and go back to http if an https site cannot be found.

Before I go ballistic on them, I thought it prudent to confirm that they are full of .....
This is a FileZilla log of a recent connection which begins with the TLS handshake, but then sends a CLIENT HELLO message.
1. Could this be their attempt to "switch from SFTP to FTP?
2. Is this 'legal'? Should they have (instead) opened a new connection to the server and started off with an FTP handshake?

Code: Select all

2022-03-15T21:07:46.405Z II [FTP Session 14 192.168.1.61] Session 0x210b4ccb0a0 with ID 14 created.
2022-03-15T21:07:46.451Z >> [FTP Session 14 192.168.1.61] AUTH TLS
2022-03-15T21:07:46.451Z DD [FTP Session 14 192.168.1.61] securer(1) ENTERING state = 0
2022-03-15T21:07:46.451Z DD [FTP Session 14 192.168.1.61] calling tls_layer_->set_certificate_file("C:\WINDOWS\system32\config\systemprofile\AppData\Local\filezilla-server\certificates\f9ded7fd623594f07ebc396eb718e48ec0a2e9f741f542ea4b135db88a45e588\key.pem", "C:\WINDOWS\system32\config\systemprofile\AppData\Local\filezilla-server\certificates\f9ded7fd623594f07ebc396eb718e48ec0a2e9f741f542ea4b135db88a45e588\cert.pem", "****")
2022-03-15T21:07:46.452Z DD [FTP Session 14 192.168.1.61] securer(1) EXITING state = 1
2022-03-15T21:07:46.452Z << [FTP Session 14 192.168.1.61] 234 Using authentication type TLS.
2022-03-15T21:07:46.452Z DD [FTP Session 14 192.168.1.61] ~securer(1) ENTERING state = 1
2022-03-15T21:07:46.452Z DD [FTP Session 14 192.168.1.61] calling tls_layer_->set_alpn()
2022-03-15T21:07:46.452Z VV [FTP Session 14 192.168.1.61] tls_layer_impl::server_handshake()
2022-03-15T21:07:46.452Z VV [FTP Session 14 192.168.1.61] tls_layer_impl::continue_handshake()
2022-03-15T21:07:46.452Z DD [FTP Session 14 192.168.1.61] ~securer(1) EXITING state = 2
2022-03-15T21:07:46.452Z DD [FTP Session 14 192.168.1.61] tls_layer_impl::on_send()
2022-03-15T21:07:46.452Z VV [FTP Session 14 192.168.1.61] tls_layer_impl::continue_handshake()
2022-03-15T21:07:46.469Z DD [FTP Session 14 192.168.1.61] tls_layer_impl::on_read()
2022-03-15T21:07:46.469Z VV [FTP Session 14 192.168.1.61] tls_layer_impl::continue_handshake()
2022-03-15T21:07:46.469Z DD [FTP Session 14 192.168.1.61] TLS handshakep: Received CLIENT HELLO
2022-03-15T21:07:46.469Z DD [FTP Session 14 192.168.1.61] tls_layer_impl::failure(-87)
2022-03-15T21:07:46.469Z !! [FTP Session 14 192.168.1.61] GnuTLS error -87: No supported cipher suites have been found.
2022-03-15T21:07:46.469Z !! [FTP Session 14 192.168.1.61] Control channel closed with error from source 0. Reason: ECONNABORTED - Connection aborted.
2022-03-15T21:07:46.470Z !! [FTP Server] Session 14 ended with error from source 0. Reason: ECONNABORTED - Connection aborted.
2022-03-15T21:07:46.470Z II [FTP Session 14 192.168.1.61] Session 0x210b4ccb0a0 with ID 14 destroyed.

[botg]

Note that SFTP is a completely different protocol, it has absolutely nothing in common with FTP and FTP over TLS (FTPS).

I assume you meant to say FTPS in your post, otherwise it makes no sense at all.

which begins with the TLS handshake, but then sends a CLIENT HELLO message.

Using the AUTH TLS command, the client tells the server that it wants to start a TLS handshake, to which the server agrees. Then the TLS handshake starts, which begins with a client hello.

Tempted to look at Let's Encrypt, but cannot find information on their web site as to which Cipher Suite they use so that I can see if the camera supports it. Definitely not worth the effort if it doesn't.

Both the traditional RSA-SHA256, as well as ECDSA-SHA256. FileZilla Server requests ECDSA certificates from Let's Encrypt.

[boco]

We're doing things the best way. No matter what the slider says, we ALWAYS attempt an SFTP connection, and if it fails, then we switch to regular FTP. The customer gets the most secure connection possible." This is similar to the behavior of modern web browsers that always attempt an https connection first, and go back to http if an https site cannot be found.

What an utter bullshit statement. Apart from the SFTP fuck up (they do not seem to be aware that SFTP is not FTP at all, and the secure FTP is called FTPS), they should actually test at least halfway modern browsers. Not even a single one of the many browsers I used (even old ones) did ever fall back from HTTPS to HTTP on its own, without being redirected by the site, and even then, they displayed a dire warning before doing so, and a clear indication after.

Automatically falling back to an unencrypted connection without any warning of the user is a security vulnerability, as it absolutely voids the reliability of the encryption. What good is encryption which could break at any time without you noticing it? Well, absolutely nothing. Browsers don't do that, even FileZilla shows a warning in its "Auto" setting.


A potential attacker of your camera system has to do nothing else than hijacking the initial connection (which starts unencrypted) and inserting a wrong FEAT message and/or server response that indicates no support for encryption. Your camera will then happily send everything, including login data, in clear text. Secure, my ass.

[CrimpOn]

Thanks for confirming my impression. However, this was not my best effort at composition. (And, I did not fully understand what the engineers were saying.)

I double checked the camera settings, and they in fact do say FTPS. I had such tunnel vision on the damn slider that I mistyped. As you point out SFTP is an entirely different protocol.

I probably did not make a good analogy. You are correct that when the user specifies 'https' no browser will switch to 'http'. My point with browsers is that when the user does not specify 'http or 'https' in the URL, 90% of the time the connection is made over 'https' without them asking for it. I had the impression that the latest versions of many browsers first try 'https' on their own (Chrome, Edge, Firefox) and the user has to deliberately prevent this behavior if they don't want it. (Note to self: do not attempt analogies.)

So, to restate the original question: The engineers are saying

• When the user requires FTPS, that is the only connection they will make. If they cannot connect with FTPS, there is no transfer. This is what happens with FileZilla because the camera does not support the required encryption methods. My impression of an ON/OFF switch was incorrect. It is intended to be a MUST/Optional switch. MUST means "do it this way or fail". Optional means "do the most secure way you can."
• Even when the user does not require FTPS, they first attempt an FTPS connection, and if that fails, they switch over to unencrypted FTP. If this is their goal, how would they go about doing it correctly:
  • Drop the original session and start a new session?
  • Send an unencrypted CLIENT HELLO in the current session?

My use of FTP is entirely within a local LAN with no internet access, so unencrypted FTP does not appear to be a serious issue for me.

The cameras are compatible with Xlight FTP Server. I will do a Wireshark capture of the connection for both FTP servers and compare.

[boco]

My point with browsers is that when the user does not specify 'http or 'https' in the URL, 90% of the time the connection is made over 'https' without them asking for it.

It's a fairly recent development. Normally, not specifying the protocol in the browser means HTTP (unencrypted). There are different methods to automatically change to HTTPS:

1. Redirection by the website itself. The unencrypted domain only redirects to the encrypted one, it doesn't serve any unencrypted content.
2. Usage of an add-on like HTTPS Everywhere.
3. Using HSTS. HSTS-enabled websites are delivered only encrypted.
4. Recent browsers have the functionality of HTTPS Everywhere built in, and can automatically upgrade connections, even without HSTS and similar features.

I had the impression that the latest versions of many browsers first try 'https' on their own (Chrome, Edge, Firefox) and the user has to deliberately prevent this behavior if they don't want it. (Note to self: do not attempt analogies.)

At least in Firefox, it's still experimental.

But you are missing the point: Upgrading the connection automatically is fully A-OK. Nothing wrong with that. It makes the connection more secure. The problem is with downgrading the connection from secure to insecure (aka "fall back") without noticing the user. Downgrading is a security vulnerability as it makes the connection less secure.

Recent example: The POODLE attack from 2014 allowed downgrading the TLS version from a high one to the very low SSL 3.0 (which is broken and thus essentially the same as no encryption at all). The user was never aware of this. As a result, automatic downgrading to lower TLS versions has been killed in all modern browsers.

When the user requires FTPS, that is the only connection they will make. If they cannot connect with FTPS, there is no transfer. This is what happens with FileZilla because the camera does not support the required encryption methods.

That behavior is OK. If the user says FTPS, they must never fall back.

My impression of an ON/OFF switch was incorrect. It is intended to be a MUST/Optional switch. MUST means "do it this way or fail". Optional means "do the most secure way you can."

Note that this optional switch is still insecure if you have a secure server. Then, requiring FTPS is much better. It doesn't matter if you know that the server is insecure and are actually expecting plain connections, though.

Even when the user does not require FTPS, they first attempt an FTPS connection, and if that fails, they switch over to unencrypted FTP. If this is their goal, how would they go about doing it correctly

FTP over TLS Explicit always starts unencrypted, until the AUTH TLS command and the following handshake. Dropping the session is not required. The real issue here is the reply to the FEAT and AUTH TLS commands. Does it come from the server or from a connection hijacker inserting fake data?

The best option: A hard OFF/ON switch and clear information that OFF MUST ONLY be used with servers not supporting encryption, and ON with secure servers. That way, it is always clear what state the connection is in. Relying on automatics that may or may not work is absolutely not recommended, it only gives a false sense of security, more so if the client operates headless.