On 10/01/2021 11:47, Дилян Палаузов via Exim-dev wrote:
RFC 5929 Channel Bindings for TLS defines the tls-unique channel
binding, stating that there was an old tls-unique, which was bad. The
new tls-unique uses the most recent TLS Finished message sent in the
token, whereas the old tls-unique used the first TLS Finished message.
Commit b1a32a3ce673 adds channel binding to openssl/exim,
2019/11. Actually only adds the OpenSSL support; channel binding
under GnuTLS was already there (since the introduction of the gsasl
driver, 2012/02).
using the
function SSL_get_peer_finished(). Compare this to the OpenLDAP
implementation, where libldap/tls_o.c:tlso_session_unique() uses
SSL_session_reused(s) ^ !is_server ? SSL_get_finished(s) :
SSL_get_peer_finished().
Exim only calls SSL_get_peer_finished() on the server side.
The client side calls SSL_get_finshed().
https://www.exim.org/exim-html-current/doc/html/spec_html/ch-the_gsasl_authenticator.html
says for server_channelbinding: “However, Channel Binding in TLS has
proven to be vulnerable in current versions. Do not plan to rely upon
this feature for security, ever, without consulting with a subject
matter expert (a cryptographic engineer). ”. Is this vulnerability
addressed in RFC 5929?
The docs warning was added in 2018/07. RFC 5979 was published 2010/07.
Draw your own conclusion.
I'm not a cryptographic engineer, and my advice is worth what you're
paying for it.
For reference, RFC 8446 (TLS 1.3) was published 2018/08. The situation
might be different in 1.3 vs. previous TLS versions. There appears to
have been recent work on the subject:
https://datatracker.ietf.org/doc/draft-ietf-kitten-tls-channel-bindings-for-tls13/
- which mentions a "triple-handshake" vulnerability found for RFC 5929
(I infer, for TLS 1.2) which in turn can be mitigated by using Extended
Master Secret. See RFC 7627; Exim enforces the requirements of
https://tools.ietf.org/html/rfc7677#section-4 (in short, if TLS Resumed
then require Extended Master Secret).
NOTE: I do not know if this is the concern that warranted the warning
in the Exim docs.
You should, as it says, consult a crypto expert.
Would you mind implementing Channel Binding also using Cyrus SASL and
doing interoperability test
The Cyrus SASL documentation is a disaster zone, from my memory of the
last time I tried to look. I'm not enthusiastic about doing anything
with that library.
Have you done any interoperability tests for the channel binding
No.
--
Cheers,
Jeremy
--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim
details at http://www.exim.org/ ##
