Git/testssl.sh
1
0
Fork 0
mirror of https://github.com/drwetter/testssl.sh.git synced 2025-10-31 13:55:25 +01:00
Code Issues Packages Projects Releases Wiki Activity

Polish comment + grade cap reason for STARTTLS

Browse Source
This commit is contained in:
Dirk
2024-10-14 14:17:02 +02:00
parent 7c0ccb3da7
commit fa5664f434
1 changed files with 10 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files

22
testssl.sh
View File

@@ -22933,20 +22933,18 @@ run_rating() {
pr_headlineln " Rating (experimental) "
outln
[[ -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"
if [[ -n "$STARTTLS_PROTOCOL" ]]; then
read -r -d '' grade_cap_reason <<'EOF'
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.
# TL;DR: STARTTLS connections are inherently insecure. A MITM can always intercept the connection, unless the client checks e.g. the
# 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)
# 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.
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
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).
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
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.
But as said, it's useless unless the client MTA checks all that which no tool can check.
EOF
# We can't use newlines in the message, as the grade-sorting function will mess up the reason
set_grade_cap "T" "$(tr '\n' ' ' <<<$grade_cap_reason)"
fi
# Explanation: There are active MitM attacks possible when using STARTTLS like https://github.com/tintinweb/striptls or
# https://github.com/libcrack/starttlsstrip. It depends on the client only whether it can detect such downgrade attack.
# As some SMTP servers are still misconfigured with wrong certificates it's is still common practice for SMTP client MTAs to
# accept those wrong certificates -- delivering e-mails is more important. There is an e-mail submission port 587 but a mail server
# cannot just switch to it and continue to receive mail from everyone. Even if you advertise this via SRV record (RFC 6186).
# TLSA Records/DANE and MTA-STS (RFC-8461) on the server side can help too,
pr_bold " Rating specs"; out " (not complete) "; outln "SSL Labs's 'SSL Server Rating Guide' (version 2009q from 2020-01-30)"
pr_bold " Specification documentation "; pr_url "https://github.com/ssllabs/research/wiki/SSL-Server-Rating-Guide"