Re: [TLS] The risk of misconfiguration

[Viktor Dukhovni <[e-mail]>]

On Wed, May 07, 2014 at 05:58:43PM -0700, Watson Ladd wrote:

> > The solution to avoid accidental use of NULL ciphers is in the
> > client API, no client HELLO should ever include a mixture of NULL
> > and non-NULL ciphers-suites.
> 
> Why not make that a MUST in the RFC

No objection there, the use of NULL ciphers is typically by mutual
agreement between cooperating peers.  They are disabled by default,
and both ends have to enable them, with the client enabling *only*
NULL ciphers where applicable.

> And the same for anonymous DH?

Sadly this does not work.  Clients often don't know whether the
server supports any ADH cipher-suites or not.  Sending only ADH is
going to result in handshake failure.

> I think this solves most of the configuration issues without making any
> uses impossible.

Yes, for NULL ciphers.

> 1: Your ciphersuite list can have either authenticated or
> unauthenticated ciphers, but cannot have both.

No on this one.  That makes ADH/AECDH unusable.

> 2: It can have null encryption or use encryption, but not both.

This is what I am proposing as an implementation feature in the
client API.  It need not be a protocol feature.

> 3: If you try to break the above rules, the remote side (assuming it
> is compliant) bails out.

Just rule "2", not rule "1".

If you absolutely must remove something, I don't know of any
plausible use-case for the following cipher-suite:

    $ openssl ciphers -v aNULL+eNULL
    AECDH-NULL-SHA          SSLv3 Kx=ECDH     Au=None Enc=None      Mac=SHA1

This just MACs each message post an authenticated key exchage.  So
you get all or nothing message integrity.

When Postfix enables eNULL it always disables aNULL, so this
cipher-suite is never turned on.  I don't think there is either a
good reason to continue to to support this, or a real benefit to
"banning" it.

-- 
	Viktor.