[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAFRnB2UBm6VXnK3te6NaZ6AQWHjYWe8XSWdWN3CD6TWyYzfUZA@mail.gmail.com>
Date: Thu, 1 Feb 2024 18:29:39 -0500
From: Alex Gaynor <alex.gaynor@...il.com>
To: oss-security@...ts.openwall.com
Subject: Re: Python standard library defaults to insecure TLS
for mail protocols
I'm the original author of PEP 476, which made certificate
verification on by default for TLS. In 2014 I scoped it to HTTPS-only
to minimize the risk of breakages, and ensure we could get the PEP
approved and implemented (particularly given it was going to be
enabled by default on Python 2.7, without a major version bump). It
was never intended to be the final destination for cert verification.
I think it'd be reasonable to start a discussion on the Python
discourse about moving forward with fixing SMTP as well:
https://discuss.python.org/
Alex
On Thu, Feb 1, 2024 at 6:32 AM Hanno Böck <hanno@...eck.de> wrote:
>
> Hello,
>
> By default, the mail protocol functions in Python's standard library do
> not validate certificates for TLS connections. The API is surprising
> and unintuitive. This is not a new issue, but I was surprised to learn
> about it. Therefore, I'm sharing it here so more people know.
>
> Python provides functionality for the standard email protocols in its
> standard library. One can create a connection to an IMAP host like this:
> c = imaplib.IMAP4_SSL(host="example.com")
>
> Similar functions exist for pop3 and smtp. This code is insecure and
> vulnerable to man-in-the-middle attacks, as certificates are not
> checked.
>
> The secure version looks like this:
> c = imaplib.IMAP4_SSL(host="example.com",
> ssl_context=ssl.create_default_context())
> (The parameter is sometimes called "ssl_context" and sometimes
> "context", depending on the protocol.)
>
> In my view this is not just an insecure default, but also very
> counterintuitive. Nothing about
> "ssl_context=ssl.create_default_context()" implies that this is about
> certificate checking. Furthermore, it is surprising and
> counterintuitive that you need a "default context" to enable something
> and that the "default context" is not the default.
>
> This is documented behavior [1].
>
> There exists a discussion in the Python issue tracker [2] since April
> 2022. According to that, the same issue exists for NNTP and FTP
> functionality. It was discussed to change the default, but it hasn't
> happened yet.
>
> Python already had a previous discussion about enabling certificate
> validation by default in the standard library, but it was only done for
> HTTPS connections [3]. The PEP document says that this should be
> reviewed in the future for other protocols.
>
> The company Pentagrid has reached out to a large number of open source
> projects impacted by this, and wrote a blogpost [4].
>
> Also relevant is RFC 8314, which contains guidelines for TLS
> connections in email protocols [5]. ("MUAs MUST validate TLS server
> certificates [...]") It targets client software, but I believe it is
> reasonable to apply the same standards to client APIs.
>
>
> [1] https://docs.python.org/3/library/ssl.html#ssl-security
> [2] https://github.com/python/cpython/issues/91826
> [3] https://peps.python.org/pep-0476/
> [4]
> https://www.pentagrid.ch/en/blog/python-mail-libraries-certificate-verification/
> [5] https://datatracker.ietf.org/doc/html/rfc8314
>
> --
> Hanno Böck
> https://hboeck.de/
--
All that is necessary for evil to succeed is for good people to do nothing.
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
