Re: What we were using public key authentication for

On 24 Mar 2016, at 12:08 AM, Tim Berners-Lee <timbl@w3.org> wrote:

> This is the system we have been using for someone to be able to identify themselves as the owner of a web page, like a blog.

This is also the system used by my grandmother’s pension fund to secure systems internal to her pension fund. It is also the same system used by organisations such as the BBC across tens of thousands of people to secure their data in transit between layers in their systems. Keygen provides a secure vendor neutral and standards compliant way to get a digital certificate securely onto a machine.

Sure, my grandmother doesn’t know or care about certificates, but she sure cares about her pension fund.

> We have been doing this using client certs, but the UI was unloved, the  keygen API weird and had bugs, browsers have had a war against client certs.  But the system worked!   Until keygen got turned off in Chrome and Firefox  a few days ago.

Not only did the system work, the system of client certs is immune to man in the middle attacks.

With a certificate on both sides of the connection, if one side is compromised by a man in the middle (think hacked CA, mistrusted root, whatever), the security on the other side of the connection is still intact, and the connection will fail safe. Sure, Eve can pretend to be your bank, but Eve cannot pretend to be you, and so any attempt by Eve to try insert herself between you and your bank will fail.

Over at Apache httpd we care about existing users, and we go to significant lengths to ensure that none of our users are suddenly DoSed by changes made. If we want to change something we deprecate the old, and ensure that something new exists to replace the old before removing it so our users aren’t left suddenly in the lurch. In contrast, Firefox and Chrome have arbitrarily ripped the carpet out from users without warning in a systematic attempt to remove strong crypto from the browser ecosystem, which in contrast to the Apache approach represents a significant lack of project maturity and governance.

The browser is seeing the erosion of an important security feature, and we should be concerned by this.

> So can we get this functionality using web crypto in the short term?
> 
> Suppose we 
> 1) generate the keys in a web app using web crypo, store them in ephemal strage, and rejenerate them any time the use clears the key storage. Use them in a custom HTML form based auth session with the server in which we invent our own PK based authentication protocol.

How do I know my browser generated the key, and that the key wasn’t given to me by someone else? Without reverse engineering the javascript code I was given to run I can’t, and as such web crypto offers no security guarantees to the end user.

> 2) genearte the keys using math, possibly web cryto with “exportable” keys, and download a .pem file to the user’s desktop.  Get the user to click on the .pem and go through the process of installing the cert on their site. Hope fingers crossed the browsers don’t just block the use of client certs at all!

Again, if I don’t know for sure I generated the key, then there is no security for me.

> 3) Switch the while thing over to use openID-connect to connect people to some password-protected site?

This relies solely on trust of the PKI. If I compromise any CA you trust, I can help myself to your identity at will.

Regards,
Graham
—

Received on Thursday, 24 March 2016 11:50:19 UTC