Re: FIPS Capable Ciphers List
On Wed, May 15, 2013, Santhosh Kokala wrote: Hi All, I have a use case where an admin can configure the Ciphers from UI. I have this code in the backend that tries to set the cipher meth = TLSv1_client_method(); ctx = SSL_CTX_new(meth); sslretval = SSL_CTX_set_cipher_list(ctx, ts_str(cipher)); When a user sets a cipher such as MD5 when the device is in FIPS mode the above call returns an error code. I am thinking to validate the input cipher against the list of FIPS supported ciphers before calling SSL_CTX_set_cipher_list(). Is there a function where I can get a list of FIPS supported ciphers? Just a couple of additional points to the excellent replies already. If you're in FIPS mode then only FIPS ciphersuites can be used so ALL will result in only FIPS ciphersuites being used (note this includes ciphersuites offering no encryption). Also the special cipher string FIPS can be used: this works outside FIPS mode too. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: FIPS Capable Ciphers List
On 5/15/2013 3:27 AM, Viktor Dukhovni wrote: On Wed, May 15, 2013 at 12:58:37AM +, Santhosh Kokala wrote: I have a use case where an admin can configure the Ciphers from UI. I have this code in the backend that tries to set the cipher meth = TLSv1_client_method(); ctx = SSL_CTX_new(meth); sslretval = SSL_CTX_set_cipher_list(ctx, ts_str(cipher)); When a user sets a cipher such as MD5 when the device is in FIPS mode the above call returns an error code. I am thinking to validate the input cipher against the list of FIPS supported ciphers before calling SSL_CTX_set_cipher_list(). Is there a function where I can get a list of FIPS supported ciphers? The OpenSSL cipherlist strings is a rather subtle language, I would not expose it directly to users. Instead define a menu of cipher grades, and have the administrator choose from that. The menu of cipher grades should: - Be monotone. Each grade restricts the cipher list to increasingly more secure options. The sets of underlying ciphers corresponding to each grade should form a total order under set inclusion. - Be pre-validated. Don't give users choices that make them feel stupid when their choice is rejected as invalid. - Be something the user can understand. For example, Postfix provides the grades export, low, medium and high. Unlike the OpenSSL EXPORT, LOW, MEDIUM and HIGH the Postfix grades are inclusive of all stronger ciphers: export = EXPORT + LOW + MEDIUM + HIGH low = LOW + MEDIUM + HIGH medium = MEDIUM + HIGH high= HIGH the actual definitions are more complex and are approximately: export = ALL:@STRENGTH low = ALL:!EXPORT:@STRENGTH medium = ALL:!EXPORT:!LOW:@STRENGTH high = ALL:!EXPORT:!LOW:!MEDIUM:@STRENGTH this avoids including eNULL and other ciphers normally omitted from ALL. You may want DEFAULT rather than ALL, if anonymous ciphers are not appropriate in your application. If the underlying choices need to be configurable, that should generally not be via the UI, rather via a configuration file of some sort. This assumes your users are normal users, not SSL protocol testers who want fine-grained control and understand OpenSSL ciphers in detail. As a knowledgeable user, I despise user interfaces like that, and tend to recommend against such products even for novices. A good user interface would provide a strength-sorted list of check boxes for individual ciphers (automatically filtered to show only available ciphers as returned by SSL_get_cipher_list or SSL_get_ciphers), plus convenience boxes to check/uncheck various strength groups in the list. The convenience push buttons could be implemented by temporarily applying OpenSSL cipher keywords such as MEDIUM to a scratch SSL context (not connected to anywhere), then using SSL_get_cipher_list or SSL_get_ciphers to get back a list of which ciphers fall into that category. Similarly, the list of available check boxes can be sorted by setting ALL:@STRENGTH on such a scratch context. The key non-experimental benefit of such fine grained control is that it allows an administrator to work around new threats without having to wait for OpenSSL to release an updated library, distributions testing and packaging it, the application developers doing the same, then the admin testing the new-and-improved product for unwanted regressions in other areas. For instance, some of the recent attacks against the SSL/TLS protocol left some ciphers unaffected by pure chance (even though they were actually weaker ciphers), and security conscious Administrators needed to turn off most other ciphers until various applications became available in versions with proper fixes that allowed them to turn the stronger ciphers back on. Security compliance checkers quickly started checking for these workaround settings, before some major products were updated. It was quite an ordeal to apply the workarounds in some products where detailed cipher adjustment was left as a semi-undocumented complex config file manipulation for experts only. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: FIPS Capable Ciphers List
As a knowledgeable user, I despise user interfaces like that As a knowledgeable user, you are in the minority and it is certainly your right to complain if your choices are restricted. and tend to recommend against such products even for novices. I firmly believe this is wrong. A good user interface would provide a strength-sorted list of check Strength isn't absolute and unchanging. Which is stronger -- RC4 or AES? (See http://threatpost.com/attack-exploits-weakness-rc4-cipher-decrypt-user-sessions-031413/ and http://www.openssl.org/news/secadv_20130205.txt ) The key non-experimental benefit of such fine grained control is that it allows an administrator to work around new threats without having to wait for OpenSSL to release an updated library This can also be done by having crypto profiles in the application, and just changing those profiles values. FWIW, we are doing something like this at Akamai. Our info-sec team will create and own a handful of crypto profiles, and we will be pushing customers to just use those profiles, rather than enter raw OpenSSL strings themselves. One of the driving forces for this was my review of a couple of thousand of cipher-suite specifications created by customers and Akamai staff. Not a pretty sight. :) /r$ -- Principal Security Engineer Akamai Technology Cambridge, MA __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: FIPS Capable Ciphers List
On Wed, May 15, 2013 at 01:07:23PM +0200, Jakob Bohm wrote: If the underlying choices need to be configurable, that should generally not be via the UI, rather via a configuration file of some sort. This assumes your users are normal users, not SSL protocol testers who want fine-grained control and understand OpenSSL ciphers in detail. As a knowledgeable user, I despise user interfaces like that, and tend to recommend against such products even for novices. You seem to have neglected the configurability of the underlying choices. That's done by experts, such you, Rich or myself (if I may be so bold). In Postfix users can when they need to do so adjust the underlying the cipherlist specs, but they almost never need to do that, and asking them to do so when they simply want a knob to tune the minimum strength (or choose an appropriate profile) would be a disservice. OpenSSL cipherlists are not for novices. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: FIPS Capable Ciphers List
On 5/15/2013 4:38 PM, Salz, Rich wrote: As a knowledgeable user, I despise user interfaces like that As a knowledgeable user, you are in the minority and it is certainly your right to complain if your choices are restricted. and tend to recommend against such products even for novices. I firmly believe this is wrong. A good user interface would provide a strength-sorted list of check Strength isn't absolute and unchanging. Which is stronger -- RC4 or AES? (See http://threatpost.com/attack-exploits-weakness-rc4-cipher-decrypt-user-sessions-031413/ and http://www.openssl.org/news/secadv_20130205.txt ) Which is exactly what I am talking about further down my mail. Strength in cryptography is always an estimate based on knowledge at the time it is entered into the code, and since the OpenSSL team already provides a built in relative measurement which is updated at a reasonable frequency, there is rarely a reason for application vendors to create their own scales and lists. The key non-experimental benefit of such fine grained control is that it allows an administrator to work around new threats without having to wait for OpenSSL to release an updated library This can also be done by having crypto profiles in the application, and just changing those profiles values. FWIW, we are doing something like this at Akamai. Our info-sec team will create and own a handful of crypto profiles, and we will be pushing customers to just use those profiles, rather than enter raw OpenSSL strings themselves. One of the driving forces for this was my review of a couple of thousand of cipher-suite specifications created by customers and Akamai staff. Not a pretty sight. :) I was talking about a user interface to specify settings without requiring a rebuild of the applications. Whether you call the resulting configuration data crypto profiles or just cipher settings is not as important as making it easy to specify and define them on the fly, without waiting for some slow moving info-sec team to come up with a new configuration, then for some other slow team to approve it, then for some slow release team to ship it, then for some slow deployment team to deliver it. In other words it is about the ability to post on bugtraq or some other security forum: If you are using an XYZ application without a vendor patch for this CVE, open the ABC dialog, click on DEF, then uncheck all the lines that say/do not say GHI or JDK. If this is not easily done (as mass communication from a 3rd party expert to regular admins), then this makes the application unserviceable in the field and thus unsuitable even for the regular admins who do not understand the reasons for why this particular setting works around a problem, because they will be literally helpless. If an application is locked down to only let the admin choose amongst approved security configurations, everybody is in trouble while waiting for bureaucracy to approve and deploy new configurations, and chances are the vendor will end up with a bad reputation for either being slow to deliver a secure configuration or rushing out a buggy release in order to make the new configuration available on time (in which case the vendor will also get a bad rep for not providing the secure configuration choice for older unsupported releases). Now I realize that in large organizations like Akamai, the word Profile can have two different meanings: Settings profile as in a collection of profiles stored under a name and referenced wherever used makes sense only if the nature of the application is such that a profile holds many related settings, is likely to be used many or zero times by any given user and profiles can easily be added, edited and removed by the admin as desired. Specification profile as in a document written by a committee listing which aspects of some collection of other documents and functionality are to be combined in various scenarios tend to degrade into bureaucracy for bureaucracy's sake. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: FIPS Capable Ciphers List
On Wed, May 15, 2013 at 8:26 AM, Viktor Dukhovni openssl-us...@dukhovni.org wrote: OpenSSL cipherlists are not for novices. Like everything else about an old API that grew organically, it has too much surface area. It's unreasonable to rely on expert performance to prevent errors - it should be hard to make mistakes when the consequences are great. That's a reliable principle of good design. - M
RE: FIPS Capable Ciphers List
I was talking about a user interface to specify settings without requiring a rebuild of the applications. And on this, we completely agree :) -- Principal Security Engineer Akamai Technology Cambridge, MA __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: FIPS Capable Ciphers List
On 5/15/2013 5:26 PM, Viktor Dukhovni wrote: On Wed, May 15, 2013 at 01:07:23PM +0200, Jakob Bohm wrote: If the underlying choices need to be configurable, that should generally not be via the UI, rather via a configuration file of some sort. This assumes your users are normal users, not SSL protocol testers who want fine-grained control and understand OpenSSL ciphers in detail. As a knowledgeable user, I despise user interfaces like that, and tend to recommend against such products even for novices. You seem to have neglected the configurability of the underlying choices. That's done by experts, such you, Rich or myself (if I may be so bold). In Postfix users can when they need to do so adjust the underlying the cipherlist specs, but they almost never need to do that, and asking them to do so when they simply want a knob to tune the minimum strength (or choose an appropriate profile) would be a disservice. Your previous posts were written as if they advocated no such configurability, which is what I was opposing. OpenSSL cipherlists are not for novices. The OpenSSL cipherlist language is highly unstable and not very usable in practice. Typically the admin will have to experiment with the openssl cipher command of the exact library patch level involved in order to determine what strings will have what effect. Which is why I described a better user interface and how to implement it using OpenSSL cipher list APIs internally. My proposed interface would contain the big knob (which maps to whatever the OpenSSL cipher list logic maps HIGH, MEDIUM, LOW etc. to on any given day) and a meaningful fine tuning user interface. Just like on some old radio receivers where there were buttons for the favorite programs which would cause the big tuning scale to jump to the chosen location while still letting people fiddle the dial to fine tune reception or tune to a rarely used station which happens to broadcast tonight's big event. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: FIPS Capable Ciphers List
On Wed, May 15, 2013 at 09:59:52AM -0600, Salz, Rich wrote: I was talking about a user interface to specify settings without requiring a rebuild of the applications. And on this, we completely agree :) +1 for no application rebuilds. Hard-coded cipherlists is not what I had mind, if that was unclear, apologies. The suggestion was to offer a sensible menu of reasonable choices, with an expert interface to refine those choices. That expert interface could be via a set of orthogonal controls to guide the non-quite expert to towards reasonable combinations. My objection was to an interface that only takes raw cipherlists from users. That's unwise. Help them build cipherlists that make sense. Ultimately the underlying language needs to be exposed for emergencies, since any radio button controls can only express features known at the time the application was developed, and the OpenSSL library grows new cipher properties from time to time. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: FIPS Capable Ciphers List
On Wed, May 15, 2013 at 12:58:37AM +, Santhosh Kokala wrote: I have a use case where an admin can configure the Ciphers from UI. I have this code in the backend that tries to set the cipher meth = TLSv1_client_method(); ctx = SSL_CTX_new(meth); sslretval = SSL_CTX_set_cipher_list(ctx, ts_str(cipher)); When a user sets a cipher such as MD5 when the device is in FIPS mode the above call returns an error code. I am thinking to validate the input cipher against the list of FIPS supported ciphers before calling SSL_CTX_set_cipher_list(). Is there a function where I can get a list of FIPS supported ciphers? The OpenSSL cipherlist strings is a rather subtle language, I would not expose it directly to users. Instead define a menu of cipher grades, and have the administrator choose from that. The menu of cipher grades should: - Be monotone. Each grade restricts the cipher list to increasingly more secure options. The sets of underlying ciphers corresponding to each grade should form a total order under set inclusion. - Be pre-validated. Don't give users choices that make them feel stupid when their choice is rejected as invalid. - Be something the user can understand. For example, Postfix provides the grades export, low, medium and high. Unlike the OpenSSL EXPORT, LOW, MEDIUM and HIGH the Postfix grades are inclusive of all stronger ciphers: export = EXPORT + LOW + MEDIUM + HIGH low = LOW + MEDIUM + HIGH medium = MEDIUM + HIGH high= HIGH the actual definitions are more complex and are approximately: export = ALL:@STRENGTH low = ALL:!EXPORT:@STRENGTH medium = ALL:!EXPORT:!LOW:@STRENGTH high = ALL:!EXPORT:!LOW:!MEDIUM:@STRENGTH this avoids including eNULL and other ciphers normally omitted from ALL. You may want DEFAULT rather than ALL, if anonymous ciphers are not appropriate in your application. If the underlying choices need to be configurable, that should generally not be via the UI, rather via a configuration file of some sort. This assumes your users are normal users, not SSL protocol testers who want fine-grained control and understand OpenSSL ciphers in detail. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: FIPS Capable Ciphers List
Viktor gave some excellent advice. I'd tweak it by removing 'export' as something to support. And perhaps use weak, good, strong -- whatever, keep the number of choices very small. I'd suggest to not use default since folks will get upset if it changes. They are more accepting if the definition of 'strong cipher' changes with time. It's curious, but it's the way humans seem to work. The openssl cipher spec is pretty darn subtle and it is far too easy to get wrong. /r$ -- Principal Security Engineer Akamai Technology Cambridge, MA __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: FIPS Capable Ciphers List
On Tue, May 14, 2013 at 09:42:08PM -0500, Salz, Rich wrote: Viktor gave some excellent advice. I'd tweak it by removing 'export' as something to support. And perhaps use weak, good, strong -- whatever, keep the number of choices very small. I'd suggest to not use default since folks will get upset if it changes. They are more accepting if the definition of 'strong cipher' changes with time. It's curious, but it's the way humans seem to work. The reason Postfix supports export is because it supports an opportunistic TLS mode, where we fall back to plain-text if the remote server does not offer TLS, or the handshake fails. So the export grade is default for opportunistic connections, since even export is somewhat better than plain-text. With mandatory TLS destinations the default cipher grade is medium. The actual design has to match the constraints and requirements of the particular application as well as usability considerations. The openssl cipher spec is pretty darn subtle and it is far too easy to get wrong. Excellent one sentence summary. -- VIktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: FIPS Capable Ciphers List
So the Postfix team finds SMTP servers that support EXPORT and nothing stronger? Wow, I am very surprised. For those who don't know, export strength crypto was a creation of the US government in the early 1990's, and the rules were removed in 2000. It's been more than a dozen years, it's time to stop supporting it. /r$ -- Principal Security Engineer Akamai Technology Cambridge, MA -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Viktor Dukhovni Sent: Tuesday, May 14, 2013 10:51 PM To: openssl-users@openssl.org Subject: Re: FIPS Capable Ciphers List On Tue, May 14, 2013 at 09:42:08PM -0500, Salz, Rich wrote: Viktor gave some excellent advice. I'd tweak it by removing 'export' as something to support. And perhaps use weak, good, strong -- whatever, keep the number of choices very small. I'd suggest to not use default since folks will get upset if it changes. They are more accepting if the definition of 'strong cipher' changes with time. It's curious, but it's the way humans seem to work. The reason Postfix supports export is because it supports an opportunistic TLS mode, where we fall back to plain-text if the remote server does not offer TLS, or the handshake fails. So the export grade is default for opportunistic connections, since even export is somewhat better than plain-text. With mandatory TLS destinations the default cipher grade is medium. The actual design has to match the constraints and requirements of the particular application as well as usability considerations. The openssl cipher spec is pretty darn subtle and it is far too easy to get wrong. Excellent one sentence summary. -- VIktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
