Ticket #4742 (closed Feature request: rejected)

Opened 3 months ago

Last modified 4 weeks ago

SNI support

Reported by: jehan Owned by:
Priority: normal Component: FileZilla Client
Keywords: Cc:
Operating system type: Operating system version:

Description

I think SNI (Server Name Indication) support like described in rfc3546 ( http://www.ietf.org/rfc/rfc3546.txt) would be a very good thing.

Is this planed for a future version of filezilla?

Change History

  Changed 3 months ago by codesquid

  • status changed from new to moreinfo

What's the purpose of supporting SNI when the underlying protocol does not distinguish between hostnames?

SNI is only useful for protocols such as HTTP where there is a concept of hostnames.

  Changed 4 weeks ago by flint1138

This would be very interesting if the ftp server can handle it aswell; in this case, the server could present the correct certificate to the client:

ftp virtualdomain1.myhost.com -> present cert for virtualdomain1.myhost.com
ftp virtualdomain2.myhost.com -> present cert for virtualdomain2.myhost.com
ftp valuable-customer.com -> present cert for valuable-customer.com

Even if ftp does not handle dns name after that, at least the user is not afraid that the certificate is a generic one like 'ns325555.host.com'

I dont know if any ftp server are SNI compliant yet, but it's the story of the chicken and egg, someone has to implement it first.

I dont think this feature would be to hard to implement, as it is just setting the host name you request in the SSL stack.

  Changed 4 weeks ago by jehan

  • status changed from moreinfo to new

Just for info: delegated ( http://www.delegate.org) supports SNI even for FTP protocol.

follow-up: ↓ 6   Changed 4 weeks ago by codesquid

  • status changed from new to moreinfo

Do you have any suggestion how to handle a fatal "unrecognized_name" alert?

  Changed 4 weeks ago by codesquid

Note that the relevant RFC is  http://www.ietf.org/rfc/rfc4366.txt, it obsoletes the above mentioned RFC 3546.

in reply to: ↑ 4   Changed 4 weeks ago by flint1138

  • status changed from moreinfo to new

Replying to codesquid:

Do you have any suggestion how to handle a fatal "unrecognized_name" alert?

Maybe manage this case as if the server did not respond to the TLS negotiation ?
so, prevent to user to connect ?

If this case rise, i guess that it's because the server is not well configured (missing a certificate), or that the user has made a mistake in the dns name.

  Changed 4 weeks ago by codesquid

  • status changed from new to closed
  • resolution set to rejected

The problem is that a connection with SNI can fail, whereas a connection to the very same server without SNI would succeed.

Also, FTP uses secondary connections based on an IP address returned by the server (in passive mode at least). For those there's not even a hostname known at all.

These issues cannot be solved, the FTP protocol is unsuited for SNI. The way I see it there is only one solution: Get more IP addresses so that every hostname resolves to its own address. Easily possible using IPv6, FileZilla is fully IPv6 capable.

  Changed 4 weeks ago by flint1138

SNI is only here to put a hint so that that the server can send the right certificate, it's an extention to TLS not to FTP protocol.

Also, connecting to a server using an IP/DNS name and getting a certificate that does not match is a mistake and the connection to the server should pop a warning to the user.

I fail to see where adding SNI could be worst than now ; even if there is a failure, you still can retry TLS handshake without SNI.

Note: See TracTickets for help on using tickets.