[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MirageOS-devel] new nocrypto/x509/tls releases

> On 5 Dec 2015, at 00:29, Hannes Mehnert <hannes@xxxxxxxxxxx> wrote:
> hey,
> David tagged nocrypto-0.5.2
> ===========================
> - avoids the opam variable nocrypto-inhibit-modernity, uses the
> environment variable NOCRYPTO_NO_ACCEL instead (this makes
> opam-1.2.0/1.2.1 happy)!
> - does not include intrinsic-related headers if SSE/AES-NI is disabled
> (e.g. on OpenBSD).

Awesome!  I'll get on with an OpenBSD port of tlstunnel now then.
I'm hoping to switch my SMPTD setup on Recoil.org to fronting 
via this rather than OpenSSL soon...

> API documentation at https://mirleft.github.io/ocaml-nocrypto/
> X.509 0.5.0 brings you
> ======================
> - public key fingerprint verification (in addition to now deprecated
> certificate fingerprint verification)
> - building certificate paths from the received set (RFC 4158) instead
> of requiring a strict chain (if the other side sends the trust
> anchor/self-signed certificate, this is ok now; or if the other side
> sends the chain in the wrong order)
> - trust anchors given to Authenticator.chain_of_trust are not validated
> (to contain KeyUsage / BasicConstraint extensions) anymore, users have
> to use valid_ca and valid_cas to filter CAs upfront (previously there
> was a whitelist of CAcert certificates which are ok to not have a
> KeyUsage X.509v3 extension, but this whitelist did not scale).
> The main reason for this change is that if the user provides us with a
> set of trust anchors, the user actually knows what they are doing (and,
> as described in RFC 5280, a trust anchor is identified by its issuer
> (ASN.1 distinguished name) and public key.
> The path building results in slightly different validation failures
> (since now, instead of a single chain, we build a set of chains, and
> report `InvalidChain to the user).  You can manually build_paths and
> verify_chain individually.
> API documentation at https://mirleft.github.io/ocaml-x509/

Just checking -- do we need any upper bound constraints on old users
of ocaml-tls for this?

> TLS 0.7.0
> =========
> - session resumption (interface: server side can pass a `session_hash :
> SessionID.t -> epoch_data option` function, client can provide a
> `cached_session : epoch_data`) [SessionID is a OrderedType and HashedType)
> - session hash and extended master secret support (security mitigation
> for secure-resumption)
> - both lwt and mirage layers block if renegotiation is in progress (some
> inconsistency we found when running the tls demo server, and by now we
> have a clue what the right thing to do is)
> - the mirage layer had a concurrency problem if read and write was
> called from different tasks (the same was present at an earlier point in
> the lwt layer as well)
> - public key pinning instead of certificate pinning interface
> - the "tls/" prefix was dropped from certificate and keys in the mirage
> X.509 module (all your application won't be able to find their keys
> anymore, sorry)
> The default TLS configuration no longer enables renegotiation (since
> renegotiation together with resumption is insecure (if the other side
> does not implement session hash) to enable session resumption in more
> scenarios.
> Client
> ------
> To enable resumption on the client side, some code like the following is
> needed:
> let config = Tls.Config.client ~authenticator ~cached_session () in
> lwt (ic, oc) = Tls_lwt.connect_ext config (host, port) in
> where cached_session can be retrieved from an already established
> earlier session in the following way:
>  lwt t = Tls_lwt.Unix.connect config (host, port) in
>  let cached_session = match Tls_lwt.Unix.epoch t with
>    | `Ok e -> e
>    | `Error -> invalid_arg "error retrieving epoch"
>  in
> Server
> ------
> For a server it would be great to have a standalone LRU cache package,
> but there is none in opam (although ocaml-git, containers, ... all
> implement LRU caches).
> The cache:
> module HT = Hashtbl.Make (Tls.Core.SessionID)
> let add_session_to_cache, session_cache =
>  let cache = HT.create 7 in
>  ((fun ed -> HT.add cache ed.Tls.Core.session_id ed),
>   (fun id -> if HT.mem cache id then Some (HT.find cache id) else None))
> and once a session is established, insert it:
> Tls_lwt.Unix.accept config s  >>= fun (t, addr) ->
> (match Tls_lwt.Unix.epoch t with
> | `Ok e -> add_session_to_cache ed
> | `Error -> ()) ;
> handle (Tls_lwt.of_t t) addr
> And pass the session_cache function to Tls.Config.server.

An Irmin-based LRU so that we have persistence here?  Not sure how
the above implementation does GC of sessions...


MirageOS-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.