[Libwebsockets] Private key in SSL

Andy Green andy at warmcat.com
Fri Jun 10 07:39:48 CEST 2016



On 06/10/2016 01:19 PM, Bruce Perens wrote:
>> openssl runs in userland too and needs the key live.  I must pass
> openssl the key + passphrase in userland as it is.
>
> You'd think that OpenSSL would need the private key for the entire
> session, but it does not!
>
> The start of the OpenSSL transaction uses the private key to encrypt an
> ephemeral symmetrical encryption key. I think this uses the IDEA
> algorithm for symmetrical encryption. The ephemeral key is passed to the
> other side which decrypts it with the public key. The entire rest of the
> OpenSSL communication goes on using the ephemeral key and symmetrical
> encryption, and the private key is not used again!
>
> This is for two reasons: 1: public-key encryption is too slow. 2: SSL
> was actually designed to use hardware cryptographic token devices to
> protect the key.
>
> This really works, I've used it for years. I own private keys which I
> can't read, and they work!

Thanks... I didn't know that.

But that doesn't change anything, in this scenario lws + openssl would 
be the untrusted, compromised userland bit of the puzzle.

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.

Basically because lws is a userland app, he can't solve that scenario 
himself, so any solution must come from elsewhere like these hardware 
dongles at Openssl (plus or minus whatever lws might need to do to 
enable supporting that, like set ssl options).

> On Thu, Jun 9, 2016 at 9:52 PM, Andy Green <andy at warmcat.com
> <mailto:andy at warmcat.com>> wrote:
>
>
>
>     On June 10, 2016 12:16:05 PM GMT+08:00, Bruce Perens
>     <bruce at perens.com <mailto:bruce at perens.com>> wrote:
>     >Andy, the private key really should live in separate hardware from your
>     >process address space or anything that the OS can read.
>     >
>     >The proper practice is to use an encryption token which never discloses
>     >the
>     >private key, but performs the encryption in tamper-resistant hardware
>     >and
>     >only passes the result to your program.
>
>     It sounds good, but there seems to be some basic problem that I am
>     running a userland app, openssl runs in userland too and needs the
>     key live.  I must pass openssl the key + passphrase in userland as
>     it is.
>
>     As root I can go look at his memory pages, or I can debug his process.
>
>     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.
>
>     There are systems like trustzone with partitioning even in the mmu
>     to try to keep things secure, but openssl on a generic linux box
>     doesn't have anything like that (and there's still the problem of
>     deciding if a request from the untrusted part is legit or the
>     request IS the attack).

These hardware dongle solutions have this problem too... they cannot 
assess the legitimacy of the request and whatever the untrusted app does 
to make the request, an attacker who compromised the userland part can 
also do.  (It's all the same if userland part is apache + openssl or 
whatever)

Consider a successful attack on the userland part of a.com that uses 
"secure hardware", where the attacker sets up a fake a.com, gets victims 
to go there by controlling their DNS, and then tunnels the SSL 
activities to the compromised a.com and gets the "secure hardware" to 
use its true key on fake a.com traffic and passes it back through fake 
a.com to the victim!  He does not have the key but he has all the 
"secure" traffic of the victims until he's discovered.

The secure dongles should solve one aspect, making it difficult to 
liberate the key directly, but if the original problem was that the 
userland part could be compromised, they don't by themselves solve the 
fact of the compromise and what else can be done with that.

>     Linux kernel also has something about protected memory kernelside,
>     but I think it's just on kernelside.
>
>     So I dunno what lws can do about his request... is there something
>     concrete we can do?

Anyway nothing lws itself can do about it I think.

-Andy

>     -Andy
>
>     >On Thu, Jun 9, 2016 at 9:12 PM, Andy Green <andy at warmcat.com
>     <mailto:andy at warmcat.com>> wrote:
>     >>
>     >> Can you explain what a "not open memory area" looks like?
>     >>
>
>



More information about the Libwebsockets mailing list