Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240201212715.67677c9a.hanno@hboeck.de>
Date: Thu, 1 Feb 2024 21:27:15 +0100
From: Hanno Böck <hanno@...eck.de>
To: oss-security@...ts.openwall.com
Subject: Re: Re: Python standard library defaults to insecure
 TLS for mail protocols

On Thu, 1 Feb 2024 09:45:36 -0800
nightmare.yeah27@...ecat.org wrote:

> Relaying *MTAs* do not usually verify the certificate of the server
> they connect to.

Even that isn't true any more in 2024. The largest mail providers (and
plenty of small ones) all support MTA-STS. So in most cases,
certificate validity and hostnames are checked.

> When they do, it creates problems because MTA
> certificates are very often self-signed. IIRC Yahoo relays in
> particular used to have this problem (or still do?)

Doubtful:
host -t txt _mta-sts.yahoo.com
_mta-sts.yahoo.com descriptive text "v=STSv1; id=20161109010200Z;"

If they had invalid certs, they wouldn't receive any mails from MTA-STS
supporting senders. I think someone would've noticed.

> It is true that MTAs are not usually written in Python :-) So maybe
> the proposal is OK. But there's a general point to note here, namely
> not all protocols are the same wrt TLS.

Some are slower, others are faster, but all of them should strive for
deprecation of man-in-the-middle-vulnerabilities by default.


-- 
Hanno Böck
https://hboeck.de/

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.