FileZilla Forums

When I click on Help -> Check for Updates ... the new window pops up and the cursor spins for a bit and I get the message "information about the latest version of FileZilla could not be retrieved. Please try again later." and a try again link is shown. No matter when or how many times I try this is all that I get. I do not have a proxy in the way. Anyone have an idea of what is wrong? Should I file a bug ticket? Client info below.

FileZilla Client
----------------

Version: 3.53.0

Build information:
Compiled for: x86_64-apple-darwin20.3.0
Compiled on: x86_64-apple-darwin20.3.0
Build date: 2021-03-15
Compiled with: Apple clang version 12.0.0 (clang-1200.0.32.29)
Compiler flags: -O2 -g -Wall -Wextra -pedantic -O2 -g -Wall -Wextra -pedantic -Werror=partial-availability

Linked against:
wxWidgets: 3.0.6
SQLite: 3.31.1
GnuTLS: 3.6.15

Operating system:
Name: Mac OS X (Darwin 20.3.0 x86_64)
Version: 11.2
CPU features: sse sse2 sse3 ssse3 sse4.1 sse4.2 avx avx2 aes pclmulqdq rdrnd bmi bmi2 adx lm
Settings dir: /Users/dpb657/.config/filezilla/

Cannot reproduce. Make sure FileZilla is not being blocked by some firewall or AV product.

May I get the target URL? I would like to try telnet and nc to get back any errors that may help debug my connectivity.

Checking for updates is done through update.filezilla-project.org port 443

Looks like the certificate is self-signed. I do not have that cached nor would I want to if it is at all possible to avoid it. Are you able to use a free LetsEncrypt certificate?

Why? It is not a public service and only FileZilla products will use it.

Apart from that, and contrary to what the CA trust mafia wants you to believe, self-signed certificates are not less safe as the paid ones. As long as you have verified or do trust the issuer/signer, they are perfectly safe. update.filezilla-project uses a self-signed certificate, and FileZilla knows (and trusts) it. I see no problem in that.

By the way, FileZilla itself does not make any distinction between self-signed certificates and paid ones. Each and every certificate not known to FileZilla needs to be confirmed by the user. There is no implied trust at all.

The certificate on update.filezilla-project.org is not self-signed. It is signed by the updater CA trusted by FileZilla, in fact the only CA FileZilla trusts for updates.

But you didn't pay a CA to sign it.

Correct. For security reasons I created my own CA, one that cannot be compromised by the highest bidder or the government.

That was what I meant. Maybe should have said "self-issued", not self-signed.

botg wrote: ↑

2021-03-24 08:08

Correct. For security reasons I created my own CA, one that cannot be compromised by the highest bidder or the government.

While this is something I like, a lot of users in the corporate world will end up not updating their FZ Clients.
Very often these users will be behind a security appliance that will terminate SSL in order to inspect the traffic and issue a certificate on the fly for the client connection:
Client<-- certificate issued by the security appliance --> Security appliance <- the real FZ cert -> https://update.filezilla-project.org

Don't know how many organizations would bother to create an exception for FZ in their security watchdog.

Most people are no good with manually keeping with updates.

Don't know what's worst - the chance - the chance of somebody sniffing on FZ update traffic (that is freely downloadable) or users ending up not getting (security) updates.

Such businesses not trusting FileZilla's update channel can easily deploy updated installers through their channels.

As much as I resent the man-in-the-middle bs in corporate networks, it is everywhere. Exceptions are usually made for the big ones that use pinned certs. Like Google. FZ is likely not even on the radar and IMO, there's a big chance clients not to get updated.
I can care less either way - I do keep my stuff updated one way or another.

This issue is still happening in our organization and I do not understand why FileZilla still uses an untrusted certificate for access to https://update.filezilla-project.org. Business of all sizes have edge protection and scanning and because this site is untrusted no downloads are possible and the app can't keep itself up to date or even alert the customer of vulnerabilities or feature updates.

Using FileZilla 3.56.2 (which I had to manually update to) I continue to see this failure when running the Check for Updates.
When I browse https://update.filezilla-project.org directly I receive an ugly error and the attached screenshot of the cert shows why.

Please fix this. The answer is not to have businesses deploy updates... the real fix is to use a publicly signed SSL cert so clients can be prompted and kept up to date.

So you want the update mechanism to rely on a public CA, where all sorts of government agencies and also the highest bidder can easily obtain illegitimate but seen as trusted certificates? And you think this is more secure just because you've been drinking straight from the snake-oil vendor's teat?

I'm not going to compromise the security of the update mechanism just because your snake-oil product has no clue about neither trust nor security.

The updater CA, and only the updater CA, is trusted by FileZilla for the purpose of updates. The updater CA is only issuing certificates used by the update infrastructure. Whether some other software sees it as trusted or not has absolutely no relevance to the security of the update mechanism.