FTPES (FTP-SSL) SNI support

[cyberduck]

b12fa57 created the issue

For webdav over HTTPS cyberduck have SNI support, but not for FTPES (FTP-SSL).

[cyberduck]

@dkocher commented

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.

[cyberduck]

d2a9fdb commented

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.

[cyberduck]

@AliveDevil commented

https://trac.cyberduck.io/browser/trunk/ftp/src/main/java/ch/cyberduck/core/ftp/FTPClient.java#L159

[cyberduck]

d2a9fdb commented

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.

This looks to be the bug where SNI was added to OpenJDK: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=6985179

It references an Hg changeset with a broken URL, but using the hash, I found this (so the path just changed a little):
http://hg.openjdk.java.net/icedtea/jdk7/jdk/rev/9d6a9f65d2bf

The actual SNI is sent here:
http://hg.openjdk.java.net/icedtea/jdk7/jdk/rev/9d6a9f65d2bf#l32.349

It doesn't send the SNI if the "hostname" is an IP address. (That is correct behavior, of course. The SNI has to be a hostname, not an IP.)

I don't know how the JDK has been restructured recently, so I'm not sure where the current code is, but I assume it is substantially the same.

[cyberduck]

@dkocher commented

In 8c0cc01.