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.