You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[[ -n "$STARTTLS_PROTOCOL" ]] && set_grade_cap "T" "STARTTLS is prone to MITM downgrade attacks. A secure TLS upgrade can only be ensured client-side. You should use TLS only (=implicit TLS) rather than STARTTLS as per RFC 8314, for other than SMTP and SIEVE"
22937
+
22938
+
# TL;DR: STARTTLS connections are inherently insecure. A MITM can always intercept the connection, unless the client checks e.g. the
22939
+
# certificate accordingly. A secure STARTTLS client is the key but we can't test for it. For other than SMTP and SIEVE (there's no implicit TLS port)
22940
+
# you should use implicit TLS as per RFC 8314. Especially e-mail transfer via port 25 is broken and amendments so far are duct tape.
22941
+
22942
+
# Explanation: There are active MitM attacks possible when using STARTTLS like https://github.com/tintinweb/striptls or
22943
+
# https://github.com/libcrack/starttlsstrip. It depends on the client only whether it can detect such downgrade attack.
22944
+
# As some SMTP servers are still misconfigured with wrong certificates it's is still common practice for SMTP client MTAs to
22945
+
# accept those wrong certificates -- delivering e-mails is more important. There is an e-mail submission port 587 but a mail server
22946
+
# cannot just switch to it and continue to receive mail from everyone. Even if you advertise this via SRV record (RFC 6186).
22947
+
# TLSA Records/DANE and MTA-STS (RFC-8461) on the server side can help too,
22950
22948
22951
22949
pr_bold " Rating specs"; out " (not complete) "; outln "SSL Labs's 'SSL Server Rating Guide' (version 2009q from 2020-01-30)"
0 commit comments