On Po, 2014-03-31 at 16:24 +0200, Nikos Mavrogiannopoulos wrote:
> On Mon, 2014-03-31 at 13:55 +0000, Viktor Dukhovni wrote:
>
> > > > This too feels like intrusive overreach. What problem are you
> > > > trying to solve?
> > > The goal is to allow the configuration of the security level of
> > > applications centrally in a system. That is, to not require the
> > > administrator to configure each and every service to obtain a sane
> > > security level, to simplify the current best practices [0].
> > This assumes that there is such a thing as a uniformly applicable
> > security policy that applies equally to opportunistic use TLS,
> > mandatory use of unauthenticated TLS, authenticated TLS with modest
> > security requirements, and transport of highly sensitive data.
>
> I disagree. The problem in current systems, isn't that there are
> different policies required per application, but the fact that in
> practice there is no policy set for any application. Nevertheless, with
> the approach I describe, the current situation can be kept when needed
> by just not using the "system" keyword.
Exactly. There might be special applications - postfix with
opportunistic encryption is such one - where different than "system"
policy is appropriate. But in case of almost all applications the
current situation means that there is no way to set the policy at all.
For example most of the https clients do not allow to set the cipher
preference string so they stick with DEFAULT. Which might be ok for
general purpose system but if you have a special purpose one such as
system set up to use FIPS approved ciphers only this is not right. And
even if there was a way to set the cipher preference string for these
https clients it would be extremely hard and error prone to set the list
for each of them individually.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll never know whether the road is wrong though.)
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
