Opened 10 years ago

Closed 10 years ago

Last modified 10 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:

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 (8)

comment:1 Changed 10 years ago by Tim Kosse

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 Changed 10 years ago by Jean-Baptiste Vignaud

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.

comment:3 Changed 10 years ago by jehan

Status: moreinfonew

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

comment:4 Changed 10 years ago by Tim Kosse

Status: newmoreinfo

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

comment:5 Changed 10 years ago by Tim Kosse

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

comment:6 in reply to:  4 Changed 10 years ago by Jean-Baptiste Vignaud

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 Changed 10 years ago by Tim Kosse

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 Changed 10 years ago by Jean-Baptiste Vignaud

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.