[erlang-questions] dh_anon SSL connection failed

[Ingela Andin]

Hi!

Well I have not had time until today. The problem is that the
keyexchange for anonymous
suites was expected by our code to be

?SERVER_KEY_EXCHANGE, <<?UINT16(PLen), P:PLen/binary,
			      ?UINT16(GLen), G:GLen/binary,
			      ?UINT16(YLen), Y:YLen/binary,
			       ?UINT16(0)>>

but atleas sometimes it will be

SERVER_KEY_EXCHANGE, <<?UINT16(PLen), P:PLen/binary,
			      ?UINT16(GLen), G:GLen/binary,
			      ?UINT16(YLen), Y:YLen/binary>>

I need to revisit the spec to figure out if we shall expect both or if
it should always be the latter.

Regards Ingela Erlang/OTP team - Ericsson AB

2012/2/16, Alexander Hudich <alttagil@REDACTED>:
> Hi, Ingela!
>
> You wrote:
>
>> Hum ... interesting it could be so that SSLv23_client_method() is more
> forgiving in some way and that your server has a bug... I will try to look
> into this more when I get time. If you come up with
>> something in the meantime pleas let me know.
>
> I wonder if you had any chance for further investigation of this problem?  I
> remember I sent you openssl connection dump and as I saw that  openssl
> always uses SSLv2/v3 method even if I pointed -no_ssl2 option explicitly.
> May be that's a way which have to be chosen to have ability to make
> connections with SSLv23_server_method() servers? I understand that SSL2
> unsecured and it won't be supported, but it's really important to be able to
> make SSLv3 and TLSv1 connections with SSLv23_server_method() servers.  Maybe
> there should be an option which version of SSL handshake hello should be
> sent?
>
> $openssl s_client -connect ip:5666 -state -debug  -no_ssl2 -cipher ADH
>
> SSL_connect:before/connect initialization
> SSL_connect:SSLv2/v3 write client hello A
> SSL_connect:SSLv3 read server hello A
> SSL_connect:SSLv3 read server key exchange A
> SSL_connect:SSLv3 read server done A
> SSL_connect:SSLv3 write client key exchange A
> SSL_connect:SSLv3 write change cipher spec A
> SSL_connect:SSLv3 write finished A
> SSL_connect:SSLv3 flush data
> SSL_connect:SSLv3 read server session ticket A
> SSL_connect:SSLv3 read finished A
>
>
>
>
> -----Original Message-----
> From: Ingela Andin [mailto:ingela.andin@REDACTED]
> Sent: Wednesday, January 18, 2012 12:39 PM
> To: alttagil@REDACTED; Erlang
> Subject: Re: [erlang-questions] dh_anon SSL connection failed
>
> Hi!
>
> 2012/1/16 Alexander Hudich <alttagil@REDACTED>:
>> Hi, Ingela!
>>
>>>> This is kind of excerpt from check_nrpe code which connects just fine:
>>>>
>>>>SSL_library_init();
>>>>SSLeay_add_ssl_algorithms();
>>>>meth=SSLv23_client_method();
>>>>SSL_load_error_strings();
>>>>ctx=SSL_CTX_new(meth));
>>>>SSL_CTX_set_options(ctx,SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3);
>>>>result=my_tcp_connect(server_name,server_port,&sd);
>>>>
>>>> /* do SSL handshake */
>>>>
>>>> if(result==STATE_OK && use_ssl==TRUE){
>>>>  if((ssl=SSL_new(ctx))!=NULL){
>>>>    SSL_CTX_set_cipher_list(ctx,"ADH");
>>>>    SSL_set_fd(ssl,sd);
>>>>    rc=SSL_connect(ssl));
>>>>  }
>>>>}
>>
>>> What cipher suite and SSL/TLS-protocol version will this code end up
>> using?
>>
>>
>> I have not very much experience in development with using SSL connections.
>> So I don't know if I've done it's right I added this line after
>> SSL_connect to get current information about established SSL
>> connection in check_nrpe:
>>
>> printf( "CIPHER %s %s\n", SSL_CIPHER_get_name(
>> SSL_get_current_cipher(ssl) ), SSL_CIPHER_get_version(
>> SSL_get_current_cipher(ssl) ) );
>>
>> And it gives:
>>
>> CIPHER ADH-AES256-SHA TLSv1/SSLv3
>>
>> Also I tried to change SSLv23_client_method() call to
> SSLv3_client_method().
>> And that gave very interesting result:
>>
>> CHECK_NRPE: Error - Could not complete SSL handshake.
>> SSL_connect=0
>> 36071:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert
>> handshake failure:s3_pkt.c:1102:SSL alert number 40
>>
>> That looks pretty similar to what I get with a result that erlang
>> ssl:connect  call returns.
>>
>
> Hum ... interesting it could be so that SSLv23_client_method() is more
> forgiving in some way and that your server has a bug... I will try to look
> into this more when I get time. If you come up with something in the
> meantime pleas let me know.
>
>>>> Erlang R16B (erts-5.10) [source] [64-bit] [smp:1:1]
>>>> [async-threads:0] [hipe] [kernel-poll:false]
>>>> 5> SockOpts.
>>>> [{active,false},
>>>> {ssl_imp,old},
>>
>>
>>>This is not a relevant option after R15B ( it will always be new even
>>>if
>> you write old).
>>
>> Yes I know that, it was just an act of despair :)
>>
>>
>>
>>>> {verify,verify_none},
>>>> {ciphers,[{dh_anon,rc4_128,md5},
>>>>            {dh_anon,des_cbc,sha},
>>>>            {dh_anon,'3des_ede_cbc',sha},
>>>>            {dh_anon,aes_128_cbc,sha},
>>>>            {dh_anon,aes_256_cbc,sha}]}]
>>>>
>>>> 6> ssl:connect( Ip, 5666, SockOpts, infinity).
>>>>
>>>> =ERROR REPORT==== 16-Jan-2012::12:49:23 ===
>>>> SSL: hello: ssl_handshake.erl:885:Fatal error: handshake failure
>>>> {error,esslconnect} What do you think is it possible to make this
>>>> type of connection in
>> Erlang?
>>>> What else can I try or is it a bug?
>>
>>> Our test cases for anonymous suites works just fine. Have you tried
>> running the test case anonymous_cipher_suites in  ssl_basic_SUITE?
>>
>> How can I do that?
>
> See description under testing in erlang patch instructions:
>
> https://github.com/erlang/otp/wiki/submitting-patches
>
>>
>>> Servers will normally not support anonymous cipher suites and we
>>> include
>> them only for test purposes and they may only be used if explicitly
>> supplied.
>>
>> I thought that I explicitly pointed to use that anonymous ciphers by
>> supplying them in connection options. Or there is something else I
>> should do?
>
> By supplying them in the connection options you will make the client try to
> connect to the server with those suites but it does not necessarily mean
> that the server supports them and will let you set up the connection.
> However your server seeems to support {dh_anon,aes_256_cbc,sha} (
> ADH-AES256-SHA ).
>
> Regards Ingela Erlang/OTP team - Ericsson AB
>
>