SSL hostname verification

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

SSL hostname verification

San Gillis
Since upgrading to Erlang 20.2 (from 19.3) we've been having issues with using SSL for Erlang distribution.

We used to run our nodes with
```
-ssl_dist_opt server_verify verify_peer
-ssl_dist_opt client_verify verify_peer
```
in the vm.args file. Since the upgrade this failed with {bad_cert, hostname_check_failed}.

I noticed that this hostname check fails because `fun public_key:verify_hostname_match_default/2` is receiving `{dns_id, "[hidden email]"}` and `{dNSName,"*.hostname.com"}` as arguments, which will fail to check.

I have looked into providing `verify_fun` to do custom verification, but this seems pretty convoluted if I just want to `erl -remsh [hidden email] -ssl_dist_optfile ...` into the given node.

Did anyone else run into this issue? Are there some better ways to fix this?

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: SSL hostname verification

Dmitry Kolesnikov-2
Hello,

I had a similar problem with plain TLS socket after 19.x to 20.x migration. This is due to SNI feature. I’ve disabled it using following ssl socket option: {server_name_indication, disable}

I think same applies for dist sockets as well. 

Best Regards, 
Dmitry

On 22 Jan 2018, at 17.28, San Gillis <[hidden email]> wrote:

Since upgrading to Erlang 20.2 (from 19.3) we've been having issues with using SSL for Erlang distribution.

We used to run our nodes with
```
-ssl_dist_opt server_verify verify_peer
-ssl_dist_opt client_verify verify_peer
```
in the vm.args file. Since the upgrade this failed with {bad_cert, hostname_check_failed}.

I noticed that this hostname check fails because `fun public_key:verify_hostname_match_default/2` is receiving `{dns_id, "[hidden email]"}` and `{dNSName,"*.hostname.com"}` as arguments, which will fail to check.

I have looked into providing `verify_fun` to do custom verification, but this seems pretty convoluted if I just want to `erl -remsh [hidden email] -ssl_dist_optfile ...` into the given node.

Did anyone else run into this issue? Are there some better ways to fix this?
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: SSL hostname verification

San Gillis
I tried adding {server_name_indication, disable} to my ssl_dist_optfile. (So it is `[{server, ...}, {client, [..., {server_name_indication, disable}]}]`, is that correct?). This doesn't change the error I get.

Also, if I understand the documentation correctly, this disables all hostname checking. Would this leave us vulnerable to MITM attacks?

2018-01-22 16:34 GMT+01:00 Dmitry Kolesnikov <[hidden email]>:
Hello,

I had a similar problem with plain TLS socket after 19.x to 20.x migration. This is due to SNI feature. I’ve disabled it using following ssl socket option: {server_name_indication, disable}

I think same applies for dist sockets as well. 

Best Regards, 
Dmitry

On 22 Jan 2018, at 17.28, San Gillis <[hidden email]> wrote:

Since upgrading to Erlang 20.2 (from 19.3) we've been having issues with using SSL for Erlang distribution.

We used to run our nodes with
```
-ssl_dist_opt server_verify verify_peer
-ssl_dist_opt client_verify verify_peer
```
in the vm.args file. Since the upgrade this failed with {bad_cert, hostname_check_failed}.

I noticed that this hostname check fails because `fun public_key:verify_hostname_match_default/2` is receiving `{dns_id, "[hidden email]"}` and `{dNSName,"*.hostname.com"}` as arguments, which will fail to check.

I have looked into providing `verify_fun` to do custom verification, but this seems pretty convoluted if I just want to `erl -remsh [hidden email] -ssl_dist_optfile ...` into the given node.

Did anyone else run into this issue? Are there some better ways to fix this?
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: SSL hostname verification

Ingela Andin

Hi!

2018-01-22 16:55 GMT+01:00 San Gillis <[hidden email]>:
I tried adding {server_name_indication, disable} to my ssl_dist_optfile. (So it is `[{server, ...}, {client, [..., {server_name_indication, disable}]}]`, is that correct?). This doesn't change the error I get.


