1

I've been looking into ways to detect a Man In the Middle attack, when the client has "duped" into trusting third party CA. Examples of this are, anti-virus applications and corporate firewalls who are now installing their own certificate authorities on the client machines with the intention of performing MITM functionality. And I'm sure that you can think of many other methods to perform this type of "Superfish" attack against consumer devices.

Given that this type of behaviour is now becoming more common, it would be better for sensitive websites (such as online banking) to include additional restrictions as to who can issue certificates. Once solution for this would have been to use the CAA DNS Record to indicate the Certificate Authorities that are allowed to issue certificates. However as has been pointed out in these forums, RFC-6844 falls short of providing any form of certificate validation.

The now deprecated HPKP protocol did require the users to have visited the site prior to the MITM proxy being installed, thus it's not a reliable mechanism and that’s probably why it was withdrawn.

As far as I can tell the other mechanisms such as Certificate Transparency, CRLs and OSCP, are only useful to verify that a certificate is valid, but they don't detect if a site is being exposed with a certificate that was issued by MITM proxy.

According to many of the posts on this website, the alternative technology is DNS-Based Authentication of Named Entities aka DANE [RFC 6698]. This can be used to publish the public key of any third-party website. However this has not been widely adopted, partly because this technology is seen as an alternative to the PKI rather than a mechanism to for validating certificate chains. And of-course DNSSEC would need to be extended to every domain to provide verifiable DNS information.

I think that I've exhausted every avenue for automatically detecting MITM. But I was wondering if there any other proposals for defending against this type of attack?

Thanks Paul

Improve this question
4
  • "...defending against this type of attack?" - what you describe is not an attack. The proxy CA is not installed in some illegal way but the user explicitly choose to install an AV with SSL interception to analyze HTTPS traffic or the company decided to install the proxy CA on their company managed systems. And that's why certificate pinning in browsers did never protect against this "attack", i.e. pinning is ignored if it is signed by an explicitly added CA. And the same policy will likely be done with other mechanisms of detecting MITM.
    – Steffen Ullrich
    Commented Jul 15, 2020 at 16:59
  • 4
    "... when the client has "duped" into trusting third party CA." - there is no way to distinguish if the client knowingly has installed the new CA or was didn't know what he was doing. And whoever "duped" the user into installing a CA might also have replaced the browser instead with a one who ignores specific certificate problems. I.e., any client-side protection you envision could simply haven been disabled. As for server-side techniques to detect MITM see Detect man-in-the-middle on server side for HTTPS.
    – Steffen Ullrich
    Commented Jul 15, 2020 at 17:14
  • The TLS protocol is assumed by the end-user to provide communications security. There can be no "Legal" interceptions that does not break the TRUST in security protocols. TLS Interception is a MiTM attack and should at a minimum be detected.
    – jwilleke
    Commented Jul 16, 2020 at 7:43
  • Thanks for your responses. I guess that there is no real way to mitigate against poor security on the client side. If the user's systems have been compromised, even by just accepting a 3rd party CA, then I guess all bets are off.
    – Paul
    Commented Jul 16, 2020 at 9:59

0

Reset to default

You must log in to answer this question.

Browse other questions tagged .