[openssl-dev] DTLS encrypt-then-mac

Matt Caswell matt at openssl.org
Thu Oct 13 22:48:50 UTC 2016



On 13/10/16 11:45, David Woodhouse wrote:
> ... is broken in 1.1. We negotiate it, then don't actually *do* it.
> 
> https://github.com/openssl/openssl/pull/1705 contains a patch to
> disable it unconditionally for DTLS, on both server and client.
> 
> In that same PR there's also a patch to actually implement EtM for DTLS
> — so that if it ever *stops* being disabled, it would actually work.
> That second patch is tested (by reverting the first) against a GnuTLS
> server both with and without EtM.
> 
> What remains is to have a conversation about how, if ever, we can turn
> EtM back on again.
> 
> There are a few mitigating factors:
>  • OpenSSL 1.1 is the only version which has this problem.
>  • OpenSSL 1.1 supports DTLSv1.2 and AEAD ciphers, which disable EtM.
> 
> However, the problem still exists for applications using OpenSSL 1.1
> with DTLSv1.0, where they *will* end up using a CBC cipher.
> 
> I don't think it makes much sense just to leave EtM disabled —
> depending on how you look at things, that's either not necessary (who
> cares about OpenSSL 1.1.0[ab]; just upgrade to 1.1.0c!), or not
> sufficient (1.1.0[ab] are still broken when talking to e.g. GnuTLS
> anyway, and *everyone* would need to stop doing DTLS+EtM).
> 
> So I think in the process of typing this mail, I've persuaded at least
> *myself* that the PR above should be refactored to include *only* the
> second patch; to *fix* EtM without disabling it.
> 
> Any dissenting opinions?

Not from me. It's broken. Lets fix it.

Matt


> 
> It really would be nice to have a way to disable EtM voluntarily
> though; especially for the DTLS_get_data_mtu() test cases that I've
> added in PR#1666.
> 
> 
> 


More information about the openssl-dev mailing list