Re: [VOTE] Improved TLS Defaults RFC

On Tue, Feb 11, 2014 at 4:16 PM, Stas Malyshev <smalyshev@sugarcrm.com>wrote: > > Wouldn't it also be good to have a constant that has the > meaning of "every protocol you can possibly support (including TLS > protocols)"? > > This is a good point. For this reason it probably makes to either: 1. NOT re-purpose the two STREAM_CRYPTO_METHOD_SSLv23_* constants to mean SSLv2 or SSLv3 (retain the OpenSSL semantics of SSLv23) 2. Introduce two new constants, STREAM_CRYPTO_CLIENT and STREAM_CRYPTO_SERVER to mean "anything we can possibly support" I have a mild preference for #2 as it eliminates confusion that can arise if you don't have a firm grasp of what OpenSSL means by SSLv23 but am certainly willing to listen to the preponderance of opinion from others here. > - What is the motivation for verify_depth default of 3? RFC does not say > anything on it. > > I admit this one is a somewhat arbitrary limit (which explains the lack of explanation in the wiki text). OpenSSL will default to a limit of 9 if we don't specify one ourselves, so there's not really that much to be gained by using a default of 3. After considering this a bit more I think it best to eliminate the addition of a default value in this area altogether. I will update the RFC and patch accordingly. > - What is the use case for honor_cipher_order? If the client is "bad", > they won't use honor_cipher_order and thus this option doesn't add to > security. If the client is "well-behaved", they would use the correct > set of cyphers. Is this setting meant for PHP servers? Because the > example clearly uses client side. > Woops! This is a copy/paste error in my example. The honor_cipher_order only ever has meaning for servers. I will update the example on the wiki to reflect to correct (server) usage shortly.