Change default security of `ftplib.FTP_TLS`

[hartwork]

Bug report

Bug description:

Hi!

It has come to my attention that the ftplib.FTP_TLS class shyly notes in its documentation — it does not warning — that it is insecure by default: it leaves the data connection without TLS and vulnerable to man-in-the-middle attacks. Documenting that calling .prot_p() closes that hole is better than nothing but misses the point: vulnerable defaults need to be fixed, just XML parsers must not be vulnerable to XXE by default.

To see the issue in action, you can run this script…

# /usr/bin/env python3
# Copyright (c) 2026 Sebastian Pipping <sebastian@pipping.org>
# SPDX-License-Identifier: 0BSD

from sys import stdout
from ftplib import FTP_TLS

ftps = FTP_TLS('test.rebex.net')
ftps.login(user="demo", passwd="password")
ftps.retrbinary('RETR readme.txt', stdout.buffer.write)  # <-- MITM here
ftps.quit()

…and watch sudo tcpdump -i any -A 2>/dev/null | grep -F "Rebex FTP/SSL" output in another terminal to see the MITM in action.

A pull request with a fix and extending documention on security is upcoming.

I'm looking forward to your review and am hoping for your support 🙏

Related:

• issue Enable TLS certificate validation by default for SMTP/IMAP/FTP/POP/NNTP protocols #91826 is another unfixed MITM vector due to lack of FTPS certificate validation 😞
• issue ftplib: Add client-side SSL session resumption #63699 is breaking FTPS with most servers for 12+ years now, would be great to have that fixed 🙏

CC @The-Compiler @hannob @nitram2342

CPython versions tested on:

3.9, 3.10, 3.11, 3.12, 3.13, 3.14, 3.15, CPython main branch

Operating systems tested on:

Linux, macOS, Windows, Other

Linked PRs

• gh-143497: Fix default security of ftplib.FTP_TLS #143498

[picnixz]

It can be a breaking change. While I understand this, I would prefer not to enable it by default. I do understand the vulnerability, I do understand why we could change it, but I do not know whether this could definitely break code that relies on that behavior. This would break the tests of everyone that uses that class without calling prot_c(). So I'm sorry but even with the standards changing, it can't be a bugfix.

[picnixz]

cc @gpshead @sethmlarson

[gpshead]

ftp is an ancient protocol from 1985, TLS was added to it as a late-stage afterthought 20 years later. Changing the ftplib default would be a breaking change, so while doable, it'd require a multi-release deprecation period. Realistically I'm not sure it would add useful security because those who need secure ftp should configure their ftp server to only allow TLS operation. Those using it for embedded closed network firmware update automation purposes (for example) would need to update their code to explicitly turn TLS off. Thus the required PEP-387 deprecation period.

We have no way to know which use case is more common.

In reality people who need secure file transfer are likely to use other protocols today such as ssh's unrelated sftp protocol (for which there are third party PyPI modules) or even rsync via ssh.

I wouldn't block this change being made, but it'll need someone to drive it and see it through. It doesn't feel high value to me.

[hannob]

I'd like to emphasize that this is a serious issue, and a security footgun.

To add some clarification: This is not about defaulting to TLS for all FTP connections (which is probably what @gpshead was alluding to with the network firmware processes, which, I think, often use plaintext FTP), but to avoid a sort-of half-TLS mode. I think the legitimate and intentional uses of this half-TLS are probably extremely minor or nonexistent, and I expect the amount of breakage introduced to be low (and in some cases, the breakage may uncover that people were unintentionally using unencrypted connections).

My understanding is this: due to its two channels, FTP has different ways of doing TLS. It can either do TLS on both channels, or only do TLS on the control channel. I cannot think of a scenario where one legitimately wants to use FTP with Half-TLS.

We all know that FTP is a legacy protocol, and most uses of FTP never used any encryption whatsoever. But this change would not impact legacy FTP use without TLS.

It is extremely unexpected and counterintuitive that creating an FTP_TLS object creates, by default, only half-TLS. To put it another way, without knowing this, noone would expect, by looking at the code examle given above, that this would cause an unencrypted data connection.

[picnixz]

• It is documented, we can always make it louder. We are consenting adults. Not reading the documentation is not an excuse IMO.
• There is an RFC and it's documented as following the RFC. If the RFC doesn't explicitly state to use encryption for both channels, then we must NOT do it ourselves. I personally don't think that auth() should be responsible for calling it. We could make it so login() calls it but auth() shouldn't be responsible for that (as it's currently done in the PR).
• Backward compatibility is especially important and breaking changes need to be motivated.
• What can be done to make the warning even louder is to emit a warning if people call login() and the data channel is not protected. That would only break code relying on the output and possibly pollute logs. OTOH, this could also indicate that channel is not protected (and sometimes people don't want those kind of logs)

[hannob]

I don't think documenting security flaws is a good way to approach security.

I also think there's plenty of precedent where Python changed things to more secure defaults despite what standardization said and despite breakage. E.g., Python changed its XML APIs to avoid XXE attacks, which is in violation of the XML specification, but it was the right thing to do (even got a CVE: CVE-2013-1665). Python also changed certificate validation defaults for HTTPS requests (PEP 476), causing probably a lot of breakage, but it was the right thing to do.

[giampaolo]

-1, mostly because such a change would break existing code and expectations.

The reason why I made prot_p() invocation explicit in bpo-2054 was because this distinction (secured control connection vs. secured data connection) existed and was quite strong in the official RFC-4217. So basically the ftplib API reflects that.

FWIW, FTP_TLS doc already states:

 Note: The user must explicitly secure the data connection by calling the prot_p() method.

...and the code sample shown some lines later includes prot_p(). So IMO the user is already well informed about this, and I expect most people already have prot_p() in their code, simply because they copied it from the doc.

@hannob wrote:

I cannot think of a scenario where one legitimately wants to use FTP with Half-TLS.

RFC-4217 mentions these use cases:

 [clear text data channel] might be the desired behaviour for servers sending file lists, 
 pre-encrypted data, or non-sensitive data (e.g., for anonymous FTP servers).

The strongest argument here appears to be "anonymous FTP". There are public FTP sites like debian.org where you don't care to encrypt downloaded files. At which point you may reply "then just use FTP instead of FTPS". Which is also true. :)

Also note that the FTP protocol is quite costly in terms of data exchange, because you have to re-open a new data connection for every file you download or directory listing. The TLS handshake is the biggest contributor to that cost in terms of bytes being transmitted, so one may make the argument of disabling TLS if the files being downloaded are a lot and not sensitive.