[erlang-bugs] SSL option fail_if_no_peer_cert has the wrong default value

[Ingela Anderton Andin]

Hi!

On 03/10/2015 06:15 PM, Vincent de Phily wrote:
> Hi Ingela,
>
> On Tuesday 10 March 2015 14:44:26 Ingela Anderton Andin wrote:
>>   From the documentation:
>>
>> "{fail_if_no_peer_cert, boolean()}
>> Used together with {verify, verify_peer} by an ssl server. If set to
>> true, the server will fail if the client does not have a certificate to
>> send, i.e. sends a empty certificate, if set to false it will only fail
>> if the client sends an invalid certificate (an empty certificate is
>> considered valid)."
>
> Yes, but it doesn't say what the default is. Not documenting the default
> values is bad enough in general, but if that default is the wrong value for
> 99% of usecases, the documentation should warn loudly about it.

You have a point there.


>> The behavior of fail_if_no_peer_cert is the same as in openSSL, as once
>> up on a time the erlang ssl application was a wrapper for openSSL
>> (which is no longer the case) but we like our backwards compatibility!
>
> OpenSSL is notorious for its bad API design. I know that Erlang ssl used to be
> a wrapper around openssl, but that doesn't mean that it can't evolve towards
> something saner.

Sure, I am not disagreeing we have already made other such changes. Just 
saying we need good reasons to.


> In f_i_n_p_c's case, changing the default would probably close more bugs than
> it'd open. Importantly, the new bugs would cause a visible failure, rather
> than the invisible security hole caused by the current bugs. It'll be an
> annoyance for the minority of people who actually need f_i_n_p_c=false, but
> it's a clear win overall.
>
> I even think that f_i_n_p_c should be completely deprecated, since it's niche
> behavior can be obtained with a custom verify_fun. But it seems like I'd have
> a hard time convincing you about that :p

We will think about it. It is not entirely up to me, but my opinion will 
count.


> Speaking of liking backward compatibility, I'm still hoping for a reply by the
> OTP team to my last two emails (2015-02-19, 2015-02-20) about the 17.3
> partial_chain breakage ;)

I am not quite sure I agree that it is a breakage! We do not like to be 
bug compatible! It is on my todo list!


>> There will always be a trade off between security and interoperability,
>> and the application will always have to care about its configuration.
>> Personally I am not very fond of the  {fail_if_no_peer_cert, false} option.
>
> Glad we agree on that. If you do nothing else, please at least document
> f_i_n_p_c's default value.
>

If nothing else is done, I promise to do that.

Regards Ingela Erlang/OTP team - Ericsson AB