Looks right  .... it is a pretty new feature so we will look into if it is tested well enough or if you just missed some little detail!
 
Also, if I understand the documentation correctly, this disables all hostname checking. Would this leave us vulnerable to MITM attacks?


Yes it disables all hostname checks making you vulnerable to the things they where designed to protect. The way to customize the checks is to handle them in your own verify_fun, why do you think that is convulted?
The verify_fun can be very simple only specifically handling the  {bad_cert, hostname_check_failed} then all other checks will behave as before. The verify_fun is not meant to  replace the default certiface checks it 
is for extending the checks and possible ignoring some specific error (even though this is seldom desirable). 

Something like:

{fun(_,{bad_cert, hostname_check_failed}, _) ->
	 %%% Preform own check ...
    (_,{extension, _}, UserState) ->
	 {unknown, UserState};
    (_, valid, UserState) ->
	 {valid, UserState};
    (_, valid_peer, UserState) ->
         {valid, UserState}
 end, []}

Initial UserStae is []

Regards Ingela Erlang/OTP team - Ericsson AB


2018-01-22 16:34 GMT+01:00 Dmitry Kolesnikov <[hidden email]>:
Hello,

I had a similar problem with plain TLS socket after 19.x to 20.x migration. This is due to SNI feature. I’ve disabled it using following ssl socket option: {server_name_indication, disable}

I think same applies for dist sockets as well. 

Best Regards, 
Dmitry

On 22 Jan 2018, at 17.28, San Gillis <[hidden email]> wrote:

Since upgrading to Erlang 20.2 (from 19.3) we've been having issues with using SSL for Erlang distribution.

We used to run our nodes with
```
-ssl_dist_opt server_verify verify_peer
-ssl_dist_opt client_verify verify_peer
```
in the vm.args file. Since the upgrade this failed with {bad_cert, hostname_check_failed}.

I noticed that this hostname check fails because `fun public_key:verify_hostname_match_default/2` is receiving `{dns_id, "[hidden email]"}` and `{dNSName,"*.hostname.com"}` as arguments, which will fail to check.

I have looked into providing `verify_fun` to do custom verification, but this seems pretty convoluted if I just want to `erl -remsh [hidden email] -ssl_dist_optfile ...` into the given node.

Did anyone else run into this issue? Are there some better ways to fix this?
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: SSL hostname verification

Ingela Andin
Hoops did not mean du remove the default fail on cert error clause ....

{fun(_,{bad_cert, hostname_check_failed}, _) ->
	 %%% Preform own check ...
    (_,{bad_cert, _} = Reason, _) ->
	 {fail, Reason};   
    (_,{extension, _}, UserState) ->
	 {unknown, UserState};
    (_, valid, UserState) ->
	 {valid, UserState};
    (_, valid_peer, UserState) ->
         {valid, UserState}
 end, []}

Regards Ingela 

2018-01-22 21:29 GMT+01:00 Ingela Andin <[hidden email]>:

Hi!

2018-01-22 16:55 GMT+01:00 San Gillis <[hidden email]>:
I tried adding {server_name_indication, disable} to my ssl_dist_optfile. (So it is `[{server, ...}, {client, [..., {server_name_indication, disable}]}]`, is that correct?). This doesn't change the error I get.


Looks right  .... it is a pretty new feature so we will look into if it is tested well enough or if you just missed some little detail!
 
Also, if I understand the documentation correctly, this disables all hostname checking. Would this leave us vulnerable to MITM attacks?


Yes it disables all hostname checks making you vulnerable to the things they where designed to protect. The way to customize the checks is to handle them in your own verify_fun, why do you think that is convulted?
The verify_fun can be very simple only specifically handling the  {bad_cert, hostname_check_failed} then all other checks will behave as before. The verify_fun is not meant to  replace the default certiface checks it 
is for extending the checks and possible ignoring some specific error (even though this is seldom desirable). 

Something like:

{fun(_,{bad_cert, hostname_check_failed}, _) ->
	 %%% Preform own check ...
    (_,{extension, _}, UserState) ->
	 {unknown, UserState};
    (_, valid, UserState) ->
	 {valid, UserState};
    (_, valid_peer, UserState) ->
         {valid, UserState}
 end, []}

