On Sat, Dec 20, 2025 at 02:02:37PM +1100, Viktor Dukhovni wrote:

> Or perhaps not, if upon retrying they fail to refresh the policy, and
> proceed without authentication?  In other words, MTA-STS is mere
> security-theatre, trivially downgradable by an MiTM attack:
> 
>     {
>       "policies": [
>         {
>           "policy": {
>             "policy-type": "sts",
>             "policy-string": [],
>             "policy-domain": "charite.de",
>             "mx-host": []
>           },
>           "summary": {
>             "total-successful-session-count": 0,
>             "total-failure-session-count": 1
>           },
>           "failure-details": [
>             {
>               "result-type": "sts-webpki-invalid",
>               "sending-mta-ip": "185.58.85.221",
>               "receiving-mx-hostname": "mail-cbf-ext.charite.de.",
>               "receiving-mx-helo": "",
>               "receiving-ip": "193.175.73.208",
>               "failed-session-count": 1,
>               "additional-information": "",
>               "failure-reason-code": ""
>             }
>           ]
>         },
>         {
>           "policy": {
>             "policy-type": "no-policy-found",
>             "policy-string": [],
>             "policy-domain": "charite.de",
>             "mx-host": []
>           },
>           "summary": {
>             "total-successful-session-count": 1,
>             "total-failure-session-count": 0
>           },
>           "failure-details": []
>         }
>       ]
>     }

There are two deliveries in that report, one "sts" failure, and one
"no-policy-found" success.

On Sat, Dec 20, 2025 at 08:50:58PM +0000, Gellner, Oliver via mailop wrote:

> If Mimecast would proceed without authentication the connection should
> be established successfully, as then the certificate or its chain
> wouldn‘t be validated.

Which matches the report, though it is possible (unclear) that the
success in question was a previous report, with policy enforcement
disabled when sending reports.

> > cross-cert is ommitted, its subject is now itself a well known
> > trust-anchor that does not need a backup cross-issuer.
> 
> He can try that but I would be surprised if Mimecast didn‘t trust the
> Hellenic Academic and Research Institutions ECC RootCA 2015 but trust
> a root certificate from the same organization which was only recently
> issued.

Every possible mistake is made by someone on the Internet.

> Even if that would be true, Mimecasts TLS stack should be able to deal
> with extraneous certificates in the chain, otherwise they would run
> into a lot of other problems.

IIRC mimecast have had TLS issues with more than just Ralf's system.
We're yet to learn the real story.

-- 
    Viktor.  🇺🇦 Слава Україні!
_______________________________________________
mailop mailing list
[email protected]
https://list.mailop.org/listinfo/mailop

Reply via email to