Remove unrelated pages for laboration

1 files changed, 0 insertions, 13 deletions

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.
-"""]]