Re: [TLS] The risk of misconfiguration

[Viktor Dukhovni <[e-mail]>]

On Thu, May 08, 2014 at 04:44:14PM +0200, Martin Rex wrote:

> The problem with unsolicited DH_anon cipher suites being available to
> an unsuspecting application is that it may easily allow bypassing of
> the check of the server certificate depending on the API architecture
> of the SSL stack and how it is used by the application.

We're back to implementation issues, which should be addressed by
implementations.  In OpenSSL for example the "DEFAULT" cipher-suite
omits anonymous cipher-suites.  Non-default cipher-suites are
configured by the application.

The Postfix SMTP client, for example, automatically appends ":!aNULL"
to the application-administrator configured cipher-suite when it
wants to elicit a certificate from the remote SMTP server.  The
Postfix SMTP server automatically appends ":!aNULL" when it wants
to solicit a client certificate from the remote SMTP client.

This is not rocket science.  If you want to add similar safety
measures in new high-level APIs, that's fine.  I still see no reason
to neuter the protocol.

> Configurability of cipher suites (such as HIGH) for administrators
> MUST NOT allow enabling of DH_anon cipher suites, because this is
> a request _by_the_administrator_, and not _by_the_application_.

The OpenSSL domain-specific-language for specifying cipher-lists
provides a set of elementary properties that can be use to construct
cipher lists by combining atoms with "+" (AND) and combining those
with ":" (OR), with special semantics for leading "-" and "!".

It is somewhat unfortunate that some think of "HIGH" as a way of
specifying high security, all it does is select symmetric algorithms
with long keys.  This is a user-interface issue.

There is new code in master that provides security levels, rather
than cipher-suite list building blocks.

> DH_anon cipher suites should only be made available, if at all,
> when the application *CODE* explicitly calls a non-standard
> API call that signals to the TLS stack, that the application code
> knows about the resulting semantics and can properly deal with
> the resulting behaviour.

Still not a reason to remove these from the protocol.

> I also believe that the current behaviour of OpenSSL, to enable DH_anon
> cipher suites when the cipher suite configuration string "HIGH" is
> used, is extremely unsafe.

I doubt you don't understand "HIGH", so you're likely alluding to
the fact that many others might not.  That's fine, OpenSSL ciphersuite
configuration is too difficult for most users, that's an API issue
and an application design issue (when applications simply pass the
buck to the user).

> DH_anon have two more serious drawbacks compared to ignoring an untrusted
> server certificate:  the client can not even "pin" the server's certificate
> for future connections to the same server (i.e. only an initial leap-of-faith),
> and it completely precludes the use of a client certificate to authenticate
> the client to the server.

Not much use if the application has no code for pinning and no
mechanisms to interact with a "user" when pins fail.

> My very personal opinion is that DH_anon cipher suites are pure bloat
> without value.  We do not even implement them in our TLS implementation.

Right more "I don't use it, so out it goes".  The protocol and many of its
implementations are general purpose and serve many use-cases.  Custom
implementations that make different trade-offs are fine, but are not
a valid rationale for neutering the protocol or all implementations.

> But I'm OK with what rfc5246 says about them in the paragraph quoted above.
> Implementors can just leave them away from their implementations, and
> the consumers will be *MUCH* better of with the result. 

This is certainly true in application-specific products, less so
in general-purpose libraries.

> I do not see the value in making this availble for an extremely small
> group of experts like Nico who could devise niche usage scenarios where
> _they_ could operate them safely with hand-selected and manually hardened
> application software, compared to the inherent danger to the large
> unwashed masses (of consumers and app-software).

Well, GSSAPI with channel-binding and without certs is not so
exotic.  Nor is opportunistic TLS in MTAs.  I think it is quite
clear that removing ADH and AECDH is an overzealous reaction
to heartbleed.

If there are concerns about interface safety in particular
implementations, they need to be addressed in the right place.
(Sometimes in applications rather than in libraries, in which
case the library documentation may need to provide better
application guidance).

-- 
	Viktor.