From 2ffaf47ae3b46e07e3249d2531924b881a5b7348 Mon Sep 17 00:00:00 2001 From: Guilhem Moulin Date: Mon, 28 Dec 2015 14:34:08 +0100 Subject: Update all Fripost links from http:// to https://. --- .../comment_3_e7e46a099bbcbef7bdacd4249e1d26aa._comment | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (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 index 9308482..bcea26e 100644 --- a/tracker/Poor_score_on_starttls.info/comment_3_e7e46a099bbcbef7bdacd4249e1d26aa._comment +++ b/tracker/Poor_score_on_starttls.info/comment_3_e7e46a099bbcbef7bdacd4249e1d26aa._comment @@ -6,7 +6,7 @@ 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? +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](https://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