Re: [exim-dev] On Channel Binding over SMTL/TLS

Pàgina inicial
Delete this message
Reply to this message
Autor: Jeremy Harris
Data:  
A: exim-dev
Assumpte: Re: [exim-dev] On Channel Binding over SMTL/TLS
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