Re: SSL option fail_if_no_peer_cert has the wrong default value

Hi!

On 03/06/2015 04:23 PM, Vincent de Phily wrote:
> Hi,
>
> I just noticed that fail_if_no_peer_cert defaults to false. This is dangerous,
> as it means that just setting {verify,verify_peer} leaves you open to
> unauthentified connections.
>
> The current default unexpected and undocumented. It is a security hole waiting
> to happen (indeed, it has been present in my software for years).

 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)."


> Thinking about it further, {fail_if_no_peer_cert,false} can only serve some
> very niche unusual usecases ? The docs say that it only has an impact if
> verify_peer is set. It could be that you want to accept (and treat
> differently) both authenticated and non-authenticated connections, but most
> users will either not need authentication (and set verify_none) or will want
> to authenticate every connection.

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!


> The absence of a peer cert seems like a poor heuristic for deciding to accept
> unauthentificated connection. What if the peer has a cert you don't know about
> ? A better interface would be one that always lets the connection succeed, but
> includes authentication status in its success return.
>
> I'd argue that even explicitly setting {fail_if_no_peer_cert,false} is likely
> to lead to surprises and that people should instead put the logic in
> verify_fun or in post-handshake checks, but that's probably out of scope for a
> bug report.

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.

Regards Ingela

_______________________________________________
erlang-bugs mailing list
[email protected]
http://erlang.org/mailman/listinfo/erlang-bugs