diff options
Diffstat (limited to 'tracker/Poor_score_on_starttls.info')
4 files changed, 0 insertions, 29 deletions
diff --git a/tracker/Poor_score_on_starttls.info/comment_1_96728869b78cedfd11594828615e5079._comment b/tracker/Poor_score_on_starttls.info/comment_1_96728869b78cedfd11594828615e5079._comment deleted file mode 100644 index c665ac7..0000000 --- a/tracker/Poor_score_on_starttls.info/comment_1_96728869b78cedfd11594828615e5079._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="guilhem" - avatar="http://cdn.libravatar.org/avatar/86d6cb4bde1ef88730b14ccad0414c28" - subject="comment 1" - date="2015-06-05T15:52:00Z" - content=""" -I'm all for ubiquitous encryption, but note that without TLSA records and DNSSEC, any MX is trivially vulnerable to downgrade attacks: an adversary sitting in the middle can easily strip the STARTTLS EHLO/HELO response, and force the communication to happen in the clear :-P -"""]] diff --git a/tracker/Poor_score_on_starttls.info/comment_2_6af51a73a33ae813cbe5104943437eb2._comment b/tracker/Poor_score_on_starttls.info/comment_2_6af51a73a33ae813cbe5104943437eb2._comment deleted file mode 100644 index 819277d..0000000 --- a/tracker/Poor_score_on_starttls.info/comment_2_6af51a73a33ae813cbe5104943437eb2._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="Grégoire" - avatar="http://cdn.libravatar.org/avatar/5ed039572e7af206cbc97a7c59dcb0ad" - subject="comment 2" - date="2015-10-01T18:00:18Z" - content=""" -But I guess in this case either side could decide to stop the communication. Either because you have some [add-hoc list](https://support.google.com/a/answer/2520500?hl=en) or a heuristic like *connection to @foobar.com was encrypted last time so I expect it to be encrypted forever* -"""]] diff --git a/tracker/Poor_score_on_starttls.info/comment_3_e7e46a099bbcbef7bdacd4249e1d26aa._comment b/tracker/Poor_score_on_starttls.info/comment_3_e7e46a099bbcbef7bdacd4249e1d26aa._comment deleted file mode 100644 index bcea26e..0000000 --- a/tracker/Poor_score_on_starttls.info/comment_3_e7e46a099bbcbef7bdacd4249e1d26aa._comment +++ /dev/null @@ -1,13 +0,0 @@ -[[!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](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. -"""]] diff --git a/tracker/Poor_score_on_starttls.info/screenshot.png b/tracker/Poor_score_on_starttls.info/screenshot.png Binary files differdeleted file mode 100644 index 06ca3af..0000000 --- a/tracker/Poor_score_on_starttls.info/screenshot.png +++ /dev/null |
