On Thu, Oct 29, 2009 at 11:33:13AM +0300, Victor B. Wagner wrote:
> > Yes, of course, in a strictly technical sense. From a user perspective,
> > however, both are the same sort of thing, something one needs to configure
> > to enable kEDH or kEECDH ciphers. When neither set of parameters is
> > provided, one gets just
>
> We are talking about server. User, who configures server is technican.
Yes, they usually understand something about Apache, or IMAP, ... but
understanding OpenSSL cipher-suite specs is almost invariably outside
their expertise. This is direct personal experience with decently
skilled staff.
> > - kRSA, kECDHr, kECDHe (no forward secrecy)
> > - kPSK (no significant adoption)
>
> There is also GOST. And it is what I'm concerned with.
>
> > > Question is - should we make user immediately aware of this restriction
> > > during parsing the configuration?
> >
> > Not sure what you mean by "during parsing".
>
> It means "before server starts and begins to listen on the socket".
>
> > > If user specifies DSA key only it is fatal.
> > > If user specifies RSA key only half of otherwise available suites
> > > are left.
> >
> > It is OK if the user cipher selection string designates more ciphers
> > (e.g. DEFAULT) than actually compatible with the available with the
> > available certificates and/or parameters, so long as a non-empty
> > set of usable cipher-suites remains.
>
> But above you are talking about lost forward secrecy.
Yes, but this is standard operating procedure for SSL. If the product
supports DH parameters, and the users want forward secrecy (sometimes,
they don't) they'll in some cases turn it on, and in some cases they'll
forget, but it would be worse to insist that the cipherlist not match
any ciphers that are not supported by the other parameters.
> It depends on application, I think. For some applications it is good
> reason, for some - it is bad.
Yes, of course, but on the whole, the design rationale is sensible.
> > If you want a "lint" tool for configurations, by all means, that would
> > be a good idea. But, making cipherlists incompatible with libraries
> > that don't support every cipher on the list, is bad, one can't use
> > a single list whose elements include features from "future" releases
>
> Why one would use such a setup for production system?
Because the configuration is rarely changed, and cipherlists are copied
cargo-cult style from release to release. I am not there at the deployment
of every SSL server, I just recommend a decently future-proof cipherlist,
and it tends to get enshrined as the "golden" cipherlist for a few years,
until someone asks me again. :-(
--
Viktor.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
