Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FTPES (FTP-SSL) SNI support #9257

Closed
cyberduck opened this issue Feb 11, 2016 · 5 comments
Closed

FTPES (FTP-SSL) SNI support #9257

cyberduck opened this issue Feb 11, 2016 · 5 comments
Assignees
Labels
enhancement fixed ftp-tls FTP (TLS) Protocol Implementation
Milestone

Comments

@cyberduck
Copy link
Collaborator

b12fa57 created the issue

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

@cyberduck
Copy link
Collaborator Author

@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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

@cyberduck
Copy link
Collaborator Author

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
Copy link
Collaborator Author

@dkocher commented

In 8c0cc01.

@iterate-ch iterate-ch locked as resolved and limited conversation to collaborators Nov 26, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement fixed ftp-tls FTP (TLS) Protocol Implementation
Projects
None yet
Development

No branches or pull requests

2 participants