Re: [MirageOS-devel] TLS on Xen

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

On 15 Jan 2015, at 15:09, Thomas Leonard <talex5@xxxxxxxxx> wrote:
> 
> On 13 January 2015 at 17:03, Thomas Leonard <talex5@xxxxxxxxx> wrote:
>> I've sent PRs for various patches to make TLS work on Xen. The changes
>> needed are:
>> 
>> 1. Add generic error handling for FLOWs, so we can propagate errors reliably.
>> 2. Fix the page alignment requirements for Netif.
>> 3. Add TLS support to conduit.
>> 
>> PRs:
>> 
>> Add `error_message` support for FLOW (can be merged now):
>> 
>> https://github.com/mirage/mirage-console/pull/33
>> https://github.com/mirage/ocaml-vchan/pull/60
>> https://github.com/mirage/mirage-tcpip/pull/98
>> 
>> (any other places implementing FLOW?)
>> 
>> Update the FLOW signature:
>> 
>> https://github.com/mirage/mirage/pull/346
>> 
>> Update TLS and Conduit (they both require and provide FLOW, so they
>> will be broken briefly):
>> 
>> https://github.com/mirleft/ocaml-tls/pull/225
>> 
>> We could add a dummy version of `error_message` here first to ease
>> upgrades, if desired. However, Conduit_mirage will break anyway due to
>> the extra TLS functor argument.
>> 
>> Make Netif not require aligned single-page buffers:
>> 
>> https://github.com/mirage/mirage-net-xen/pull/17
>> 
>> (optional: remove now-pointess copying in ocaml-tls)
>> 
>> You can then configure conduit for TLS like this:
>> 
>>        let mode = `TLS (tls_config, `TCP (`Port 443)) in
>> 
>> The mode contains the TLS arguments and a configuration for some
>> underlying channel.
>> 
>> I'm fairly happy with it. One minor problem is creating the TLS server
>> from a TLS config. Is there a function for this? In conduit, I
>> currently have:
>> 
>>          let server = Tls.Config.(server
>>            ~ciphers:config.ciphers
>>            ~version:config.protocol_versions
>>            ~hashes:config.hashes
>>            ~reneg:config.use_reneg
>>            ?certificate:config.own_certificate
>>            ~secure_reneg:config.secure_reneg)
>>            () in
>> 
>> However, this will silently fail to pass any new config attributes
>> that get adding later.
> 
> As suggested in the call yesterday, I've made a branch of the
> mirage-dev repository that contains updated versions of the packages
> with Xen/TLS support and tests them all together:
> 
>  https://github.com/mirage/mirage-dev/pull/52
> 
> I don't think it should hold anything up, but there are some
> improvements we might want to make in future:
> 
> - It would be good to make the config type abstract, so that conduit
> doesn't bring in dependencies on the TLS libraries.

Agreed; https://github.com/mirage/ocaml-conduit/issues/39

> 
> - It might be nice if mirage would let you configure an HTTP server
> without using conduit. Resolving URLs needs to be dynamic, but when
> providing a service you usually know statically which transport you
> want (http, https or vchan).

And agreed again: https://github.com/mirage/ocaml-conduit/issues/40

It should be easy enough to have a CoHTTP Request/Response functor
based on the V1_LWT.CHANNEL (which itself only needs a V1_LWT.FLOW).

That wouldn't have any URL resolution functions exposed, but only
the Client interface needs that anyway.

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