[openssl-dev] Proposed cipher changes for post-1.0.2

Steffen Nurpmeso sdaoden at yandex.com
Thu Feb 12 17:39:49 UTC 2015


Oh, this thread is about the OpenSSL configuration package that
Rich Salz promised!..

Daniel Kahn Gillmor <dkg at fifthhorseman.net> wrote:
 |On Wed 2015-02-11 10:15:11 -0500, Salz, Rich wrote:
 |>> Note that for most applications the correct approach to configuring
 |>> ciphersuites should be to start with DEFAULT and subtract what they don't
 |>> want.  The library is then responsible for a generally \
 |>> sensible default order
 |>> and default exclusions.
 |>
 |> I strongly disagree.  Most applications should explicitly list the
 |> ciphers they DO want.  That is the only way an application can be sure
 |> of what it is getting, without consulting external parties or
 |> configuration.  Otherwise, when the next Crime or Poodle or
 |> NameOfTheWeek comes out, you have no idea if you are vulnerable or not
 |> unless you look at something like the OpenSSL source code.
 |>
 |> For what it's worth, I believe that "security levels" make this
 |> problem much worse.
 |
 |I disagree with you here, Rich.  There is ongoing evolution of our

I do, too.

 |understanding of TLS best practices, including standards, cryptanalysis,
 |and interoperability.  This dynamic situation seems unlikely to be come
 |static at any point in the future (changes in standards, cryptanalysis,
 |and the state of the network will continue to occur).  Even those of us
 |who spend a lot of time thinking about these matters have a hard time
 |keeping up.
 |
 |As a larger ecosystem, we have maybe three main options to manage this
 |dynamism:
 |
 |  0) every adminstrator of every TLS-using network service and every
 |     user of every TLS-using client needs to fiddle with TLS parameter
 |     selection as changes happen.
 |
 |  1) every developer of every TLS-using tool (client or server) needs to
 |     fiddle with TLS parameter selection as changes happen.
 |
 |  2) every library that implements TLS needs to fiddle with TLS
 |     parameter selection as changes happen.
 |
 |Situation (0) is clearly untenable (it's also what we are valiantly
 |attempting today, e.g. https://bettercrypto.org/, because the other
 |things haven't happened effectively).
 |
 |And situation (1) is just plain unlikely to happen.  Most software
 |developers *want* TLS to be "magic sauce" that they can sprinkle on and
 |have it Just Work.  They do not want to keep track of which parameters
 |are considered a bad idea this month, and they certainly don't want to
 |release new versions of their software just because someone says "hey,
 |you need to update your cipherstring".
 |
 |On the other hand, the people who are experts in this situation and who
 |understand the dynamics best are going to be the folks tapped for the
 |work in (2).  This is why these kinds of things should be done by
 |default in the TLS implementations.

I absolutely support all statements of Daniel Kahn Gillmore, but
especially that dynamism must be handled at a place that can be
adjusted without the necessity for any recompilation.
And i want to point to OPENSSL_config(3) which states for a longer
time duration:

       It is strongly recommended that all new applications call
       OPENSSL_config() or the more sophisticated functions such as
       CONF_modules_load() during initialization (that is before starting any
       threads). By doing this an application does not need to keep track of
       all configuration options and some new functionality can be supported
       automatically.

and so this finally appears to me as a natural place for such
things.  (The next version of the MUA i maintain will, also
finally, add support for this, for example.)

I think it was a bug report (sigh; btw., is the new EVP test still
broken regarding "evp_test(33743) malloc: pointer being freed was
not allocated"?) where i've expressed my own personal feelings
about that topic, in that i think the best would be if the
configuration file would be extended to offer the necessary
possibilities, yet i would dramatically change the current
semantics, for example regarding $OPENSSL_CONF, but there also
should be an option to enable the usual Unix configuration file
chain way of doing things ("global configuration file", "$HOME
configuration file"), and an administrator should have the option
to fixate some settings, possibly via a new "!" prefix to
a variable option, as in

  # /etc/openssl.rc
  [ciphers]
  DEFAULT=ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384
  !ALL=ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384

so that a user could do

  # ~/.openssl.rc
  [ciphers]
  DEFAULT=ECDHE-RSA-AES256-GCM-SHA384

but not

  # ~/.openssl.rc
  [ciphers]
  ALL=ECDHE-RSA-AES256-GCM-SHA384

because the administrator cramped the possibilities.
The good thing about that approach is definitely that necessary
changes after revealed protocol or cipher insecurities could be
applied immediately by anybody after reading an announcement mail,
without the need for any recompilation or even a library release.
Of course OpenSSL could provide a "conf" package that would
distribute the necessary changes officially, and so could to
distributions, too.

Even more so if three files would be used (OpenSSL, system-global,
per-user).  Like that the OpenSSL one could be packaged separately
and administrators could adjust the system-global template.
Of course a mechanism like rc.conf and rc.local could also be used
instead, yet i think having that possibility as such would be
great.

Of course there need to be more flags (e.g., "don't load user
file") and some utility should gain the possibility to perform
syntax checking.
But the mechanism as such is worth thinking about, imho.

--steffen


More information about the openssl-dev mailing list