Re: [whatwg/fetch] Clarification on CORS preflight fetches for TLS client certificates (#869)

mikkorantalainen left a comment (whatwg/fetch#869)

> This exclusion treats the TLS client certificate as a confidential credential on par with cookies and `Authorization`. But a certificate and its public key are public _by construction_. An X.509 certificate (RFC 5280) is a CA-signed binding over a public key, designed to be distributed, containing only public information; nothing in it confers access on its own.

If I've understood correctly, the rationale for excluding all kind of credentials for the preflight request is to prevent preflight from being used to detect session/authentication state to 3rd party server, not about secrecy of the credentials.

Basically the attack that the lack of credentials is trying to prevent is using e.g. cross-domain request from attacker.com to safe.com to detect if the visitor of attacker.com has credentials to safe.com or not. This could be used to e.g. detect which organisation/bank/whatever-secure-entity the victim visiting the attacker.com already has which makes implementing phishing attacks much more powerful.

That is, using credentials for OPTIONS might allow preflight to succeed and the javascript running on attacker.com could use timing attack to detect this from connection that's missing the client certificate for the OPTIONS request.

So this is not about safety of the credentials but about preventing timing attack to detect which credentials the user has.

Of course, this is all just part of the workaround mess I mentioned earlier. If preflight used some other method than OPTIONS this couldn't be used to probe 3rd party servers that are not trying to use CORS. This workaround was implemented because the browser cannot know if the 3rd party server expects to see CORS requests at all and if the server doesn't know about CORS requests but it knows about TLS client certificates, the preflight request could be used to probe if the victim has a client certificate.

This might have been possible to avoid by inventing a new method such as CORS instead of reusing OPTIONS for the preflight check but I'm not entirely sure if even that could have been used to detect usage of safe.com by 3rd party server as a side-channel information leak. I'm afraid not. This feels like networking counterpart of Spectre class security vulnerabilities.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/869#issuecomment-4825456670
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/issues/869/4825456670@github.com>