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 List                    openssl-users@openssl.org
Automated List Manager                           majord...@openssl.org

Reply via email to