Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Accessing underlying TLS information #397

Open
misterfish opened this issue Aug 5, 2021 · 4 comments
Open

Accessing underlying TLS information #397

misterfish opened this issue Aug 5, 2021 · 4 comments

Comments

@misterfish
Copy link

What is the proper way to access the underlying TLS information in conduit 4.0? In particular, I would like to be able to access information about the epoch / certificates from within a server connection callback.

For reference, this was also discussed here: issue 253

Also, since tls is an optional dependency, how does one reliably access the Tls_lwt.t structure or something similar?

Thanks.

@misterfish
Copy link
Author

As this is a blocking issue for our project, I'm working on a temporary fix. We need to know the public key with which a client connected. Definitely not a permanent solution, but hopefully enough to get us unblocked.

The idea is:

process_accept in conduit_lwt_server.ml gets wrapped in a module functor, which gets passed a module argument by both conduit_lwt_tls.real and conduit_lwt_unix_ssl.real. The module argument has a type t which is Tls_lwt.Unix.t and (Ssl.context * Lwt_ssl.socket) respectively. t should help us derive the information we need about a connection in both the cases. At the end of it all, the connection callback, which is currently called like callback flow ic oc will become callback flow ic oc info. info will be for now a structure containing a single value, which is a callback for retrieving the public key for the connection. It's a callback so that the user can decide which information to retrieve and try to avoid affecting the performance.

This also requires a patch to Lwt_ssl, to add a get_public_key function which hooks into openssl.

I'll try to post results here of how this idea goes.

Still curious whether there is a more official way of doing this already or in the planning.

@dinosaure
Copy link
Member

I should advise you to use mimic for such purpose instead of conduit. Indeed, it as the ability to destruct the given type flow to what it really is such as:

module R = (val (Mimic.repr ssl_protocol))

let connect ~ctx = 
  Mimic.resolve ctx >>= function
  | R.T (ssl : Lwt_ssl.socket) -> ...

A small tutorial exists about mimic to help you to understand and use it here: https://dinosaure.github.io/mimic/mimic/index.html#the-server-side.

As far as I can say, we don't have for the mid-term a plan to improve significantly conduit.

@misterfish
Copy link
Author

Thanks for your answer. I'll check out mimic.

@misterfish
Copy link
Author

misterfish commented Aug 16, 2021

Update: the experiment worked and I am able to access connection information, but it took me a while to figure out why all the values in epoch_data relating to client certificates were empty or None.

Please see issue #401

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants