I do not understand how SNI would be useful with explicit TLS over FTP. Regardless, we use the same SSL stack for HTTP and FTP and we are not aware that we would disable the SNI extension for FTP. Please reopen this ticket with more information if available.
When using Cyberduck 7.4.1 (33065) on both macOS High Sierra (10.13.6) and Windows 10, Cyberduck is not sending SNI.
ProFTPD as of 1.3.7 (1.3.7rc3) supports SNI. The release notes say, "mod_tls now honors client-provided SNI as part of the TLS handshake, for implementing name-based virtual hosts via TLS SNI." http://www.proftpd.org/docs/RELEASE_NOTES-1.3.7a
Now that ProFTPD supports SNI and free certificates are trivially available via Let's Encrypt, it is feasible to configure named-based virtual hosts for FTP. A shared hosting server that supports example1.com, customer2.com, and site3.com can serve the three different certificates based on what the client sends as SNI. That way, each customer can configure their FTP client using their own site's domain. Traditionally, they would need to know the server name, which might be something.myhostingcompany.com. The SNI named-based configuration is more user-friendly. This is the same model used for HTTPS, so it's something that administrators are already familiar with.
Other clients already support SNI. lftp, the command line client on Linux, supports SNI. FileZilla supports SNI. (FileZilla doesn't do certificate validation at all; users always have to approve the certificate. That is less than ideal.) WinSCP is adding SNI right now. (The developer added it last night at my suggestion and I have verified it works for explicit FTPS; that support should be in the next release.)
I tested this against my website: coderich.net Feel free to test against that site. If you send SNI, you'll get a coderich.net cert. If you don't send SNI, you'll get a bison.wiktel.com cert. You don't need working credentials to test the TLS negotiation, so just make up a username and password. On that server, both explicit (on port 21) and implicit FTS (on port 990) are supported. Though I don't think Cyberduck supports implicit FTPS.
Right, that code looks to be passing the IP address from socket.getInetAddress().getHostAddress() as the host, so the SNI won't be sent. If you pass the client-configured hostname, SNI should hopefully just work.
For webdav over HTTPS cyberduck have SNI support, but not for FTPES (FTP-SSL).
The text was updated successfully, but these errors were encountered: