From b5aee0b7f72a8df513b73ddc9df7230f53b6ae64 Mon Sep 17 00:00:00 2001 From: guilhem Date: Tue, 6 Oct 2015 14:21:01 +0200 Subject: Added a comment --- .../comment_3_e7e46a099bbcbef7bdacd4249e1d26aa._comment | 13 +++++++++++++ 1 file changed, 13 insertions(+) create mode 100644 tracker/Poor_score_on_starttls.info/comment_3_e7e46a099bbcbef7bdacd4249e1d26aa._comment (limited to 'tracker') diff --git a/tracker/Poor_score_on_starttls.info/comment_3_e7e46a099bbcbef7bdacd4249e1d26aa._comment b/tracker/Poor_score_on_starttls.info/comment_3_e7e46a099bbcbef7bdacd4249e1d26aa._comment new file mode 100644 index 0000000..9308482 --- /dev/null +++ b/tracker/Poor_score_on_starttls.info/comment_3_e7e46a099bbcbef7bdacd4249e1d26aa._comment @@ -0,0 +1,13 @@ +[[!comment format=mdwn + username="guilhem" + avatar="http://cdn.libravatar.org/avatar/86d6cb4bde1ef88730b14ccad0414c28" + subject="comment 3" + date="2015-10-06T12:21:01Z" + content=""" +Doing so would violate the SMTP protocol, so it's unlikely to be implemented on non-private MTAs. (And end users typically don't talk directly to a MX.) + +Furthermore, while ad-hoc lists are very useful on a local MTA (list the fingerprints of all known SMTPSA servers to defeat MITM attacks) or to specify an encryption policy within a given Email Service Provider (which is [what we're doing](http://git.fripost.org/fripost-ansible/tree/roles/common/templates/etc/postfix/tls_policy.j2) by the way), they don't really scale. Like the heuristic you described, they also fail to properly address key rotation and/or expiration. (If the certificate has changed, how to determine if it was done by the MTA operator or if the connection is being MITM'ed? By relying on the CA model? +Should the client decide to bounce the message or to send it in the clear?) Also, what if the service operator suddenly decide to remove TLS support? As far as SMTP is concerned this is perfectly fine since STARTLS is optional. + +On the other hand, by publishing some (signed) TLSA records a site operator can broadcast their certificate fingerprint or signing CAs. Clients no longer have to guess a heuristic since they can rely on the information provided by site operators themselves. This is what we get when not-security-focused 30 years-old protocols are being patched up to meet today's standards: fixes come with yet another RFC extension. And care must be taken to defeat downgrade attacks. +"""]] -- cgit v1.2.3