ftp down

[Jacob Bachmeyer]

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