#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 by , 15 years ago
| Status: | new → moreinfo |
|---|
comment:2 by , 15 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 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 by , 15 years ago
| Status: | moreinfo → new |
|---|
Just for info: delegated (http://www.delegate.org) supports SNI even for FTP protocol.
follow-up: 6 comment:4 by , 15 years ago
| Status: | new → moreinfo |
|---|
Do you have any suggestion how to handle a fatal "unrecognized_name" alert?
comment:5 by , 15 years ago
Note that the relevant RFC is http://www.ietf.org/rfc/rfc4366.txt, it obsoletes the above mentioned RFC 3546.
comment:6 by , 15 years ago
| Status: | moreinfo → 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.
comment:7 by , 15 years ago
| Resolution: | → rejected |
|---|---|
| Status: | new → closed |
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 , 15 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.
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.