Re: [MirageOS-devel] TLS on Xen

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

On 16 Jan 2015, at 00:00, Thomas Gazagnaire <thomas@xxxxxxxxxxxxxx> wrote:
> 
>>> On 15 January 2015 at 17:58, Thomas Gazagnaire <thomas@xxxxxxxxxxxxxx> 
>>> wrote:
>>>>> - It would be good if you could configure an https server directly in
>>>>> config.ml. Currently, the need to configure it with a certificate and
>>>>> private key means this step has to go in the unikernel.
>>>> 
>>>> would it be possible to do something like for the IP address where we 
>>>> write the IP address in config.ml and then generate main.ml with the same 
>>>> IP printed in (ie. we "lift" the IP value from the configuration language 
>>>> to the main program)? Is there a way to print a server configuration as a 
>>>> string which can be interpreted as an OCaml value?
>>> 
>>> What's the recommended way to store the private key? I don't want it
>>> in config.ml because that's part of the source repository. I could
>>> load it there. I can't deploy via a public GitHub repository if the
>>> binary contains the key, so maybe it should be stored on a block
>>> device?
>> 
>> At the risk of abusing XenStore too much, it could also be written there
>> with suitably constrained permissions.  It would still need to be a block
>> device for normal cloud providers though.
> 
> maybe you can load the key when configuring your unikernel ie. it should be 
> available on the filesystem (or somewhere else) where you are configuring 
> your unikernel.
> 
> in that case you can:
> - in config.ml: call a function to read the private key
> - in main.ml: you can generate some code with the hard-coded private key read 
> while configuring

This doesn't meet the requirement that the binary can be redistributed on a 
public site (ala mirage-www-deployment).

> Regarding xenstore: I'm still a bit uncomfortable with passing dynamic secret 
> data in there

It does require some thought for sure -- but Xenstore is already a highly 
trusted component that can only be accessed by the root user in the guest 
kernel on conventional operating systems.  If not Xenstore itself, then some 
other channel of a similar nature (like Xentropyd has) would fit the bill.  
Unfortunately, this won't work on a public cloud provider, but a block device 
should be fine there.

Thinking about the block device more, perhaps we could have the notion of a 
transient block device -- attach it at boot to read the private key into 
memory, and then immediately eject it.

-anil
_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel