Timeline for How can I verify the certificates when connecting to an FTP server with Filezilla?
Current License: CC BY-SA 4.0
11 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
Nov 30, 2018 at 6:48 | comment | added | le3th4x0rbot | @reed In this form post, the author of FileZilla (botg) discusses certificate support very briefly. It seems to not be a major priority. Describing your problem as a feature request there might actually help them prioritize this feature. forum.filezilla-project.org/viewtopic.php?t=40417 | |
Nov 30, 2018 at 3:43 | comment | added | le3th4x0rbot | @reed If you trust the certificate in the browser it is reasonable to trust it in FileZilla, it is a good strategy. Poor support for pki does not mean FileZilla is bad, and in fact it is actually one of the better graphical clients. It just does a bad job helping you use CA signed certificates to trust a server. Now that you have trusted that certificate, it should otherwise be safe. The situation with SSH is not better, there literally is no pki. I would be surprised if the command line ftp client even supports tls. | |
Nov 29, 2018 at 18:31 | comment | added | reed | You gave me an idea: the ftp domain in the example is also accessible via HTTPS (as you can see the certificate is signed by cPanel). I used the browser to load that domain and checked the details of the certificate: the fingerprints match! So I can trust the FTP certificate because it's the same that the browser accepts. It's a cumbersome method, but in many cases it's likely to work if the same certificate is used for HTTPS. Otherwise I don't know if there's a better alternative than FileZilla (on Linux), I thought that was the best available. | |
Nov 26, 2018 at 7:30 | comment | added | le3th4x0rbot | @reed My suggestions at this point would be either of these options: 1) Connect using a client with good TLS certificate verification support, record the fingerprint and trust that certificate in FileZilla. 2) Use the technique in the last paragraph of my answer to observe the certificate with index 0, trust it when you feel comfortable. | |
Nov 26, 2018 at 7:26 | comment | added | le3th4x0rbot | @reed That fingerprint is for an identically named certificate that is in the Windows trust store, which is apparently not the same certificate... After looking at the screenshot I did a bit of research and find that TLS certificate verification support in FileZilla is awful. It does not verify the CN from the certificate at all. Here it is showing a chain of intermediate certificates that would be sent by the server but it does not seem to actually check it against a client side trusted certificate. | |
Nov 25, 2018 at 15:47 | comment | added | reed | No, I don't see that string anywhere. How did you come up with that? | |
Nov 24, 2018 at 21:45 | comment | added | le3th4x0rbot |
@reed Is the sha1 fingerprint of certificate #2 afe5d244a8d1194230ff479fe2f897bbcd7a8cb4 ?
|
|
Nov 24, 2018 at 14:57 | comment | added | reed | Ok, I added the screenshots of the window that appears in FileZilla. | |
Nov 24, 2018 at 14:02 | comment | added | le3th4x0rbot | @reed can you add a screenshot of the certificate trust chain to your question? | |
Nov 24, 2018 at 11:45 | comment | added | reed | I actually don't know what Filezilla does exactly, only what I see. It shows me a chain of certificates, and I suppose they are all provided by the FTP server I'm connecting to. But I don't know if Filezilla is actually verifying that chain. Also, I'm afraid the actual root certificate isn't included, because the last certificate up the chain has a root CA as the issuer, but the subject of the certificate is different, so I guess that is not the actual root certificate, and I can't compare it to one I already have and trust (I tried, fingerprints differ). | |
Nov 6, 2018 at 20:58 | history | answered | le3th4x0rbot | CC BY-SA 4.0 |