Date: Thu, 14 Apr 2016 09:19:28 -0700
From: Tony Arcieri <bascule@...il.com>
To: Árpád Magosányi <mag@...was.rulez.org>
Cc: "fulldisclosure@...lists.org" <fulldisclosure@...lists.org>
Subject: Re: [FD] end of useable crypto in browsers?

On Sat, Apr 9, 2016 at 2:34 AM, Árpád Magosányi <mag@...was.rulez.org>
wrote:

> Browser developers are dropping support for X509 key generation.
> Yes, <keygen> have its problems. But window.crypto - which is meant to
> replace it - have no way to save keys in the browser's keystore.


Using X.509 client certificates with browsers has a *huge* problem: they
don't follow the same-origin policy, and <keygen> was not designed for this
in mind. Without following SOP, browsers wind up doing a terrible thing:
prompting the user to select which TLS client cert/key to use with a
particular web site. This is bad for both UX and security/privacy: users
must make a decision, and if they make the wrong one they end up leaking
information about their key to a potential attacker.

Newer technologies like FIDO U2F tie generated keys to an "AppID" (Yubico
goes as far as to include the AppID in key derivation itself), i.e. an
"origin". This not only improves the UX by never having to prompt the user
which certificate to use, but has the effect of making such tokens
"unphishable" because an attacker domain will always get different keys
from any other (as opposed to doing a challenge-response auth system with a
key shared across origins, where an attacker can trick you into exposing
it, and effectively MitMing the challenge/response)

The reality of <keygen> is its many problems meant adoption was extremely
low, so it's not surprising that browser vendors want to axe it.

-- 
Tony Arcieri

_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Powered by blists - more mailing lists