Skip to content

Commit fa5664f

Browse files
committed
Polish comment + grade cap reason for STARTTLS
1 parent 7c0ccb3 commit fa5664f

1 file changed

Lines changed: 12 additions & 14 deletions

File tree

testssl.sh

Lines changed: 12 additions & 14 deletions
Original file line numberDiff line numberDiff line change
@@ -22933,20 +22933,18 @@ run_rating() {
2293322933
pr_headlineln " Rating (experimental) "
2293422934
outln
2293522935

22936-
22937-
if [[ -n "$STARTTLS_PROTOCOL" ]]; then
22938-
read -r -d '' grade_cap_reason <<'EOF'
22939-
TL;DR: E-mail transfer via port 25 is broken and the amendments suggested so far are duct tape. So please do not expect testssl.sh to shut up.
22940-
22941-
Explanation: For other than SMTP you should use TLS as per RFC 8314. For SMTP however there's this thing named reality: A mail server cannot
22942-
just switch to the mail submission port 587 only and continue to receive mail from everyone. Even if you advertise this via SRV record (RFC 6186).
22943-
For STARTTLS there's no way to tell for testssl.sh whether it is secure. A MitM can always intercept the connection, unless the client checks
22944-
the certificate accordingly (it's getting better but some just don't). TLSA Records/DANE and MTA-STS (RFC-8461) on the server side can help too.
22945-
But as said, it's useless unless the client MTA checks all that which no tool can check.
22946-
EOF
22947-
# We can't use newlines in the message, as the grade-sorting function will mess up the reason
22948-
set_grade_cap "T" "$(tr '\n' ' ' <<<$grade_cap_reason)"
22949-
fi
22936+
[[ -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,
2295022948

2295122949
pr_bold " Rating specs"; out " (not complete) "; outln "SSL Labs's 'SSL Server Rating Guide' (version 2009q from 2020-01-30)"
2295222950
pr_bold " Specification documentation "; pr_url "https://github.com/ssllabs/research/wiki/SSL-Server-Rating-Guide"

0 commit comments

Comments
 (0)