Oh, this thread is about the OpenSSL configuration package that Rich Salz promised!..
Daniel Kahn Gillmor <d...@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 _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev