Re: [openssl-dev] Proposed cipher changes for post-1.0.2
Hello, Dr. Stephen Henson st...@openssl.org wrote: |On Fri, Feb 13, 2015, Viktor Dukhovni wrote: | On Fri, Feb 13, 2015 at 11:59:13AM +, Salz, Rich wrote: | Some time ago, I had submitted a patch which allows administrators, but | most importantly OS distributors to set their own strings \ | in the configuration | And my intent is to pull this into master pretty soon. | We may not need a patch for this, I thought we were about to deprecate | OpenSSL_config() with its void return status and encourage folks |Just clarification. The initialisation we're recommending I normally refer |to as config modules. NCONF is a more general API for configuration files. I think an interesting question would be wether that configuration API will eventually obsolete the direct function interface? |Config modules were intended to be used for application setup so would |be a good place to add a system cipher string instead of a \ |whole new mechanism. |The only problem is that it would only work with application that supported |config modules. So break API compatibility and extend the mandatory SSL_library_init() to incorporate the functionality of CONF_modules_load_file(), introducing a SSL_library_free() counterpart? Or don't break compatibility and let SSL_library_init() internally do OPENSSL_config() unless OPENSSL_INIT_DONT_LOAD_CONF is defined? Or ditto but introduce a new SSL_library_init_with_conf() with an SSL_library_free_with_conf(), too. It will be very interesting to see how you will overcome that deadlocked situation. Have a nice weekend. --steffen ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Proposed cipher changes for post-1.0.2
On Thu, 2015-02-12 at 18:39 +0100, Steffen Nurpmeso wrote: 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 Some time ago, I had submitted a patch which allows administrators, but most importantly OS distributors to set their own strings in the configuration file, which software can then rely on, to provide a consistent security level: https://github.com/openssl/openssl/pull/192 regards, Nikos ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Proposed cipher changes for post-1.0.2
Some time ago, I had submitted a patch which allows administrators, but most importantly OS distributors to set their own strings in the configuration file, which software can then rely on, to provide a consistent security level: https://github.com/openssl/openssl/pull/192 And my intent is to pull this into master pretty soon. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Proposed cipher changes for post-1.0.2
Hello, Nikos Mavrogiannopoulos n...@redhat.com wrote: |On Thu, 2015-02-12 at 18:39 +0100, Steffen Nurpmeso wrote: | 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 | # /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 | |Some time ago, I had submitted a patch which allows administrators, but |most importantly OS distributors to set their own strings in the |configuration file, which software can then rely on, to provide a |consistent security level: https://github.com/openssl/openssl/pull/192 sorry, i haven't seen that yet. Of course, definining their very own profile in a special namespace is i think also a great option for users. --steffen ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Proposed cipher changes for post-1.0.2
On Fri, Feb 13, 2015, Viktor Dukhovni wrote: On Fri, Feb 13, 2015 at 11:59:13AM +, Salz, Rich wrote: Some time ago, I had submitted a patch which allows administrators, but most importantly OS distributors to set their own strings in the configuration file, which software can then rely on, to provide a consistent security level: https://github.com/openssl/openssl/pull/192 And my intent is to pull this into master pretty soon. And applications would need to opt-in to having this new profile apply, or more usefully need to be able to choose which application-specific file contains the desired profile. there's no such thing as a universal profile that works for all software. We may not need a patch for this, I thought we were about to deprecate OpenSSL_config() with its void return status and encourage folks to use the NCONF API, which should be able to handle this, or be close in any case. Just clarification. The initialisation we're recommending I normally refer to as config modules. NCONF is a more general API for configuration files. Config modules were intended to be used for application setup so would be a good place to add a system cipher string instead of a whole new mechanism. The only problem is that it would only work with application that supported config modules. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Proposed cipher changes for post-1.0.2
On Fri, Feb 13, 2015 at 03:54:50PM +, Dr. Stephen Henson wrote: Config modules were intended to be used for application setup so would be a good place to add a system cipher string instead of a whole new mechanism. The only problem is that it would only work with application that supported config modules. I don't think that's a problem. This is a good thing. We just need to encourage applications to adopt the use of appropriate config modules (if that's the right interface). -- Viktor. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Proposed cipher changes for post-1.0.2
On Fri, Feb 13, 2015 at 11:59:13AM +, Salz, Rich wrote: Some time ago, I had submitted a patch which allows administrators, but most importantly OS distributors to set their own strings in the configuration file, which software can then rely on, to provide a consistent security level: https://github.com/openssl/openssl/pull/192 And my intent is to pull this into master pretty soon. And applications would need to opt-in to having this new profile apply, or more usefully need to be able to choose which application-specific file contains the desired profile. there's no such thing as a universal profile that works for all software. We may not need a patch for this, I thought we were about to deprecate OpenSSL_config() with its void return status and encourage folks to use the NCONF API, which should be able to handle this, or be close in any case. -- Viktor. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Proposed cipher changes for post-1.0.2
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
Re: [openssl-dev] Proposed cipher changes for post-1.0.2
On Wednesday 11 February 2015 20:21:37 Viktor Dukhovni wrote: On Wed, Feb 11, 2015 at 12:59:22PM +0100, Hubert Kario wrote: On Tuesday 10 February 2015 21:46:46 Viktor Dukhovni wrote: On Tue, Feb 10, 2015 at 09:15:36PM +, Salz, Rich wrote: I would like to make the following changes in the cipher specs, in the master branch, which is planned for the next release after 1.0.2 Anything that uses RC4 or MD5 what was in MEDIUM is now moved to LOW Note, that RC4 is already the only commonly used cipher-suite in MEDIUM. Changing the definitions of EXPOR, LOW, MEDIUM introduces significant compatibility issues for opportunistic TLS (e.g. Postfix) where RC4 is still required for interop and is better than cleartext. Opportunistic TLS is a-typical use of TLS. One that is vulnerable to trivial MitM attacks by the very definition. Using ALL, possibly ALL:!aNULL, instead of DEFAULT doesn't make it much less secure. Yeah, right, 70-90% of the world's email using opportunistic TLS is atypical. XMPP server-to-server using opportunistic TLS is atypical, sorry the browser use-case is not the sole use of TLS. yes, when the encryption is implemented using post-it note with please don't enter on it it is atypical especially if you look at the amount of traffic that email and xmpp generate compared to HTTP... I'd like it to be different, but the reality is as it is. As for vulnerable to MiTM, opportunistic TLS is less vulnerable than cleartext. yes, point is that as long as you don't do verification of identity of peer they are only infinitesimally better from each other. The library should be secure by default, you have different need, which is interoperable by default. We can't have both. (I'll believe that you actually care that opportunistic TLS is not secure enough when Redhat deploys DNSSEC and DANE TLSA RRs for its MX hosts). What I say are not official Redhat statements, I argue arguments, not sides, and I don't work in IT so I have minimal impact on what our MXs do. -- Regards, Hubert Kario ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Proposed cipher changes for post-1.0.2
I think these definitions should stay the same, but I have no objection to disabling RC4 in DEFAULT, or entirely removing EXPORT/LOW. That seems inconsistent with your view that RC4 must remain in MEDIUM, yet you are willing to drop other terms that other applications might be using. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Proposed cipher changes for post-1.0.2
On Wed, Feb 11, 2015 at 03:15:11PM +, 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. Our customers during the last SSL exploits were hoping for a global configuration file actually to change cipher preferences. Something that is present in 1.0.2 although I have not checked it deeply yet. Ciao, Marcus ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Proposed cipher changes for post-1.0.2
Also, what about changing order so that 128bit+ AEAD and PFS are preferred over other ciphers (including 256 bit ones)? I sent in a patch for exactly that a while ago. Unfortunately I got zero feedback... https://mta.openssl.org/pipermail/openssl-dev/2015-January/000421.html Sorry for the delay; it's been on my todo list. I want to think about this more, but... yeah, probably. Hope that helps. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Proposed cipher changes for post-1.0.2
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 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. That doesn't mean that integer-based security levels is the right approach (is there documentation on what the OpenSSL semantics should be for these other than doc/ssl/SSL_CTX_set_security_level.pod?) -- it's possible that common use cases would be better. Then there could be an opportunistic use case that meets Viktor's goals, and a standard use case that hews closer to TLS BCP. --dkg ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Proposed cipher changes for post-1.0.2
Hi, On Tue, 10 Feb 2015 21:46:46 + Viktor Dukhovni openssl-us...@dukhovni.org wrote: Changing the definitions of EXPOR, LOW, MEDIUM introduces significant compatibility issues for opportunistic TLS (e.g. Postfix) where RC4 is still required for interop and is better than cleartext. Let me add some infos that may change the picture of RC4. From what I understand we talk about the next openssl version, which is likely still many months away. Until then a couple of things will likely happen: * The IETF has a draft to deprecate and explicitely forbid RC4 which will probably be an RFC by that time [1] * There are two yet unpublished new attacks on RC4 where only preliminary info is available [2] [3] So by the time openssl 1.0.3 or 1.1.0 or whatever it'll be called will be released we'll likely have an official document stating that using RC4 violates the standard. And we'll probably have more attacks (of course this point is a bit speculative, because they are unpublished yet). If anyone uses an RC4 only configuration then you should tell them to stop doing so. Now. Another thing people may find interesting: Chromium recently started to declare everything not PFS/AEAD as obsolete crypto. I like that and I hope Google (and others) will do more steps in that direction. Maybe that'll also change the picture on what should be considered HIGH. The CBC modes are currently in a state that could be described at there are some attacks, they're not really that practical and we have some mitigations in place. That's not super-worrying, but it's really not the thing I'd call a HIGH security cipher. [1] https://tools.ietf.org/html/draft-ietf-tls-prohibiting-rc4-01 [2] https://i.imgur.com/0myz7Zm.jpg [3] https://www.blackhat.com/asia-15/briefings.html#bar-mitzva-attack-breaking-ssl-with-13-year-old-rc4-weakness cu, -- Hanno Böck http://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42 pgp3WfFXnHCdN.pgp Description: OpenPGP digital signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Proposed cipher changes for post-1.0.2
On Wed, 11 Feb 2015 13:01:14 +0100 Hubert Kario hka...@redhat.com wrote: Also, what about changing order so that 128bit+ AEAD and PFS are preferred over other ciphers (including 256 bit ones)? I sent in a patch for exactly that a while ago. Unfortunately I got zero feedback... https://mta.openssl.org/pipermail/openssl-dev/2015-January/000421.html -- Hanno Böck http://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42 pgp0DzpKqWEVG.pgp Description: OpenPGP digital signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Proposed cipher changes for post-1.0.2
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. /r$ ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Proposed cipher changes for post-1.0.2
On Wed, Feb 11, 2015 at 12:59:22PM +0100, Hubert Kario wrote: On Tuesday 10 February 2015 21:46:46 Viktor Dukhovni wrote: On Tue, Feb 10, 2015 at 09:15:36PM +, Salz, Rich wrote: I would like to make the following changes in the cipher specs, in the master branch, which is planned for the next release after 1.0.2 Anything that uses RC4 or MD5 what was in MEDIUM is now moved to LOW Note, that RC4 is already the only commonly used cipher-suite in MEDIUM. Changing the definitions of EXPOR, LOW, MEDIUM introduces significant compatibility issues for opportunistic TLS (e.g. Postfix) where RC4 is still required for interop and is better than cleartext. Opportunistic TLS is a-typical use of TLS. One that is vulnerable to trivial MitM attacks by the very definition. Using ALL, possibly ALL:!aNULL, instead of DEFAULT doesn't make it much less secure. Yeah, right, 70-90% of the world's email using opportunistic TLS is atypical. XMPP server-to-server using opportunistic TLS is atypical, sorry the browser use-case is not the sole use of TLS. As for vulnerable to MiTM, opportunistic TLS is less vulnerable than cleartext. (I'll believe that you actually care that opportunistic TLS is not secure enough when Redhat deploys DNSSEC and DANE TLSA RRs for its MX hosts). -- Viktor. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Proposed cipher changes for post-1.0.2
On Tuesday 10 February 2015 21:15:36 Salz, Rich wrote: I would like to make the following changes in the cipher specs, in the master branch, which is planned for the next release after 1.0.2 Anything that uses RC4 or MD5 what was in MEDIUM is now moved to LOW Anything that was 40-bit encryption is removed: /* Cipher 03 EXP-RC4-MD5 removed */ /* Cipher 06 EXP-RC2-CBC-MD5 removed */ /* Cipher 08 EXP-DES-CBC-SHA removed */ /* Cipher 0B EXP-DH-DSS-DES-CBC-SHA removed */ /* Cipher 0E EXP-DH-RSA-DES-CBC-SHA removed */ /* Cipher 11 EXP-DHE-DSS-DES-CBC-SHA removed */ /* Cipher 14 EXP-DHE-RSA-DES-CBC-SHA removed */ /* Cipher 17 EXP-ADH-RC4-MD5 removed */ /* Cipher 19 EXP-ADH-DES-CBC-SHA removed */ /* Cipher 26 EXP-KRB5-DES-CBC-SHA removed */ /* Cipher 27 EXP-KRB5-RC2-CBC-SHA removed */ /* Cipher 28 EXP-KRB5-RC4-SHA removed */ /* Cipher 29 EXP-KRB5-DES-CBC-MD5 removed */ /* Cipher 2A EXP-KRB5-RC2-CBC-MD5 removed */ /* Cipher 2B EXP-KRB5-RC4-MD5 removed */ The value of DEFAULT changes to this: ALL:!LOW:!EXPORT:!aNULL:!eNULL The combination of the first and last changes means that anyone who wants or needs to use, say RC4 must explicitly say so. Comments? Maybe we should also move 3DES to MEDIUM? Given that this is effectively a 112 bit cipher... Also, what about changing order so that 128bit+ AEAD and PFS are preferred over other ciphers (including 256 bit ones)? -- Regards, Hubert Kario ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Proposed cipher changes for post-1.0.2
On Tuesday 10 February 2015 21:46:46 Viktor Dukhovni wrote: On Tue, Feb 10, 2015 at 09:15:36PM +, Salz, Rich wrote: I would like to make the following changes in the cipher specs, in the master branch, which is planned for the next release after 1.0.2 Anything that uses RC4 or MD5 what was in MEDIUM is now moved to LOW Note, that RC4 is already the only commonly used cipher-suite in MEDIUM. Changing the definitions of EXPOR, LOW, MEDIUM introduces significant compatibility issues for opportunistic TLS (e.g. Postfix) where RC4 is still required for interop and is better than cleartext. Opportunistic TLS is a-typical use of TLS. One that is vulnerable to trivial MitM attacks by the very definition. Using ALL, possibly ALL:!aNULL, instead of DEFAULT doesn't make it much less secure. -- Regards, Hubert Kario ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Proposed cipher changes for post-1.0.2
On Wednesday 11 February 2015 02:00:50 Viktor Dukhovni wrote: On Wed, Feb 11, 2015 at 12:22:44AM +, Salz, Rich wrote: RC4 in LOW has a bit of pushback so far. My cover for it is that the IETF says don't use it. So I think saying if you want it, say so is the way to go. By all means, don't use it, but it is not OpenSSL's choice to make by breaking the meaning of existing interfaces. If you put RC4 in LOW, one can no longer exclude LOW ciphers if one still needs RC4. Nobody uses single-DES, but enough peers still use (only) RC4 to make disabling of RC4 a choice best made by applications. if you upgrade to a new minor version of library and don't check configuration afterwards you're part of the problem example? ALL:!ADH and variations of thereof It *IS* the libraries duty to update the policies. Changing policies in the hundreds of applications that use it every time a cipher or protocol is broken is insanity. All the keyword definitions in ciphers(1) use the word currently. -- Regards, Hubert Kario ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Proposed cipher changes for post-1.0.2
On Tue, Feb 10, 2015, Viktor Dukhovni wrote: We should also recall that the master branch has introduced security levels, which may still need some work to become production-ready, but are likely a better mechanism for applications to move to more secure settings than incompatible changes in existing interfaces. I'd agree that the best approach is to use security levels. This covers a far wider set of parameters than just ciphersuites. For example on the master branch the default security level is 1: The security level corresponds to a minimum of 80 bits of security. Any parameters offering below 80 bits of security are excluded. As a result RSA, DSA and DH keys shorter than 1024 bits and ECC keys shorter than 160 bits are prohibited. All export ciphersuites are prohibited since they all offer less than 80 bits of security. SSL version 2 is prohibited. Any ciphersuite using MD5 for the MAC is also prohibited. This happens no matter what the cipher string is set to (unless it forcibly lowers the security level). So an application setting ALL will get the above conditions. In the light of poodle this could be ammended to make SSLv3 disabled at level 1 or above. Currently level 1 is the only real general purpose default (due to widespread use of SHA1 in certificates which offer less than 80 bits of security). The levels could be extended so there is more than one usable level. Security levels can currently only completely disable ciphersuites: this could be extended so they can prioritise them instead. For example that would allow the use of PFS+AEAD ciphersuites first, PFS not AEAD second and as a last resort RC4 at some levels. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Proposed cipher changes for post-1.0.2
On Tue, Feb 10, 2015 at 10:52:02PM +, Salz, Rich wrote: I'd further suggest to move everything that's not PFSAEAD from HIGH to MEDIUM. I think it's a little early to do that. But once TLS 1.3 is out, then yes :) This is NOT a decision a library should be making on behalf of applications. So, NO, not even then, except that of course when TLS 1.3 is negotiated, that's all you get, but that only happens with TLS 1.3 peers, which is fine and does not break compatibility, and does not require re-definition of the existing cipher-suite classes. We should also recall that the master branch has introduced security levels, which may still need some work to become production-ready, but are likely a better mechanism for applications to move to more secure settings than incompatible changes in existing interfaces. Not all applications are browsers folks, and libraries need to provide stable interfaces that mirror the application's intent consistent with expected behaviour of existing interfaces. Only new interfaces can freely shed compatibility baggage. -- Viktor. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Proposed cipher changes for post-1.0.2
On Wed, Feb 11, 2015 at 12:22:44AM +, Salz, Rich wrote: RC4 in LOW has a bit of pushback so far. My cover for it is that the IETF says don't use it. So I think saying if you want it, say so is the way to go. By all means, don't use it, but it is not OpenSSL's choice to make by breaking the meaning of existing interfaces. If you put RC4 in LOW, one can no longer exclude LOW ciphers if one still needs RC4. Nobody uses single-DES, but enough peers still use (only) RC4 to make disabling of RC4 a choice best made by applications. -- Viktor. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Proposed cipher changes for post-1.0.2
By all means, don't use it, but it is not OpenSSL's choice to make by breaking the meaning of existing interfaces. Except that we've explicitly stated we're breaking things with this new release. Those magic cipher keywords are point-in-time statements. And time has moved on. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Proposed cipher changes for post-1.0.2
On Tue, Feb 10, 2015 at 06:17:38PM -0500, Daniel Kahn Gillmor wrote: On Tue 2015-02-10 16:15:36 -0500, Salz, Rich wrote: I would like to make the following changes in the cipher specs, in the master branch, which is planned for the next release after 1.0.2 Anything that uses RC4 or MD5 what was in MEDIUM is now moved to LOW yes, please! There are lots of ways to disable RC4: * You can do that in a browser, or any other application * The NCONF interface allows one to specify this in suitable configuration files. * Security levels can be similarly specified, ... * TLS 1.3 will not support RC4, ... However, OpenSSL MUST NOT force this choice on applications or require them to be explicitly modified to continue to support RC4. It is NOT the library's job to set this policy. when these are removed, what will that do to a cipherstring that specifies them by negation? currently, this is an error: 0 dkg@alice:~$ openssl ciphers -v ALL:!NO-SUCH-CIPHER bash: !NO-SUCH-CIPHER: event not found PBKAC: $ openssl ciphers -v 'RC4:!FOOBARXYZZY' ECDHE-RSA-RC4-SHA SSLv3 Kx=ECDH Au=RSA Enc=RC4(128) Mac=SHA1 ECDHE-ECDSA-RC4-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=RC4(128) Mac=SHA1 AECDH-RC4-SHA SSLv3 Kx=ECDH Au=None Enc=RC4(128) Mac=SHA1 ADH-RC4-MD5 SSLv3 Kx=DH Au=None Enc=RC4(128) Mac=MD5 ECDH-RSA-RC4-SHASSLv3 Kx=ECDH/RSA Au=ECDH Enc=RC4(128) Mac=SHA1 ECDH-ECDSA-RC4-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=RC4(128) Mac=SHA1 RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 RC4-MD5 SSLv2 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 PSK-RC4-SHA SSLv3 Kx=PSK Au=PSK Enc=RC4(128) Mac=SHA1 EXP-ADH-RC4-MD5 SSLv3 Kx=DH(512) Au=None Enc=RC4(40) Mac=MD5 export EXP-RC4-MD5 SSLv3 Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 export EXP-RC4-MD5 SSLv2 Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 export -- Viktor. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Proposed cipher changes for post-1.0.2
Not all applications are browsers folks, and libraries need to provide stable interfaces that mirror the application's intent consistent with expected behaviour of existing interfaces. Please point to where it is documented what the value of MEDIUM means and what interface is being broken? I can't find anywhere that it says RC4 is by definition part of MEDIUM. /r$ ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Proposed cipher changes for post-1.0.2
currently, this is an error: 0 dkg@alice:~$ openssl ciphers -v ALL:!NO-SUCH-CIPHER bash: !NO-SUCH-CIPHER: event not found 0 dkg@alice:~$ Yeah, but that's coming from bash, not openssl :) ; openssl ciphers -v ALL | wc 111 6758403 ; openssl ciphers -v ALL:!FOOBAR | wc 111 6758403 RC4 in LOW has a bit of pushback so far. My cover for it is that the IETF says don't use it. So I think saying if you want it, say so is the way to go. /r$ ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Proposed cipher changes for post-1.0.2
On Tue 2015-02-10 19:22:44 -0500, Salz, Rich wrote: currently, this is an error: 0 dkg@alice:~$ openssl ciphers -v ALL:!NO-SUCH-CIPHER bash: !NO-SUCH-CIPHER: event not found 0 dkg@alice:~$ Yeah, but that's coming from bash, not openssl :) ; openssl ciphers -v ALL | wc 111 6758403 ; openssl ciphers -v ALL:!FOOBAR | wc 111 6758403 d'oh! of course, thanks. headdesks RC4 in LOW has a bit of pushback so far. My cover for it is that the IETF says don't use it. So I think saying if you want it, say so is the way to go. I think that's the correct position. People who want to be able to negotiate a deprecated cipher should need to explicitly state that that's their intent. --dkg ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Proposed cipher changes for post-1.0.2
On Wed, Feb 11, 2015 at 06:11:08AM +, Viktor Dukhovni wrote: I think these definitions should stay the same, but I have no objection to disabling RC4 in DEFAULT, or entirely removing EXPORT/LOW. And also MD5 (which subsumes all SSLv2 cipher-suites). 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. For example, the below yields a compact list of cipher-suites with little legacy baggage: DEFAULT:!EXPORT:!LOW:!MD5:!RC4:!SRP:!PSK:!aDSS:!aDH:!SEED:!IDEA:!kECDHr:!kECDHe A variant with RC4-SHA as a last resort would be: DEFAULT:!EXPORT:!LOW:!MD5:!SRP:!PSK:!aDSS:!aDH:!SEED:!IDEA:!kECDHr:!kECDHe:+RC4 -- Viktor. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Proposed cipher changes for post-1.0.2
On Wed, Feb 11, 2015 at 01:50:07AM -0500, Daniel Kahn Gillmor wrote: RC4 in LOW has a bit of pushback so far. My cover for it is that the IETF says don't use it. So I think saying if you want it, say so is the way to go. I think that's the correct position. People who want to be able to negotiate a deprecated cipher should need to explicitly state that that's their intent. I do: aNULL:-aNULL:ALL:!EXPORT:!LOW:+RC4:@STRENGTH The proposal to now misclassify RC4 as LOW (lumped in with single DES and similar) needlessly breaks this. -- Viktor. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Proposed cipher changes for post-1.0.2
On Wed, Feb 11, 2015 at 03:33:03AM +, Salz, Rich wrote: Not all applications are browsers folks, and libraries need to provide stable interfaces that mirror the application's intent consistent with expected behaviour of existing interfaces. Please point to where it is documented what the value of MEDIUM means and what interface is being broken? The ciphers(1) manpage has set consistent expectations since the dawn of time (same meaning in 0.9.7, 0.9.8, 1.0.0 and 1.0.1): HIGH high encryption cipher suites. This currently means those with key lengths larger than 128 bits, and some cipher suites with 128-bit keys. MEDIUM medium encryption cipher suites, currently some of those using 128 bit encryption. LOW low encryption cipher suites, currently those using 64 or 56 bit encryption algorithms but excluding export cipher suites. EXP, EXPORT export encryption algorithms. Including 40 and 56 bits algorithms. EXPORT40 40 bit export encryption algorithms EXPORT56 56 bit export encryption algorithms. In OpenSSL 0.9.8c and later the set of 56 bit export ciphers is empty unless OpenSSL has been explicitly configured with support for experimental ciphers. Those currently's have meant the same thing for a decade and a half, the only change being a relaxation of HIGH to include AES128 in 2005 which introduces no interop issues. 1.0.0 and later: commit 61094cf3dc1cc0086f8bcb70f73cc5822a53b2be Author: Dr. Stephen Henson st...@openssl.org Date: Wed Sep 21 00:55:42 2005 + 128 bit AES ciphersuites should be classified as HIGH. 0.9.8 backport: commit daa657fb78b517ebcddeef09e17e8a20624ac314 Author: Dr. Stephen Henson st...@openssl.org Date: Wed Sep 21 00:57:28 2005 + 0.9.7 backport: commit 9f03d028e75c9376b3e4908dc666a8e75e03af61 Author: Dr. Stephen Henson st...@openssl.org Date: Wed Sep 21 00:58:48 2005 + I think these definitions should stay the same, but I have no objection to disabling RC4 in DEFAULT, or entirely removing EXPORT/LOW. -- Viktor. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Proposed cipher changes for post-1.0.2
On Tue, 10 Feb 2015 21:15:36 + Salz, Rich rs...@akamai.com wrote: Comments? Sounds good. I'd further suggest to move everything that's not PFSAEAD from HIGH to MEDIUM. -- Hanno Böck http://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42 pgpwviI3Wtd4z.pgp Description: OpenPGP digital signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Proposed cipher changes for post-1.0.2
On Tue, Feb 10, 2015 at 09:15:36PM +, Salz, Rich wrote: I would like to make the following changes in the cipher specs, in the master branch, which is planned for the next release after 1.0.2 Anything that uses RC4 or MD5 what was in MEDIUM is now moved to LOW Note, that RC4 is already the only commonly used cipher-suite in MEDIUM. Changing the definitions of EXPOR, LOW, MEDIUM introduces significant compatibility issues for opportunistic TLS (e.g. Postfix) where RC4 is still required for interop and is better than cleartext. I have no issues with changing DEFAULT, but would strongly prefer to not see RC4 demoted to LOW. Just define: DEFAULT = ALL:!aNULL:!EXPORT:!LOW:!RC4:!MD5 Which leaves from MEDIUM just SEED and IDEA: $ openssl ciphers -v 'MEDIUM:!aNULL:!MD5:!RC4' DHE-RSA-SEED-SHASSLv3 Kx=DH Au=RSA Enc=SEED(128) Mac=SHA1 DHE-DSS-SEED-SHASSLv3 Kx=DH Au=DSS Enc=SEED(128) Mac=SHA1 DH-RSA-SEED-SHA SSLv3 Kx=DH/RSA Au=DH Enc=SEED(128) Mac=SHA1 DH-DSS-SEED-SHA SSLv3 Kx=DH/DSS Au=DH Enc=SEED(128) Mac=SHA1 SEED-SHASSLv3 Kx=RSA Au=RSA Enc=SEED(128) Mac=SHA1 IDEA-CBC-SHASSLv3 Kx=RSA Au=RSA Enc=IDEA(128) Mac=SHA1 -- Viktor. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Proposed cipher changes for post-1.0.2
On Tue, Feb 10, 2015 at 10:38:01PM +0100, Hanno B?ck wrote: On Tue, 10 Feb 2015 21:15:36 + Salz, Rich rs...@akamai.com wrote: Comments? Sounds good. I'd further suggest to move everything that's not PFSAEAD from HIGH to MEDIUM. Thus breaking applications that were previously using HIGH as a reasonably interoperable setting. You can introduce all kinds of new settings, promote their use, even change the default, but incompatibly re-definining existing interfaces is not a winning strategy. -- Viktor. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Proposed cipher changes for post-1.0.2
Sounds good. Thanks. I'd further suggest to move everything that's not PFSAEAD from HIGH to MEDIUM. I think it's a little early to do that. But once TLS 1.3 is out, then yes :) ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Proposed cipher changes for post-1.0.2
On Tue 2015-02-10 16:15:36 -0500, Salz, Rich wrote: I would like to make the following changes in the cipher specs, in the master branch, which is planned for the next release after 1.0.2 Anything that uses RC4 or MD5 what was in MEDIUM is now moved to LOW yes, please! Anything that was 40-bit encryption is removed: /* Cipher 03 EXP-RC4-MD5 removed */ /* Cipher 06 EXP-RC2-CBC-MD5 removed */ /* Cipher 08 EXP-DES-CBC-SHA removed */ /* Cipher 0B EXP-DH-DSS-DES-CBC-SHA removed */ /* Cipher 0E EXP-DH-RSA-DES-CBC-SHA removed */ /* Cipher 11 EXP-DHE-DSS-DES-CBC-SHA removed */ /* Cipher 14 EXP-DHE-RSA-DES-CBC-SHA removed */ /* Cipher 17 EXP-ADH-RC4-MD5 removed */ /* Cipher 19 EXP-ADH-DES-CBC-SHA removed */ /* Cipher 26 EXP-KRB5-DES-CBC-SHA removed */ /* Cipher 27 EXP-KRB5-RC2-CBC-SHA removed */ /* Cipher 28 EXP-KRB5-RC4-SHA removed */ /* Cipher 29 EXP-KRB5-DES-CBC-MD5 removed */ /* Cipher 2A EXP-KRB5-RC2-CBC-MD5 removed */ /* Cipher 2B EXP-KRB5-RC4-MD5 removed */ when these are removed, what will that do to a cipherstring that specifies them by negation? currently, this is an error: 0 dkg@alice:~$ openssl ciphers -v ALL:!NO-SUCH-CIPHER bash: !NO-SUCH-CIPHER: event not found 0 dkg@alice:~$ i wouldn't want ALL:!EXP-DHE-DSS-DES-CBC-SHA to be an error, though. The value of DEFAULT changes to this: ALL:!LOW:!EXPORT:!aNULL:!eNULL The combination of the first and last changes means that anyone who wants or needs to use, say RC4 must explicitly say so. This looks good to me. Hanno wrote: I'd further suggest to move everything that's not PFSAEAD from HIGH to MEDIUM. I agree with this as well. It sets the stage for TLS 1.3. Thanks for pushing on this, Rich. --dkg ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
