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
