Opened 12 years ago

Closed 11 years ago

Last modified 11 years ago

#4742 closed Feature request (rejected)

SNI support

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


I think SNI (Server Name Indication) support like described in rfc3546 ( would be a very good thing.

Is this planed for a future version of filezilla?

Change History (8)

comment:1 by Tim Kosse, 12 years ago

Status: newmoreinfo

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.

comment:2 by Jean-Baptiste Vignaud, 11 years ago

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 -> present cert for
ftp -> present cert for
ftp -> present cert for

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 ''

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.

comment:3 by jehan, 11 years ago

Status: moreinfonew

Just for info: delegated ( supports SNI even for FTP protocol.

comment:4 by Tim Kosse, 11 years ago

Status: newmoreinfo

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

comment:5 by Tim Kosse, 11 years ago

Note that the relevant RFC is, it obsoletes the above mentioned RFC 3546.

in reply to:  4 comment:6 by Jean-Baptiste Vignaud, 11 years ago

Status: moreinfonew

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.

comment:7 by Tim Kosse, 11 years ago

Resolution: rejected
Status: newclosed

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.

comment:8 by Jean-Baptiste Vignaud, 11 years ago

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.