CP-310090 Stunnel lib: Expose unix socket path for TLS proxy

[changlei-li]

Add a module UnixSocketProxy in stunnel lib to provide a unix socket
path that can proxy TLS. This can offer a unified mechanism for
differnt users.
Stunnel listens on the unix socket path, accepts the connection
from local request then forwards to remote host and port with TLS.
The certificate checking in TLS connection can be done by stunnel
with the new trusted-certs implementation.
Two set of APIs are provided:

1. long-running stunnel proxy for that the user want to use it
   multi-times and handle the proxy lifecycle itself.

let stunnel_proxy =
  Stunnel.UnixSocketProxy.start ~verify_cert ~remote_host ~remote_port ()
in
match stunnel_proxy with
| Error e -> (* handle error *)
| Ok proxy_handle ->
    let socket_path = Stunnel.UnixSocketProxy.socket_path proxy_handle in
    (* use socket_path with HTTP clients *)
    ...
    Stunnel.UnixSocketProxy.diagnose proxy_handle |> function
    | Ok () -> (* all good *)
    | Error err -> (* handle connection errors *)
    ...
    Stunnel.UnixSocketProxy.stop proxy_handle (* clean up when done *)

2. short-lived stunnel proxy for that the user just want to use
   one-shot with auto cleanup.

Stunnel.UnixSocketProxy.with_proxy ~verify_cert ~remote_host ~remote_port
  (fun proxy_handle ->
    let socket_path = Stunnel.UnixSocketProxy.socket_path proxy_handle in
    (* use socket_path with HTTP clients *)
    ...
    Stunnel.UnixSocketProxy.diagnose proxy_handle)
    ...
  )

[psafont]

Xapi already has a system to manage stunnel instances, and it's placed in ocaml/libs/stunnel/stunnel_cache.ml. This is done to limit the amount of stunnel instances running and therefore the amount of memory used by them. I think having a module that allows creating instances without controlling this can lead to memory exhaustion and other issues.

I think the proxy module should be redone.

I think having better errors is something that needed very much, so thanks for enhancing that, but I'm afraid I have to ask for changes regarding the handling of stunnel instances

[changlei-li]

Xapi already has a system to manage stunnel instances, and it's placed in ocaml/libs/stunnel/stunnel_cache.ml. This is done to limit the amount of stunnel instances running and therefore the amount of memory used by them. I think having a module that allows creating instances without controlling this can lead to memory exhaustion and other issues.

I think the proxy module should be redone.

I think having better errors is something that needed very much, so thanks for enhancing that, but I'm afraid I have to ask for changes regarding the handling of stunnel instances

Hi @psafont. The background is to use unix socket path file to support licensing as we have cpp/python code to communicate with license server. So the exposing the unix socket path with a stunnel instance is a unified mechanism for this case (and also the trusted certs you are reviewing rencently). This is not for xapi to use.
In my view, stunnel_cache is a different level to manage reuse and limit the stunnel instances. While this PR just add the proxy by unix socket path. It should be compared to Stunnel.with_connect, Stunnel.with_client_proxy_systemd_service.
In the licensing case, we just use one long running stunnel instance, so no need to compare to stunnel_cache.

[psafont]

So, if I understood correctly, the stunnel proxy module is meant to be used from a different process from the xapi one. which means the cache can't be shared.

Can the process use directly the code in the module, or does it need some kind of RPC to access this functionality? I'm asking this because you mentioned it's C++ and python code that do the connections

[changlei-li]

So, if I understood correctly, the stunnel proxy module is meant to be used from a different process from the xapi one. which means the cache can't be shared.

Can the process use directly the code in the module, or does it need some kind of RPC to access this functionality? I'm asking this because you mentioned it's C++ and python code that do the connections

Please be aware this is just the stunnel lib, although it is in xapi repo. Briefly says, component(OCaml) will use the code directly to create stunnel instance with proper certificates. The stunnel will listen on the unix socket, then other code(non OCaml) can communicate with the unix socket path. Stunnel will proxy it to remote tls host.

[changlei-li]

Rebase to lastest feature/trusted-certs and squash the commits