Matthias Radestock | 2 Aug 00:35 2012

missing function clause in ssl_connection:handle_alert

We got the following process crash report from a user running R15B01 
(trimmed somewhat to hide private key material):

=CRASH REPORT==== 31-Jul-2012::11:49:27 ===
   crasher:
     initial call: ssl_connection:init/1
     pid: <0.2005.0>
     registered_name: []
     exception exit: {function_clause,
                      [{ssl_connection,handle_alert,
                        [{alert,1,41,{"ssl_connection.erl",1678}},
                         certify,
                         {state,server,
                          {#Ref<0.0.0.3519>,<0.2004.0>},
                          gen_tcp,tcp,tcp_closed,tcp_error,"localhost",5673,
                          #Port<0.6927>,
                          {ssl_options,[],verify_peer,
                           {#Fun<ssl.3.54384637>,
                            #Fun<rabbit_networking.0.89858908>},
                           false,false,undefined,1,
                           "C:/certstore/server/cert.pem",undefined,

"C:/certstore/server/key.pem",undefined,undefined,
                           undefined,"C:/certstore/testca/cacert.pem",
                           undefined,undefined,
                           [<<0,57>>,
                            <<0,56>>,
                            <<0,53>>,
                            <<0,22>>,
                            <<0,19>>,
(Continue reading)

Loïc Hoguin | 2 Aug 00:39 2012
Picon

Re: missing function clause in ssl_connection:handle_alert

I also observed this but with the following difference:

[{ssl_connection,handle_alert,
     [{alert,211,61,{"ssl_connection.erl",1678}},

I can submit the whole crash log if needed.

On 08/02/2012 12:35 AM, Matthias Radestock wrote:
> We got the following process crash report from a user running R15B01
> (trimmed somewhat to hide private key material):
>
> =CRASH REPORT==== 31-Jul-2012::11:49:27 ===
>    crasher:
>      initial call: ssl_connection:init/1
>      pid: <0.2005.0>
>      registered_name: []
>      exception exit: {function_clause,
>                       [{ssl_connection,handle_alert,
>                         [{alert,1,41,{"ssl_connection.erl",1678}},
>                          certify,
>                          {state,server,
>                           {#Ref<0.0.0.3519>,<0.2004.0>},
>
> gen_tcp,tcp,tcp_closed,tcp_error,"localhost",5673,
>                           #Port<0.6927>,
>                           {ssl_options,[],verify_peer,
>                            {#Fun<ssl.3.54384637>,
>                             #Fun<rabbit_networking.0.89858908>},
>                            false,false,undefined,1,
>                            "C:/certstore/server/cert.pem",undefined,
(Continue reading)

Sergey Shilov | 2 Aug 09:09 2012
Picon

Re: missing function clause in ssl_connection:handle_alert


On Aug 2, 2012, at 1:35 AM, Matthias Radestock wrote:

> We got the following process crash report from a user running R15B01 (trimmed somewhat to hide private key material):
> 
> =CRASH REPORT==== 31-Jul-2012::11:49:27 ===
>  crasher:
>    initial call: ssl_connection:init/1
>    pid: <0.2005.0>
>    registered_name: []
>    exception exit: {function_clause,
>                     [{ssl_connection,handle_alert,
>                       [{alert,1,41,{"ssl_connection.erl",1678}},
>                        certify,
>                        {state,server,
>                         {#Ref<0.0.0.3519>,<0.2004.0>},
>                         gen_tcp,tcp,tcp_closed,tcp_error,"localhost",5673,
>                         #Port<0.6927>,
>                         {ssl_options,[],verify_peer,
>                          {#Fun<ssl.3.54384637>,
>                           #Fun<rabbit_networking.0.89858908>},
>                          false,false,undefined,1,
>                          "C:/certstore/server/cert.pem",undefined,

The problem is old and (probably) well-known

http://erlang.2086793.n4.nabble.com/ssl-connection-crash-on-client-connect-w-o-certificte-tt3570411.html#none

A possible solution included

(Continue reading)

Matthias Radestock | 2 Aug 10:52 2012

Re: missing function clause in ssl_connection:handle_alert

On 02/08/12 08:09, Sergey Shilov wrote:
> The problem is old and (probably) well-known
>
> http://erlang.2086793.n4.nabble.com/ssl-connection-crash-on-client-connect-w-o-certificte-tt3570411.html#none

Ah. I knew I should have done a search first. I see you got no reply to 
your original post. Shame that this still hasn't been fixed, more than a 
year later :(

Matthias.
_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs

Ali Sabil | 2 Aug 15:55 2012
Picon

Re: missing function clause in ssl_connection:handle_alert

On Thu, Aug 2, 2012 at 9:09 AM, Sergey Shilov <hsvhome <at> mail.ru> wrote:
>
> On Aug 2, 2012, at 1:35 AM, Matthias Radestock wrote:
>
>> We got the following process crash report from a user running R15B01 (trimmed somewhat to hide private
key material):
>>
>> =CRASH REPORT==== 31-Jul-2012::11:49:27 ===
>>  crasher:
>>    initial call: ssl_connection:init/1
>>    pid: <0.2005.0>
>>    registered_name: []
>>    exception exit: {function_clause,
>>                     [{ssl_connection,handle_alert,
>>                       [{alert,1,41,{"ssl_connection.erl",1678}},
>>                        certify,
>>                        {state,server,
>>                         {#Ref<0.0.0.3519>,<0.2004.0>},
>>                         gen_tcp,tcp,tcp_closed,tcp_error,"localhost",5673,
>>                         #Port<0.6927>,
>>                         {ssl_options,[],verify_peer,
>>                          {#Fun<ssl.3.54384637>,
>>                           #Fun<rabbit_networking.0.89858908>},
>>                          false,false,undefined,1,
>>                          "C:/certstore/server/cert.pem",undefined,
>
>
> The problem is old and (probably) well-known
>
> http://erlang.2086793.n4.nabble.com/ssl-connection-crash-on-client-connect-w-o-certificte-tt3570411.html#none
(Continue reading)

Sergey Shilov | 2 Aug 17:24 2012
Picon

Re: missing function clause in ssl_connection:handle_alert


On Aug 2, 2012, at 4:55 PM, Ali Sabil wrote:


A possible solution included



Maybe you could submit the patch to erlang-patches?


No problem :-)
The patch is redirected to the "erlang-patches" mailing list.

Regards.

Sergey.
_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs
Joe Armstrong | 3 Aug 11:12 2012
Picon

bug in erlang:size

I think this is a bug:

$erl
1> B = <<1:17>>.
<<0,0,1:1>>
2> size(B)
2

B is not a binary or tuple to size(B) should give badarg

/Joe
_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs

Warren Smith | 3 Aug 19:05 2012
Picon

bug decoding AuthorityKeyIdentifier in certificate?


I've come across what may be a bug in the function dec_AuthorityKeyIdentifier(Tlv, TagIn) in
OTP-PUB-Key.erl in version R15B01.

A simple test program is:

$ cat test_cert.erl

-module(test_cert).
-export([cert_file_to_db/1,cert_from_file/1]).

cert_file_to_db(File) ->
        Db = ssl_certificate_db:create(),
        ssl_certificate_db:add_trusted_certs(self(), File, Db).

cert_from_file(File) ->
        {ok, PemBin} = file:read_file(File),

        [PemEntry] = public_key:pem_decode(PemBin),
        {'Certificate', Cert, not_encrypted} = PemEntry,

        ErlCert = public_key:pkix_decode_cert(Cert, otp),
        io:format("~p~n",[ErlCert]).

On this certificate:

$ cat 5813ea38.0

-----BEGIN CERTIFICATE-----
MIICgjCCAeugAwIBAgIBADANBgkqhkiG9w0BAQUFADA3MQ0wCwYDVQQKEwRBdXRv
MRkwFwYDVQQLExBGdXR1cmVHcmlkTmltYnVzMQswCQYDVQQDEwJDQTAeFw0xMDA5
MDcxNjM0NDJaFw0xNTA5MDcxNjM0NTJaMDcxDTALBgNVBAoTBEF1dG8xGTAXBgNV
BAsTEEZ1dHVyZUdyaWROaW1idXMxCzAJBgNVBAMTAkNBMIGfMA0GCSqGSIb3DQEB
AQUAA4GNADCBiQKBgQCyYqVUsHNqOUS+31s2zdMj7HTENnmdTxb+Ihbt50zl+L/o
VTJkRWEw3Vy3F8KSbIHEfViDPAMBcpv2KZGZIZfCfGE9wfwEp/mcuEY/WA+jKSev
lKFQXPWZQtP0OhwT7h2ZHYK/BA8gNvEpKmqvxm8Kb71v/HCXANYoZMwwgjNIcwID
AQABo4GdMIGaMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFBhsOpAcfJATaaHH
EeG7ff96svu2MFsGA1UdIwRUMFKAFBhsOpAcfJATaaHHEeG7ff96svu2oTcxDTAL
BgNVBAoTBEF1dG8xGTAXBgNVBAsTEEZ1dHVyZUdyaWROaW1idXMxCzAJBgNVBAMT
AkNBggEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOBgQCuaZaw8f8AmQg4
CiOMgR2qs1zqiXXDGJTx5mnvcDwgyWKqrsNj+8g9oh0R8fx29jUJvq82cVCk0mTR
6Yl/wlgFPFHveykA94AzMoHrVBdmusRJRN0B7GTCTnMCnSHhG0FBjagyqC92MZj4
qJRQswlft8SqfOTxezAZLRXSDJYvvw==
-----END CERTIFICATE-----

Results in:

$ erl -noshell -s test_cert cert_from_file 5813ea38.0 -s init stop
{"init terminating in do_boot",{{badmatch,{error,{asn1,{invalid_choice_tag,{17,[{16,[{6,<<3
bytes>>},{19,<<4 bytes>>}]}]}}}}},[{public_key,pkix_decode_cert,2,[{file,"public_key.erl"},{line,216}]},{test_cert,cert_from_file,1,[{file,"test_cert.erl"},{line,15}]},{init,start_it,1,[]},{init,start_em,1,[]}]}}

Crash dump was written to: erl_crash.dump
init terminating in do_boot ()

This certificate is handled ok by OpenSSL (e.g. openssl x509 -in 5813ea38.0 -text -noout) and by at least
one Java X.509 implementation.

I haven't looked in to the process of how public_key/asn1/OTP-PUB-KEY.erl is generated, but this block of
code in the dec_AuthorityKeyIdentifier(Tlv, TagIn) function:

    %%-------------------------------------------------
    %% attribute authorityCertIssuer(2)   External OTP-PUB-KEY:GeneralNames OPTIONAL
    %%-------------------------------------------------
    {Term2, Tlv3} = case Tlv2 of
                     [{131073, V2} | TempTlv3] ->
                         {dec_GeneralNames(V2, []), TempTlv3};
                     _ -> {asn1_NOVALUE, Tlv2}
                   end,

Is where the problem start showing up. For the above certificate, it is passing this to
dec_GeneralNames(Tlv, TagIn):

  Tlv: [{17,[{16,[{6,<<85,4,10>>},{19,<<"Auto">>}]}]},
        {17,[{16,[{6,<<85,4,11>>},{19,<<"FutureGridNimbus">>}]}]},
        {17,[{16,[{6,<<85,4,3>>},{19,<<"CA">>}]}]}]
  TagIn: []

This doesn't look like what dec_GeneralNames() expects. It is close to what dec_Name() expects, though.

There are perhaps 2 problems here. First, ({1310??, ???}, []) needs to be passed to dec_GeneralNames() not
just (???, []). Second, 131076 should be associated with the above Tlv, not 131073.

So, a hack of:

    %%-------------------------------------------------
    %% attribute authorityCertIssuer(2)   External OTP-PUB-KEY:GeneralNames OPTIONAL
    %%-------------------------------------------------
    {Term2, Tlv3} = case Tlv2 of
                      [{131073, V2} | TempTlv3] ->
                          {dec_GeneralNames([{131076, {16, V2}}], []), TempTlv3};
                      _ -> {asn1_NOVALUE, Tlv2}
                    end,

Works around the problem for this certificate. 

What I haven't dug in to is why asn1rt_ber_bin_v2__decode(B, nif) is picking 131073 instead of 131076 (see
below). I don't really understand what these numbers represent or where they are coming from so I'm not
sure if there is a problem with the code, or with this certificate. However, from RFC 3280, it seems like it
is valid to have a Name/RDN (or any other GeneralName) as the authorityCertIssuer. Maybe there is a
restriction somewhere that I'm missing, though...

decode(Type, Data)
  Type: 'AuthorityKeyIdentifier'
  Data: <<48,82,128,20,24,108,58,144,28,124,144,19,105,161,199,17,225,187,125,
          255,122,178,251,182,161,55,49,13,48,11,6,3,85,4,10,19,4,65,117,116,
          111,49,25,48,23,6,3,85,4,11,19,16,70,117,116,117,114,101,71,114,105,
          100,78,105,109,98,117,115,49,11,48,9,6,3,85,4,3,19,2,67,65,130,1,0>>
  element: {16,
            [{131072,
              <<24,108,58,144,28,124,144,19,105,161,199,17,225,187,125,255,
                122,178,251,182>>},
             {131073,
              [{17,[{16,[{6,<<85,4,10>>},{19,<<"Auto">>}]}]},
               {17,[{16,[{6,<<85,4,11>>},{19,<<"FutureGridNimbus">>}]}]},
               {17,[{16,[{6,<<85,4,3>>},{19,<<"CA">>}]}]}]},
             {131074,<<0>>}]}
_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs

Warren Smith | 3 Aug 21:10 2012
Picon

bug decoding domain components in certificate?


I've come across another problem with decoding some certificates in R15B01. An example certificate where
the problem occurs is:

$ cat 684261aa.0
-----BEGIN CERTIFICATE-----
MIIEHTCCAwWgAwIBAgIBATANBgkqhkiG9w0BAQUFADBuMRMwEQYKCZImiZPyLGQB
GRMDRURVMRYwFAYKCZImiZPyLGQBGRMGVVRFWEFTMRQwEgYKCZImiZPyLGQBGRME
VEFDQzESMBAGA1UEChMJVVQtQVVTVElOMRUwEwYDVQQDEwxUQUNDIFJvb3QgQ0Ew
HhcNMDgxMDAyMDM1NjAyWhcNMTgwOTMwMDM1NjAyWjBuMRMwEQYKCZImiZPyLGQB
GRMDRURVMRYwFAYKCZImiZPyLGQBGRMGVVRFWEFTMRQwEgYKCZImiZPyLGQBGRME
VEFDQzESMBAGA1UEChMJVVQtQVVTVElOMRUwEwYDVQQDEwxUQUNDIFJvb3QgQ0Ew
ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCwlD+7dc8Am/rnd1bvvyW+
UGlkXb3KxlObgmlx0RdznJvWrxCPz4/nfvk87toUX2L4fxv3/mO3Q6n0UVFc83og
oJlNh8oqNJuVotH6jg+e65XD0z4QSNSgLVAWGV/9TU93PGUALgfXJFng3VbJ/Ljb
o01RbOQjOD7e5VJIx52wlOiyaMQlaV0yZ4C5OxgpKR/X2xMtqbuCGVIieeOBJtzg
cvatyuEIZBSHA/qhX51Rqrfc8MtKeZ/Zu7K4v0RC77bolptsAg36LCRR1T9BcyJx
Gv+yj52m5bPBuJj6ALEx/CkI6fAmkDGLvtIwZJRByrN8BdXYrBme6q0NChJg1pPR
AgMAyfujgcUwgcIwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUjXUjaNFVmWzD
ph6G/N/EU+jlU8cwHwYDVR0jBBgwFoAUjXUjaNFVmWzDph6G/N/EU+jlU8cwDgYD
VR0PAQH/BAQDAgEGMB0GA1UdEQQWMBSBEmNhQHRhY2MudXRleGFzLmVkdTBABgNV
HR8EOTA3MDWgM6Axhi9odHRwOi8vd3d3LnRhY2MudXRleGFzLmVkdS9DQS9UQUND
X1Jvb3RfQ1JMLmRlcjANBgkqhkiG9w0BAQUFAAOCAQEAm7B3gK4RiE50ct2cAbhT
dD1BOHXVIIb312ZlqB6IqwM+EFfo4HW82/bDbfPfF8QZMvESuRkFl0mVK5hYPT12
VWsQC5sX6wz1ps5dgoaJ+lLZbgb3pStnN0lZEAfufMog98GM+DW6YnJaWIYpv2Mv
QbRYInGZAYWHR2GJbUjyKh2u0sJZOHJjffDL4NCUsA2thaKDcE0CG8bjwikYEVHX
j6GTY5rLsKW2NfJ8VU40dPEGjtWMOsC0HFoy27Nj5Gi2j6WpRD49EKN7+pg6Dy2I
Em9R60Sl6WhKgo//3+mg8/mZqsqCQSq5BNa7M5ltyx1RgFPoRhKlTDXLDzxVEFNk
Cg==
-----END CERTIFICATE-----

A simple test program is:

$ cat test_cert.erl

-module(test_cert).
-export([cert_file_to_db/1,cert_from_file/1]).

cert_file_to_db(File) ->
        Db = ssl_certificate_db:create(),
        ssl_certificate_db:add_trusted_certs(self(), File, Db).

cert_from_file(File) ->
        {ok, PemBin} = file:read_file(File),

        [PemEntry] = public_key:pem_decode(PemBin),
        {'Certificate', Cert, not_encrypted} = PemEntry,

        ErlCert = public_key:pkix_decode_cert(Cert, otp),
        io:format("~p~n",[ErlCert]).

And the error I see is:

$ erl -noshell -s test_cert cert_from_file 684261aa.0 -s init stop
{"init terminating in do_boot",{{badmatch,{error,{asn1,{{case_clause,22},[{'OTP-PUB-KEY',check_and_convert_restricted_string,5,[{file,"OTP-PUB-KEY.erl"},{line,14128}]},{'OTP-PUB-KEY',decode,2,[{file,"OTP-PUB-KEY.erl"},{line,499}]},{pubkey_cert_records,transform,2,[{file,"pubkey_cert_records.erl"},{line,60}]},{lists,map,2,[{file,"lists.erl"},{line,1173}]},{pubkey_cert_records,transform,2,[{file,"pubkey_cert_records.erl"},{line,72}]},{pubkey_cert_records,decode_tbs,1,[{file,"pubkey_cert_records.erl"},{line,189}]},{pubkey_cert_records,decode_cert,1,[{file,"pubkey_cert_records.erl"},{line,40}]},{public_key,pkix_decode_cert,2,[{file,"public_key.erl"},{line,211}]}]}}}},[{public_key,pkix_decode_cert,2,[{file,"public_key.erl"},{line,215}]},{test_cert,cert_from_file,1,[{file,"test_cert.erl"},{line,
 15}]},{init,start_it,1,[]},{init,start_em,1,[]}]}}

Crash dump was written to: erl_crash.dump
init terminating in do_boot ()

I see that dec_DomainComponent(Tlv, TagIn) gets arguments:

  Tlv: {19,<<"EDU">>}
  TagIn: [22]

And this results (after a couple levels of function calls) in match_tags() returning:

{error,{asn1,{wrong_tag,{19,22}}}}

It looks like this certificate has domain components that use the type poste-restante-address (19) while
the erlang code expects extended-network-address (22). I'm not entirely sure what the correct behavior
should be. I spent some time looking around the X.509-related RFCs and didn't manage to find constraints
on what types can be used in domain components. This certificate is handled ok by OpenSSL (e.g. openssl
x509 -in 5813ea38.0 -text -noout) and by at least one Java X.509 implementation, though.

I just did a work around by changing dec_DomainComponent() from:

dec_DomainComponent(Tlv) ->
    dec_DomainComponent(Tlv, [22]).

To:

dec_DomainComponent(Tlv) ->
    {Tag, Data} = Tlv,
    case Tag of
        19 -> decode_restricted_string(Tlv, [], Tag, [Tag]);
        22 -> decode_restricted_string(Tlv, [], Tag, [Tag])
    end.

_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs

Steve Davis | 4 Aug 01:06 2012
Picon

Re: [erlang-questions] bug in erlang:size

3> byte_size(B).
3


On Friday, August 3, 2012 4:12:02 AM UTC-5, Joe Armstrong wrote:
I think this is a bug:

$erl
1> B = <<1:17>>.
<<0,0,1:1>>
2> size(B)
2


B is not a binary or tuple to size(B) should give badarg

/Joe
_______________________________________________

_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs

Gmane