-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[FEATURE] Check whether STARTTLS is enforced before MAIL FROM #1832
Comments
Can look into this. What I 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:
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) |
Okay, we can take this as a feature at least. |
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 @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 |
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. |
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
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. |
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 . |
Seems like i am also one of these |
Seems me are one of these 1% too.. This is a BUG, is a WRONG message that affects testssl functionality. And that 1%... ¿How do you know if you never validated it? |
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).
When sending
EHLO
to the server, we are expecting250-STARTTLS
as part of the capabilities. And to test whether it is enforced, one might go forward without it and try aMAIL FROM
.The text was updated successfully, but these errors were encountered: