On 2009.10.28 at 14:56:54 -0400, Victor Duchovni wrote: > On Wed, Oct 28, 2009 at 09:09:59PM +0300, Victor B. Wagner wrote: > > > > > But for some setups, especially in OpenSSL 1.0, which supports EC > > > > ciphersuites, dh parameters are not neccessary. > > > > > > This is not entirely accurately, one still needs to designate an ECDH > > > curve for ECDHE ciphers. Postfix code for this: > > > > curve is not DH parameters. It is quite different dataset. > > (and often expressed as just OID, not actual curve data). > > 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. > - 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. > I strong disagree. Most users (I've talked to users trying to select > appropriate cipher lists) have no idea what the various ciphers are, > and are much better off with either DEFAULT or DEFAULT:!SSLv2:!EXPORT:!LOW > than anything they are likely to come up with on their own. If users use DEFAULT, it means that they haven't EXPLICITELY specified kEDH ciphersuites. They've specified "anyhing that appropriate". Unfortunately, it is quite hard to distinguish between these two situatuion with current libssl API. > In both of the "sensible" cipherlists above, there are a lot more ciphers > than typically compatible with the rest of the configuration. This is fine. > > > And obvoisly a fatal configuration error if some of these ciphersuites > > were explicitely specified by user in the cipher list. > > This would be bad. It is specifically documented that unknown cipherlist > elements are ignored, and for good reason. It depends on application, I think. For some applications it is good reason, for some - it is bad. > 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? ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
