Re: Man-in-the-middle attack against WebAuthn by a powerful attacker

Thanks, that's exactly what I wanted to propose - to use the certificate
fingerprint as an additional input in `clientDataJSON` for protection
against man-in-the-middle attacks that the server-side application later
verifies, this would be similar to TLS Client Certificate Authentication.

The proposal is here:
https://gitlab.com/mrts/webauthn-additions/wikis/Mitigation-for-man-in-the-middle-attack-against-WebAuthn-by-a-powerful-attacker

Yes, this is a significant change in browsers. Do you think it is possible
to propose this to browser working groups?
Would there be a JavaScript API for accessing the verified certificate?

In case you find the proposal valuable, how to proceed with this?

Best regards,
Mart S.

> Token Binding is a mitigation if used.   It meets the requirements for
> SP800-63-3 AAL3.
>
> There is a spec for reverse proxies to pass on token binding info.  So
> if properly set up a reverse proxy should be no problem.
>
> It is true that Edge is currently the only browser supporting it.  That
> may change.
>
> So I will grant that the mitigation is not widely available currently.
>
> The certificate thumbprint idea is used in Fido UAF as an option.
>
> It is better than the origin alone.   It still has issues with forward
> proxies.   The browser will  likely have the TLS certificate of the
> proxy not the one for the Authentication server.
>
> I don't think that it would meet the requirements of AAL3 because the
> assertion is not cryptographicly bound to the TLS session as it is in
> token binding.
>
> The thumbprint would need to be added both to CTAP2 and WebAuthn.  It
> could be an extension but is a significant change that browsers would
> need to support.
>
> John B.
>
> On 2/22/2019 2:05 AM, David Waite wrote:
> > This attack would imply at least partial control of networking
> > infrastructure (client routing or RP DNS) and of a legitimate CA,
> > meaning it is either an enterprise policy, an attack based on
> > enterprise policy, or state actor attack.
> >
> > Typically I would expect this to be solved by some form of certificate
> > transparency or certificate pinning:
> > - `HPKP` was a previous solution for this, but was unfortunately
> > abusable and will never see wide adoption
> > - Certificate Transparency (and the `Expect-CT` header) allow a site
> > to opt into certificate transparency for browsers that support it
> > - Including the TLS thumbprint of the TLS Certificate in
> > `clientDataJSON` (when token binding is not supported) would allow the
> > RP infrastructure to validate against a whitelist of TLS certificates.
> >
> > On Thu, Feb 21, 2019 at 2:29 PM Mart Sõmermaa <mart.somermaa@gmail.com
> > <mailto:mart.somermaa@gmail.com>> wrote:
> >
> >     Hello!
> >
> >     Have you considered that origin validation is not a sufficient
> >     countermeasure against man-in-the-middle attacks in case of a
> >     powerful attacker who controls responses to user's DNS requests
> >     and has a valid certificate that is trusted by the user's browser
> >     for the target host?
> >
> >     Full details of the attack here:
> >
https://gitlab.com/mrts/webauthn-additions/wikis/Man-in-the-middle-attack-against-WebAuthn-by-a-powerful-attacker
> >
> >     I have a proposal how to mitigate this, but I would like to hear
> >     your thoughts regarding this first.
> >
> >     Thanks in advance for looking into this,
> >     Mart Sõmermaa
> >
> >
> >
> > --
> > Ping Identity <https://www.pingidentity.com>
> > David Waite
> > Principal Technical Architect, CTO Office
> > dwaite@pingidentity.com <mailto:dwaite@pingidentity.com>
> > w: 303 468 2855