Initial UserStae is []

Regards Ingela Erlang/OTP team - Ericsson AB


2018-01-22 16:34 GMT+01:00 Dmitry Kolesnikov <[hidden email]>:
Hello,

I had a similar problem with plain TLS socket after 19.x to 20.x migration. This is due to SNI feature. I’ve disabled it using following ssl socket option: {server_name_indication, disable}

I think same applies for dist sockets as well. 

Best Regards, 
Dmitry

On 22 Jan 2018, at 17.28, San Gillis <[hidden email]> wrote:

Since upgrading to Erlang 20.2 (from 19.3) we've been having issues with using SSL for Erlang distribution.

We used to run our nodes with
```
-ssl_dist_opt server_verify verify_peer
-ssl_dist_opt client_verify verify_peer
```
in the vm.args file. Since the upgrade this failed with {bad_cert, hostname_check_failed}.

I noticed that this hostname check fails because `fun public_key:verify_hostname_match_default/2` is receiving `{dns_id, "[hidden email]"}` and `{dNSName,"*.hostname.com"}` as arguments, which will fail to check.

I have looked into providing `verify_fun` to do custom verification, but this seems pretty convoluted if I just want to `erl -remsh [hidden email] -ssl_dist_optfile ...` into the given node.

Did anyone else run into this issue? Are there some better ways to fix this?
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions




_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: SSL hostname verification

San Gillis
In reply to this post by Ingela Andin
Hi!

First of all, thank you Dmitry and Ingela for the quick replies.

Yes it disables all hostname checks making you vulnerable to the things they where designed to protect.

Thought so, so I would prefer not to use the disable option.
 
The way to customize the checks is to handle them in your own verify_fun, why do you think that is convulted?

It just seemed weird to me to write erlang functions inside a configuration file. But then again, I didn't understand it could be just a short function, which makes it a lot more acceptable.
 
The verify_fun can be very simple only specifically handling the  {bad_cert, hostname_check_failed} then all other checks will behave as before. The verify_fun is not meant to  replace the default certiface checks it 
is for extending the checks and possible ignoring some specific error (even though this is seldom desirable). 

Something like:

{fun(_,{bad_cert, hostname_check_failed}, _) ->
	 %%% Preform own check ...
    (_,{extension, _}, UserState) ->
	 {unknown, UserState};
    (_, valid, UserState) ->
	 {valid, UserState};
    (_, valid_peer, UserState) ->
         {valid, UserState}
 end, []}

I tried this, but the weird thing is that when I explicitly set verify_fun to what is described as the default in the documentation:

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

I do not get the hostname_check_failed error anymore. I did not expect this.

I believe `ssl_certificate:verify_hostname` is called when I do not explicitly provide verify_fun, because I added some debug statements that got executed.
When I do provide the verify_fun as above the debug statements no longer get executed. But I couldn't find any other occurrences of hostname_check_failed in my copy of the `lib` dir of erlang 20.2. 


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: SSL hostname verification

Ingela Andin
Hi!

Well I forgot you are using distribution over TLS and when specifying the fun via the configuration file you must use fun <Module>/3  format for funs.
So you need to have a module implementing the function that you want to use as a fun.
 
So 

-module(my_verify)

-export([verify/3]).

verify(Cert,{bad_cert, hostname_check_failed} = Reason, UserState) ->
  case my_hostname_check(Cert, UserState) of


{fail, Reason};
verify(_,{bad_cert, _} = Reason, _) ->
{fail, Reason};
verify(_,{extension, _}, UserState) ->
{unknown, UserState};
verify(_, valid, UserState) ->
{valid, UserState};
verify(_, valid_peer, UserState) ->
         {valid, UserState}.

2018-01-23 12:13 GMT+01:00 San Gillis <[hidden email]>:
Hi!

First of all, thank you Dmitry and Ingela for the quick replies.

Yes it disables all hostname checks making you vulnerable to the things they where designed to protect.

