Werner Koch via Gnupg-users wrote:
Hi!

Thanks for mentioning this.

On Sat, 17 Aug 2024 13:49, Jan Palus said:
FTP service at ftp.gnupg.org appears to be down for some
time. Couldn't find any
info about FTP decommissioning so just letting you know about the problem.

I would not considere this a problem but something which we should have
done years ago.  Sorry for not annoucing this but my impression was that
nobody is using ftp anymore since the rush from http to https about 10
years ago.

Mapping ftp.gnupg.org URLs is a easy:

  ftp://ftp.gnupg.org/foo => https://gnupg.org/ftp/foo

Unlike HTTP, FTP is /not/ subject to simple Man-on-the-Side attacks (which motivated the rush to HTTPS) because there is no in-protocol redirect. The attack on HTTP depends on winning a race and having the client close the connection before the server's legitimate response arrives. (The attacker sends a fake 301 response with "Location: http://pwn.me.now/..."; and "Connection: close" headers. The HTTP client then closes the connection and the client system sends TCP RST to the server when the legitimate response arrives. The HTTP client the processes the redirect and contacts the attacker's server...) In HTTPS, the attack is much harder---the attacker must win a much longer race to negotiate a fake TLS session and must hold a plausible certificate. (Actual "zero RTT" TLS set-up could make Man-on-the-Side possible against HTTPS if the attacker can get a phony certificate---you should assume that rogue states and transnational criminal organizations can obtain phony certificates from legitimate CAs by coercion or fraud.) In FTP, the control connection must remain open during the transfer and there is no way for an attacker's response to redirect the client to a malicious server.

There is still a lack of confidentiality, since FTP is almost always run in plaintext, but that is not much of a concern when distributing publicly available software, especially when the mere fact that user X contacted gnupg.org and received N bytes is a good hint of what they were doing and possibly even exactly what they downloaded. (In other words, traffic analysis easily breaks confidentiality in this case, even for HTTPS.) For GPG, integrity is assured by signing the distribution tarballs directly, and the transport is untrusted anyway.

I would encourage resuming FTP distribution, since I see no plausible security benefit to omitting it.


-- Jacob


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Reply via email to