Cyberduck Mountain Duck CLI

#9257 closed enhancement (fixed)

FTPES (FTP-SSL) SNI support

Reported by: andreas7 Owned by: jmalek
Priority: normal Milestone: 7.5.0
Component: ftp-tls Version: 7.4.1
Severity: normal Keywords: SNI FTPES FTP-SSL
Cc: Architecture: Intel
Platform: macOS 10.13

Description

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

Change History (8)

comment:1 Changed on Feb 11, 2016 at 8:05:09 PM by dkocher

  • Resolution set to worksforme
  • Status changed from new to closed

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.

comment:2 Changed on Jul 30, 2020 at 9:53:50 PM by rlaager

  • Architecture set to Intel
  • Platform changed from Mac OS X 10.10 to macOS 10.13
  • Resolution worksforme deleted
  • Status changed from closed to reopened
  • Version changed from 4.7.3 to 7.4.1

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.

comment:3 Changed on Jul 30, 2020 at 11:03:21 PM by jmalek

  • Owner changed from dkocher to jmalek
  • Status changed from reopened to new

comment:4 Changed on Jul 30, 2020 at 11:03:28 PM by jmalek

  • Status changed from new to assigned

comment:5 Changed on Jul 30, 2020 at 11:39:59 PM by rlaager

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.

comment:6 Changed on Jul 31, 2020 at 8:08:20 AM by dkocher

  • Milestone set to 8.0

comment:7 Changed on Jul 31, 2020 at 12:04:05 PM by dkocher

  • Resolution set to fixed
  • Status changed from assigned to closed

In r49568.

comment:8 Changed on Aug 11, 2020 at 9:07:52 AM by dkocher

  • Milestone changed from 8.0 to 7.5.0
Note: See TracTickets for help on using tickets.
swiss made software