On 5/15/2013 3:27 AM, Viktor Dukhovni wrote:
On Wed, May 15, 2013 at 12:58:37AM +0000, 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 List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
