Re: [VOTE] Improved TLS Defaults RFC
On Tue, Feb 11, 2014 at 4:16 PM, Stas Malyshev <[email protected]>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.
Thread (16 messages)