[FEATURE] Check whether STARTTLS is enforced before MAIL FROM

[pbraun9]

STARTTLS is enforced over there, according to the SMTP HEALTH CAMPAIGN. However, the test ends-up with an overall grade of T, which is inappropriate.

./testssl.sh --starttls smtp xc.os3.su:25

Grade capped to T. Encryption via STARTTLS is not mandatory (opportunistic).

Linux 5.10.3 x86_64
    testssl.sh       3.1dev from https://testssl.sh/dev/
    (477bd13 2021-01-07 10:25:02 -- )
commit 477bd13899fd813c50c54d2273706f6bf7cb1065
./bin/openssl.Linux.x86_64

When sending EHLO to the server, we are expecting 250-STARTTLS as part of the capabilities. And to test whether it is enforced, one might go forward without it and try a MAIL FROM.

[drwetter]

Can look into this. What I dodid not like about this solution is testssl.sh is supposed to start the smtp handshake. See your point though.

There are alternatives like MTA-STS and DANE which seem more widespread to me, for the reason probably that it offers not a hard cut which makes sense if you prefer confidentiality over availability. Last but not least keep another thing in mind: It's up to the client whether it accepts your certificate or the one from evil eve. The sending MTA would need to enforce the check on your certificate. So e.g. an attacker with bigger power can probably do BGP spoofing and MITM the handshake with a forged server certificate.

MTA-STS is in the works, see #1815 . The server in question though doesn't support MTA-STS (and DANE also but it seems at least DNSSEC is supported). What is strange though that querying almost any TXT record always returns SPF values:

prompt> host -t TXT _mta-sts.os3.su
_mta-sts.OS3.su descriptive text "v=spf1 mx a -all
prompt> host -t TXT foo-beer.os3.su                                                                                                                                                                                              
foo-beer.os3.su descriptive text "v=spf1 mx a -all
prompt> 

This is offtopic but hard fails lead for forwarded mails originating from your domain to problems at the final recipient. ( If that instance doesn't look at the dmarc record which nullifies the SPF values, if I understand that correctly. Surprisingly the DMARC record is according to the specs)

[drwetter]

Okay, we can take this as a feature at least.

[pbraun9]

This is BUG, not a feature request, simply because of the output message and grade cap that tells about opportunistic STARTTLS. How is the check done in testssl.sh? If DANE and MTA-STS records are checked, that's another story. But then the output should report about those standards respectively. If there is no check whether STARTTLS is enforced or opportunistic, why report about it?

@drwetter you have a point about MX certificate verification, and that should also be part of the validations, if ever STARTTLS matters, and that is stated in the SMTP Health Campaign. However let's not mix-up things and keep PKIX vs DANE and that new MTA-STS nonsense out of this issue. It's another story. I am referring to Grade capped to T. Encryption via STARTTLS is not mandatory (opportunistic).

[drwetter]

As we don't do this check, this is a missing feature ;-) Speaking of standards .... we didn't do this yet as it is a violation of RFC 3207 (A publicly-referenced SMTP server MUST NOT require use of the STARTTLS extension). Time has passed since 2002 but in fact not so much happened. :-/ There are still sending MTAs out there today which have a problem with refusing plain text mails -- which I (and probably others too) experienced first hand. So from the security standpoint you traded confidentiality+ integrity with availability.

When implemented in the end it's a question how we phrase this and whether we apply the SSLlabs rating.

[multiflexi]

I just started to deal with issue also. RFC 3207 also says: "A publicly-referenced SMTP server is an SMTP server which runs on port 25 of an Internet host listed in the MX record (or A record if an MX record is not present) for the domain name on the right hand side of an Internet mail address." So when I scan 587, to determine if "Encryption via STARTTLS is not mandatory (opportunistic).", it needs to either

• do SMTP handshake
  or
• change the result message

Also I have not found where in the SSL Labs Rating Guide is specified grade T for STARTTLS. I only found that it is for issues with certificate.
The current state just does not describe the truth IMHO.

[drwetter]

We used the "SSL Labs Rating Guide" 1:1 with the exception for applying it to STARTTLS too, with some discussion.

T is fine as long as it cannot be ensured yet that there's trust. "As long as": it's not implemented here. 99% of STARTTLS connections probably don't enforce anything and a MiTM would be possible. We don't want to relax the warning so that 1% are happy .