Git
/
testssl.sh
mirror of https://github.com/drwetter/testssl.sh.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Polish comment + grade cap reason for STARTTLS

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