W3C home > Mailing lists > Public > public-html-comments@w3.org > June 2012

Re: Resistance of <keygen> to client-side attack

From: Alan Egerton <eggyal@gmail.com>
Date: Thu, 14 Jun 2012 13:29:50 +0100
Message-ID: <CA+phaecWwfZHar_tKt0+FGaK+fPjTNetm-rdwYwbX4uSmCL4eg@mail.gmail.com>
To: Anders Rundgren <anders.rundgren@telia.com>
Cc: public-html-comments@w3.org
On Thu, Jun 14, 2012 at 10:32 AM, Anders Rundgren
<anders.rundgren@telia.com> wrote:
> If the browser/platform is corrupt (which a precondition for malicious
> client-side scripts), all bets are off.

Not necessarily.  An XSS attack, for example, could have introduced
malicious script without corrupting browser/platform.  It could then
proceed to alter the form that is submitted to the server so that the
generated public key is replaced with an attacker's key - and the
server has no means to know whether that has taken place.

Better would be for the generated public key to be returned to the
server in a channel which cannot be affected by client-side script,
such as an HTTP header.  I agree that this would not protect against
compromise of the browser/platform, but as you say all bets are off if
that is this case (and clearly avoiding such attacks is out of the
scope of HTML).

> Anyway, not even Apple actually use <keygen> in spite of pushing it!
> They have a much better system in iOS.  The Other Two" are also
> working on entirely new schemes for enrollment but none of the
> big vendors has any plans showing this to an SDO, at least not
> until they are firmly established by their respective customers :-)

The only time I have come across <keygen> in practice is on obtaining
a S/MIME key from StartCom using Safari.  Not only would the above
issue have existed, but I also did not receive any feedback to assure
me that the apparently downloaded key was indeed generated by <keygen>
(rather than simply generated elsewhere and sent to my browser).  This
is a browser UI issue, again out of scope for HTML, but nevertheless
one worth considering.

-- Alan
Received on Thursday, 14 June 2012 12:30:44 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:26:28 UTC