Thought so, so I would prefer not to use the disable option.
 
The way to customize the checks is to handle them in your own verify_fun, why do you think that is convulted?

It just seemed weird to me to write erlang functions inside a configuration file. But then again, I didn't understand it could be just a short function, which makes it a lot more acceptable.
 
The verify_fun can be very simple only specifically handling the  {bad_cert, hostname_check_failed} then all other checks will behave as before. The verify_fun is not meant to  replace the default certiface checks it 
is for extending the checks and possible ignoring some specific error (even though this is seldom desirable). 

Something like:

{fun(_,{bad_cert, hostname_check_failed}, _) ->
	 %%% Preform own check ...
    (_,{extension, _}, UserState) ->
	 {unknown, UserState};
    (_, valid, UserState) ->
	 {valid, UserState};
    (_, valid_peer, UserState) ->
         {valid, UserState}
 end, []}

I tried this, but the weird thing is that when I explicitly set verify_fun to what is described as the default in the documentation:

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

I do not get the hostname_check_failed error anymore. I did not expect this.

I believe `ssl_certificate:verify_hostname` is called when I do not explicitly provide verify_fun, because I added some debug statements that got executed.
When I do provide the verify_fun as above the debug statements no longer get executed. But I couldn't find any other occurrences of hostname_check_failed in my copy of the `lib` dir of erlang 20.2. 



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: SSL hostname verification

Ingela Andin
Hi!

Just ignore my previous mail. Note to self never edit code in browser-mail-window! ;)

Well I forgot you are using distribution over TLS and when specifying the fun via the configuration file you must use fun <Module>:<Function>/3  format for funs.
So you need to have a module implementing the function that you want to use as a fun.

Somethin like:

-module(my_verify)

-export([verify/3]).

verify(Cert,{bad_cert, hostname_check_failed} = Reason, UserState) ->
  case my_hostname_check(Cert, UserState) of
             true ->
                  {valid, UserState};
            false ->
                 {fail, Reason}
             end;

verify(_,{bad_cert, _}, UserState) ->
       {fail, Reason};
verify(_,{bad_cert, _} = Reason, _) ->
{fail, Reason};
verify(_,{extension, _}, UserState) ->
{unknown, UserState};
verify(_, valid, UserState) ->
{valid, UserState};
verify(_, valid_peer, UserState) ->
         {valid, UserState}.


And option  like: {verify_fun, fun my_verify:verify/3, <UserState>}

This is a limitation for  distribution over TLS as unamed funs can not be handled in files.

Regards Ingela Erlang/OTP -team



2018-01-23 15:59 GMT+01:00 Ingela Andin <[hidden email]>:
Hi!

Well I forgot you are using distribution over TLS and when specifying the fun via the configuration file you must use fun <Module>/3  format for funs.
So you need to have a module implementing the function that you want to use as a fun.
 
So 

-module(my_verify)

-export([verify/3]).

verify(Cert,{bad_cert, hostname_check_failed} = Reason, UserState) ->
  case my_hostname_check(Cert, UserState) of


{fail, Reason};
verify(_,{bad_cert, _} = Reason, _) ->
{fail, Reason};
verify(_,{extension, _}, UserState) ->
{unknown, UserState};
verify(_, valid, UserState) ->
{valid, UserState};
verify(_, valid_peer, UserState) ->
         {valid, UserState}.

2018-01-23 12:13 GMT+01:00 San Gillis <[hidden email]>:
Hi!

First of all, thank you Dmitry and Ingela for the quick replies.

Yes it disables all hostname checks making you vulnerable to the things they where designed to protect.

Thought so, so I would prefer not to use the disable option.
 
The way to customize the checks is to handle them in your own verify_fun, why do you think that is convulted?

It just seemed weird to me to write erlang functions inside a configuration file. But then again, I didn't understand it could be just a short function, which makes it a lot more acceptable.
 
The verify_fun can be very simple only specifically handling the  {bad_cert, hostname_check_failed} then all other checks will behave as before. The verify_fun is not meant to  replace the default certiface checks it 
is for extending the checks and possible ignoring some specific error (even though this is seldom desirable). 

