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

RFC 9266: Channel Bindings for TLS 1.3 support #742

Open
Neustradamus opened this issue Jul 28, 2022 · 10 comments
Open

RFC 9266: Channel Bindings for TLS 1.3 support #742

Neustradamus opened this issue Jul 28, 2022 · 10 comments
Assignees
Milestone

Comments

@Neustradamus
Copy link
Contributor

Neustradamus commented Jul 28, 2022

Can you add the support of RFC 9266: Channel Bindings for TLS 1.3?

Channel Bindings for TLS: https://datatracker.ietf.org/doc/html/rfc5929

Little details, to know easily:

  • tls-unique for TLS =< 1.2
  • tls-server-end-point
  • tls-exporter for TLS = 1.3

I think that you have seen the jabber.ru MITM and Channel Binding is the solution:

Thanks in advance.

Linked to:

cc: @simo5, @quanah, @iboukris, @hyc, @GuidoKiener, @ksmurchison, @aamelnikov, @lhoward, @dilyanpalauzov, @JanParcel, @Jakuje, @whitehse, @michael-o, @slesru, @brong.

@GuidoKiener
Copy link
Contributor

Thank you for the hint.
The cyrus-sasl library already supports a generic function for channel binding (e.g. sasl_setprop(conn, SASL_CHANNEL_BINDING, &cb). The applications (using the cyrus-sasl lib) need to add support for tls-exporter type, e.g. here: https://github.com/cyrusimap/cyrus-imapd/blob/master/imap/tls.c#L1316
Do you know of any reference implementation using the function SSL_export_keying_material(..)?

@Neustradamus
Copy link
Contributor Author

@GuidoKiener: Thanks for your comment!

For example:

You can see the code in Mellium SASL by the author of the RFC9266:

Prosody IM has been updated:

Miranda NG has been updated:

GNU SASL (GSASL) has been updated:

glib/glib-networking has been updated, it was compatible with draft before:

@Neustradamus
Copy link
Contributor Author

@GuidoKiener (and others): One year after, have you looked?

You can see a list with -PLUS variants here:

@GuidoKiener
Copy link
Contributor

@GuidoKiener (and others): One year after, have you looked?

You can see a list with -PLUS variants here:

Thank you for pushing SCRAM-*-PLUS mechanism. I don't have any relation to the Cyrus IMAP project, but I only use the Cyrus-SASL library for the HiSLIP 2.0 project. There are other people who are maintaining Cyrus IMAP.
BTW what do you think about SCRAM-SRP? Wouldn't it be better to push this protocol? SCRAM requires strong passwords, otherwise passwords can be cracked with brute force attacks after a TLS session (provided a MITM can listen to the TLS streams).

@Neustradamus
Copy link
Contributor Author

@GuidoKiener: SCRAM-SRP?

@GuidoKiener
Copy link
Contributor

GuidoKiener commented Sep 3, 2023

@GuidoKiener: SCRAM-SRP?

@Neustradamus Sorry, it was a typo. I wanted to ask for SASL SRP (Secure Remote Password). https://www.cyrusimap.org/sasl/sasl/authentication_mechanisms.html#srp.

@GuidoKiener
Copy link
Contributor

This issue can be closed when #823 is imerged.

@quanah
Copy link
Contributor

quanah commented Jul 23, 2024

@Neustradamus As noted in #800 we need a code example for #824 to get merged. Thanks!

@quanah quanah added this to the 2.2.0 milestone Jul 23, 2024
@Neustradamus
Copy link
Contributor Author

@quanah: I have relaunched @aamelnikov.

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

3 participants