Re: A working multi-domain WebCrypto - TLS client cert auth

On Fri, Aug 24, 2012 at 5:04 AM, Anders Rundgren
<anders.rundgren@telia.com> wrote:
> Before taking on any major work to solve the multi-domain issue, I think it is worthwhile studying one existing already implemented and relatively widely used such solution.
>
> Is there anything fundamentally wrong with this solution except that it isn't a JS API?  I could imagine an X.509 client-certificate extension that would restrict the list of possible relying parties to what fits the use-case.
>
> A demo-server that asks for you to select one from *all* of your certificates:
> https://www.apache-ssl.org/cgi/cert-export
>
> BTW, multi-domain symmetric keys doesn't look like a terribly useful combination.
>
> Anders
>

Hi Anders,

Thanks for posting this. I actually think the scenario you describe
represents a single origin access model, which may be why there is
some confusion around single/multi-origin.

In the TLS client auth scenario, only one application (web or native)
actually has access to your keying material - the user agent or
application communicating with the (myriad) TLS servers. For each
origin you're performing TLS negotiation with, they only receive a
signed statement. This statement (the ClientCertificateVerify) is
constructed through combining material from the server with material
that it cannot control (the client's hello and random), thus ensuring
that the server cannot spoof or relay messages.

Under such a scenario, the "risk" is of native applications being able
to run on the client machine. A native application that is granted
unfettered access to the key (much like the user agent is) would be
allowed to sign any message. One class of applications that seek to do
this are 'malware' applications, which attempt to act as TLS MITM
while still preserving client auth.

If we apply a literal translation of these concepts, then we arrive at
a situation where a single origin has access to the actual key, but it
is permitted to mediate messages to other origins (eg: the
ClientCertificateVerify), based on their requests. In the Web model,
there are many ways to deliver such requests - iframes, postMessage,
intents are just a few examples - but the overall security is
preserved only when a single origin is permitted to access the key.

If you permit multiple origins, then any of those origins becomes a
potential target for compromise, and such attacks on Origin-B can be
then leveraged into MITM attacks on Origin-A.

Because of this, I think it is important to preserve same origin
policy restrictions, as discussed during and within the charter, and
look at ways for applications to expose mediated/'safe' ways for other
origins to request they sign or encrypt some message.

Does this help?

Received on Friday, 24 August 2012 17:38:37 UTC