Something like:

{fun(_,{bad_cert, hostname_check_failed}, _) ->
	 %%% Preform own check ...
    (_,{extension, _}, UserState) ->
	 {unknown, UserState};
    (_, valid, UserState) ->
	 {valid, UserState};
    (_, valid_peer, UserState) ->
         {valid, UserState}
 end, []}

I tried this, but the weird thing is that when I explicitly set verify_fun to what is described as the default in the documentation:

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

I do not get the hostname_check_failed error anymore. I did not expect this.

I believe `ssl_certificate:verify_hostname` is called when I do not explicitly provide verify_fun, because I added some debug statements that got executed.
When I do provide the verify_fun as above the debug statements no longer get executed. But I couldn't find any other occurrences of hostname_check_failed in my copy of the `lib` dir of erlang 20.2. 




_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: SSL hostname verification

San Gillis

So you need to have a module implementing the function that you want to use as a fun.

I tried this, and I start my remote shell using
`erl -remsh nodename@remotehost -pa ./ebin -setcookie cookie -name node@host -ssl_dist_optfile ./sslopts.conf -proto_dist inet_tls`
where ./ebin contains the module beam.

In this case the shell process just terminates without giving me any error messages.
 

This is a limitation for  distribution over TLS as unamed funs can not be handled in files.

When I put some `io:format` statements in my unnamed function they did get printed to console, so it seems this does work?

Regards,
San


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: SSL hostname verification

Raimo Niskanen-2
On Tue, Jan 23, 2018 at 06:04:53PM +0100, San Gillis wrote:

> > So you need to have a module implementing the function that you want to
> > use as a fun.
> >
>
> I tried this, and I start my remote shell using
> `erl -remsh nodename@remotehost -pa ./ebin -setcookie cookie -name node@host
> -ssl_dist_optfile ./sslopts.conf -proto_dist inet_tls`
> where ./ebin contains the module beam.
>
> In this case the shell process just terminates without giving me any error
> messages.
>
>
> This is a limitation for  distribution over TLS as unamed funs can not be
> > handled in files.
> >
>
> When I put some `io:format` statements in my unnamed function they did get
> printed to console, so it seems this does work?
>
> Regards,
> San

Well, I'll be darned, but that acually seems to work!

The file parsing results in an erl_eval internal fun with the parsed
abstract form in its environment, so when that fun is called it is
interpreted by erl_eval.  Interpretation is _much_ slower then execution,
but I do not know when that would be a real problem...

Here is an example that works, I ripped out pieces from after running
the test suite ssl_dist_bench_SUITE:setup/1:

To start one node:
    erl -run application start crypto -run application start public_key
        -eval 'net_kernel:verbose(1)'
        -sname ssl_dist_bench_SUITE_node_a
        -proto_dist inet_tls
        -ssl_dist_optfile ~/tmp/[hidden email]

To start the other node:
    erl -run application start crypto -run application start public_key
        -eval 'net_kernel:verbose(1)'
        -sname ssl_dist_bench_SUITE_node_b
        -proto_dist inet_tls
        -ssl_dist_optfile ~/tmp/[hidden email]

My host's short name is elxd1243rl3.
The "-eval 'net_kernel:verbose(1)' increases verbosity for testing.
The applications 'crypto' and 'public_key' has to be started, either from
the command line like this, or from a dedicated boot script.  See:

    http://erlang.org/doc/apps/ssl/ssl_distribution.html Section 4.1


The test framework generates the .conf files containing certificates for
the short node names so these nodes actually pass hostname verification.
In these .conf files I have added an inline verify_fun in the client
section.

Excerpt from ~/tmp/[hidden email]:

