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

IV_PROTO tls-ekm does not work nicely with a debian server #181

Closed
hannesm opened this issue Dec 4, 2023 · 3 comments · Fixed by #243
Closed

IV_PROTO tls-ekm does not work nicely with a debian server #181

hannesm opened this issue Dec 4, 2023 · 3 comments · Fixed by #243

Comments

@hannesm
Copy link
Contributor

hannesm commented Dec 4, 2023

As remarked by @reynir in #169 (comment):
I observed AEAD decrypt failures on both the OpenVPN™ server and the client when using tls 1.3 on my own debian server with both tls-crypt and tls-crypt-v2. Using tls 1.2 works fine however. I tested with the main branch and I can reproduce the same behavior (except for tls-crypt of course).

Interestingly I can't reproduce against the OpenVPN™ server running on FreeBSD.

@reynir: could you add OpenVPN version numbers to this issue so at a later point in time we can try to reproduce with the exact versions?

On the FreeBSD server, we use openvpn-2.6.8

@reynir
Copy link
Contributor

reynir commented Dec 4, 2023

I used openvpn 2.6.3 and a custom build with extra debug logging and tls-crypt protocol_dump fix 2.7_git. In both cases OpenSSL 1.1.1w is used.

@hannesm
Copy link
Contributor Author

hannesm commented Dec 4, 2023

ah, good that you mention it -- we are using OpenSSL 1.1.1h-freebsd 22 Sep 2020 on the FreeBSD machine

hannesm added a commit that referenced this issue Dec 4, 2023
disable advertisement of ekm for now #181
reynir added a commit that referenced this issue May 7, 2024
reynir added a commit that referenced this issue May 7, 2024
reynir added a commit that referenced this issue May 7, 2024
@hannesm
Copy link
Contributor Author

hannesm commented May 10, 2024

With mirleft/ocaml-tls#495 I can establish an EKM session with TLS 1.3 between our server and client (both notun).

The old Debian server side issue may be related to openssl/openssl#3940 -- but I wasn;t able to track down which OpenSSL versions are affected.

I'd suggest: let's get a tls release out, and then enable EKM in MirageVPN (and if we encounter another issue, we can revert).

reynir added a commit that referenced this issue May 14, 2024
The bug has been identified in ocaml-tls and fixed by @hannesm. Clients
and servers should again use tls-ekm for key derivation if possible.

Closes #181.
raphael-proust pushed a commit to ocaml/opam-repository that referenced this issue May 15, 2024
CHANGES:

* tls: documentation: clarify send_application_data (mirleft/ocaml-tls#492 @reynir)
* BUGFIX: tls: export_key_material was wrong for the server side on TLS 1.3,
  reported in robur-coop/miragevpn#181 by @reynir, fix in mirleft/ocaml-tls#495 @hannesm
* FEATURE: tls: add channel_binding (RFC 5929, RFC 9266) support (tls_unique,
  tls_exporter, tls_server_endpoint), requested by @Neustradamus in mirleft/ocaml-tls#484, added
  in mirleft/ocaml-tls#496 by @hannesm
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging a pull request may close this issue.

2 participants