[Libwebsockets] Private key in SSL

Andy Green andy at warmcat.com
Fri Jun 10 09:56:45 CEST 2016

On 06/10/2016 03:14 PM, Bruce Perens wrote:
> On Thu, Jun 9, 2016 at 10:39 PM, Andy Green <andy at warmcat.com
> <mailto:andy at warmcat.com>> wrote:
>     The key and the passphrase do pass through lws + openssl, that would
>     be enough if the attacker compromises the userland part and then
>     forces the admin to restart it.
> The key and passphrase remain within the token. So, we have to combine

Yes... but I was talking about the existing situation without any 
separate hardware.

It doesn't help that if openssl only needs the secrets briefly as you 
were explaining.

There's nothing lws (or Apache, or whatever) can do to improve matters 
afaik, because whatever it does is also exposed in userland.

> lws and openssl with OpenSC, which controls the token and provides a
> public-key engine to OpenSSL that causes the token to be used. We don't
> provide the key to lws, we just provide the /name/ of the key and it
> asks, through openssl and OpenSC, for the token to use it.
>             Or if my app can get things manipulated by this 'tamper
>         resistant
>             hardware', I can inject my request in the userland app, or by
>             duplicating what the app does on usb or whatever, and get things
>             signed by it as if I was the app.
> Yes. It will use the key if an unauthorized person gets in a position to
> ask it to. But it will never reveal the key. So, the compromise is limited.

Right it is 'limited' in the sense it succeeds not to lose the key, and 
that is of course a good thing.  But it doesn't really limit the damage 
of being compromised in any other way including the attacker being able 
to use the protected credentials for his own purposes while the 
intrusion goes undetected.


More information about the Libwebsockets mailing list