[{server,
  [{fail_if_no_peer_cert,true},
   {verify,verify_peer},
   {versions,['tlsv1.2']},
   {ciphers,[{ecdhe_ecdsa,aes_128_cbc,sha256,sha256}]},
   {cert,<<48,130,2,237,48,130,2,72,160,3,2,1,2,2,1,4,48,16,6,7,42,134,
           ...,235,67,74,159,21,16,15>>},
   {key,{'ECPrivateKey',<<48,129,220,2,1,1,4,66,1,177,250,81,233,146,
                          ...,60,213,172>>}},
   {cacerts,[<<48,130,2,213,48,130,2,48,160,3,2,1,2,2,1,2,48,16,6,7,42,
               ...,141,240,231,115,166,243>>,
             <<48,130,2,213,48,130,2,48,160,3,2,1,2,2,1,2,48,16,6,7,
               ...,237,32,9,141,240,231,115,166,243>>]}]},

 {client,
  [{verify,verify_peer},
   {verify_fun,
    {fun (_, Event, UserState) ->
         io:format("~p.~n", [Event]),
         case Event of
             {bad_cert, hostname_check_failed} ->
                  %%% Preform own check ...
                 {valid, UserState};
             {extension, _} ->
                 {unknown, UserState};
             valid ->
                 {valid, UserState};
             valid_peer ->
                 {valid, UserState}
         end
     end, []}},
   {versions,['tlsv1.2']},
   {ciphers,[{ecdhe_ecdsa,aes_128_cbc,sha256,sha256}]},
   {cert,<<48,130,2,237,48,130,2,72,160,3,2,1,2,2,1,4,48,16,6,7,42,134,
           ...,235,67,74,159,21,16,15>>},
   {key,{'ECPrivateKey',<<48,129,220,2,1,1,4,66,1,177,250,81,233,146,
                          ...,60,213,172>>}},
   {cacerts,[<<48,130,2,213,48,130,2,48,160,3,2,1,2,2,1,2,48,16,6,7,42,
               ...,141,240,231,115,166,243>>,
             <<48,130,2,213,48,130,2,48,160,3,2,1,2,2,1,2,48,16,6,
               ...,206,74,237,32,9,141,240,231,115,166,243>>]}
  ]
 }].


This is node a that gets connected to, I am sorry I connected from node b
to node a, that is not according to telco tradition :-(

erl -run application start crypto -run application start public_key
    -eval 'net_kernel:verbose(1)' -sname ssl_dist_bench_SUITE_node_a
    -proto_dist inet_tls
    -ssl_dist_optfile ~/tmp/[hidden email]
Erlang/OTP 21 [DEVELOPMENT] [erts-9.2] [source-8e66754] [64-bit] [smp:8:8]
    [ds:8:8:10] [async-threads:10] [hipe]

Eshell V9.2  (abort with ^G)
(ssl_dist_bench_SUITE_node_a@elxd1243rl3)1>

=ERROR REPORT==== 25-Jan-2018::09:53:37 ===
Net kernel got ping


And this is node b that connects:

erl -run application start crypto -run application start public_key
    -eval 'net_kernel:verbose(1)' -sname ssl_dist_bench_SUITE_node_b
    -proto_dist inet_tls
    -ssl_dist_optfile ~/tmp/[hidden email]
Erlang/OTP 21 [DEVELOPMENT] [erts-9.2] [source-8e66754] [64-bit] [smp:8:8]
    [ds:8:8:10] [async-threads:10] [hipe]

Eshell V9.2  (abort with ^G)
(ssl_dist_bench_SUITE_node_b@elxd1243rl3)1>
    {net_kernel,ssl_dist_bench_SUITE_node_a@elxd1243rl3} ! ping.
ping

=INFO REPORT==== 25-Jan-2018::09:53:37 ===
{net_kernel,{auto_connect,ssl_dist_bench_SUITE_node_a@elxd1243rl3,1,
                          #Ref<0.1220262086.1603141640.225564>}}
{extension,
 {'Extension',{2,5,29,17},false,
  [{dNSName,"ssl_dist_bench_SUITE_node_a@elxd1243rl3"}]}}.

valid_peer.

(ssl_dist_bench_SUITE_node_b@elxd1243rl3)2>


So we got two printouts from the verify_fun on node b, one for the
subject altnames extension, and one from the succesful validation.

I hope this information was useful.
--

/ Raimo Niskanen, Erlang/OTP, Ericsson AB
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions