[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... -anil _______________________________________________ MirageOS-devel mailing list MirageOS-devel@xxxxxxxxxxxxxxxxxxxx http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |