Encode certificates in s-expressions

[cfcs]

(Don't merge yet)

This makes it possible to restore a handshake_state (and probably other structures) from sexp.

I couldn't figure out how to add a certificate tag/atom to the serialized structure, does anyone know how that should be done?

[cfcs]

(now I learned you wrap the Atom foo in List [Atom "certificate" ; Atom foo]

[hannesm]

(Don't merge yet)

ok

This makes it possible to restore a handshake_state

I doubt this, since the handshake_state use crypto_context, which uses cipher_st, which is defined as:

type cipher_st =
  | Stream : 'k stream_state -> cipher_st
  | CBC    : 'k cbc_state -> cipher_st
  | AEAD   : 'k aead_state -> cipher_st

(* Sexplib stubs -- rethink how to play with crypto. *)
let sexp_of_cipher_st = function
  | Stream _ -> Sexp.Atom "<stream-state>"
  | CBC _    -> Sexp.Atom "<cbc-state>"
  | AEAD _   -> Sexp.Atom "<aead-state>"

let cipher_st_of_sexp =
  Conv.of_sexp_error "cipher_st_of_sexp: not implemented"

Also, Config.config is refered to from handshake_state, which contains an X509.Authenticator which serialise and deserialise is not implemented (neither was ever).

We used the tracing facilities to dump and replay connections (and connection attempts) - the cipher states can be recovered if the master secret can be computed/is known, and all messages are dumped (to figure out the sequence numbers). I'm curious what your exact use case is, and which parts you need to dump and restore.

On a second thought, why use s-expressions? The very nice Marshal module provides serialising and deserialising functionality builtin to OCaml already, which based on my experience of tracing and replaying, I'd recommend to use instead (unless you need some human-readable or interoperable with another application not written in OCaml).

[cfcs]

1. This makes it possible to restore a handshake_state

   I doubt this, since the handshake_state use crypto_context, which uses cipher_st, which is defined as: [...]

   Yes, the states that use those need special handling, but for a client that is a very limited subset. For those you need special handling.

2. X509.Authenticator: Yes. In my application I know what the X509.Authenticator is, so I set it to None before serializing, and reinstate it upon deserialization.

   • My use-case is https://github.com/cfcs/tlsping which provides a client + a proxy. The proxy is responsible for keeping the TLS connection to an IRC server alive (TCP, and sending encrypted data at regular intervals), the client is responsible for resuming the connection. The client needs to serialize the TLS state so that the computer running the client can be turned off, and at a later point (potentially on a different computer) restore the TLS state and resume control over the connection.

3. Why s-expressions:

   1. Because unlike Marshal they are consistent across OCaml versions (with explicit schema evolution / migration required for different tls library versions, when changes are made to the state).
   2. A lot of the deriving tooling can be used when the tls state definition remains unchanged, with a different serialization framework I would have to hand-serialize/deserialize everything.

[hannesm]

closing, this has conflicts with the main branch; also the s-expression marshalling got removed from ocaml-tls. happy to discuss how we can support use cases such as tlsping if there's demand and interest.