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

On 2012-08-24 19:38, Ryan Sleevi wrote:
> 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.

Hi Ryan,

There may indeed be confusion but what *I* consider multi-domain is a key that
can (by design) be consumed by multiple and potentially independent parties.

That is what I (rightly or wrongly) think is the Korean use-case which
actually is quite significant.

It is still beyond my understanding how you can combine this with an API
like WebCrypto.

Regards,
Anders

> 
> 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:54:46 UTC