[erlang-patches] Allow server to use verify_peer and have no cacertfile

[Ingela Anderton Andin]

Hi!

After pondering how to solve this we have agreed that
our original design of the verify-modes and extension verification  
(that was
undocumented) was somewhat flawed.
And we have now implemented a new solution using a new
semantic for the verify_fun, that I actually think will work as Jonas
hoped his patch would.

The  verify_fun option will take a  {fun(), UserState :: term()} tuple.
The verify fun will be called when path validation errors  or
unknow certificate extensions are encountered.

A fun for accepting the unknown_ca error would for instance look like
this.

fun(_,{bad_cert, unknown_ca}, UserState) ->
         {valid, UserState};
        (_,{bad_cert, _} = Reason, _) ->
         {fail, Reason};
        (_,{extension, _}, UserState) ->
         {unknown, UserState}
     end,

Backwards compatibility code is in place, even if the old style 
verify_fun option
support will be discontinued.

Code will be in github in the beging of next week.

Regards Ingela Erlang/OTP team - Ericsson AB

Ingela Anderton Andin wrote:
> Hi!
>
> After discussing this with Jonas a bit I feel that the
> what we probably want to do is to make it possible for
> the server to send a certificate request in verify_none
> mode as then the verify fun can be used in the way that
> Jonas wants. It seems there is a bug in public_key that
> under certain circumstances would make the path_validation
> not return an error in verify_peer mode as intended.
>
> As I explained in an Erlang-questions thread:
>
> If verify_none all possible path validation errors will be passed
> to the the verify fun and it will be up to the verify fun if the
> connection should fail or succeed. At the moment this option is
> only relevant for the client side as the server will never send a
> certificate request in verify_none mode. ( It is possible that we
> want this to be possible and we are looking in to that now).
>
> If verify_peer any path validation error should make the
> connection fail we should never get to the branch using the
> verify fun, the public_key path validation should return {error,
> Reason}.
>
> So we are working on a solution I can not promise it will be
> ready for R14B but I think it can make a maintenance release
> i.e. I do not think you will have to wait for R15.
>
> Regards Ingela Erlang/OTP team - Ericsson AB
>
> jonas wrote:
>> Hey *,
>> I wanted to implement a server that can authenticate clients using the
>> FOAF+SSL protocol (http://esw.w3.org/Foaf+ssl). This protocol uses the
>> existing TLS infrastructure but does not use a cacert to authenticate
>> the user. Providing no cacert was just an option for a client, since
>> they can usually verify the certificate manually. If a server doesn't
>> provide a cacertfile you get an error. This patch removes this
>> restriction and allows a server to have no cacert, too.
>>
>> git fetch git://github.com/jonasp/otp.git foaf_ssl
>>
>> I didn't delete the testcase "Test server must have cacerts if it
>> wants to verify client" yet. I can do so if you think that the patch
>> is fine as it is.
>> As far as documentation is concerned I am not exactly sure what would
>> be reasonable to change since the FOAF+SSL usecase is still a bit too
>> exotic to be referred to. (It is still in the process of being
>> formally standardized.) And the Erlang man page for ssl just states
>> that the cacertfile option can be omitted if you do not want to verify
>> the peer but does not differentiate between client or server as it
>> actually should at the moment. So I don't think any change is needed
>> there.
>>
>> Best regards
>> Jonas Pollok
>>
>> ________________________________________________________________
>> erlang-patches (at) erlang.org mailing list.
>> See http://www.erlang.org/faq.html
>> To unsubscribe; mailto:erlang-patches-unsubscribe@REDACTED
>>
>>   
>
>
> ________________________________________________________________
> erlang-patches (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-patches-unsubscribe@REDACTED
>