[erlang-bugs] possible bug in ssl and/or public_key module (R13 and R14)

Ingela Anderton Andin <>
Tue Sep 21 14:07:24 CEST 2010


Filipe David Manana wrote:
> On Mon, Sep 20, 2010 at 2:47 PM, Ingela Anderton Andin <
> > wrote:
>> So I definitely consider this a regression :(
>> The weird thing is that I can use this certificates file with the old ssl
>> implementation (default on R13 and R12 releases) on R13B03 and R13B04 at
>> least.
>> Well the thing is that the old ssl-implementation only is an erlang-glue
>> that leaves the most things up to the underlaying openssl implementation,
>> but the new ssl
>> only uses openssl crypto library and takes care the ssl protocol
>> fsm-machinery and  certificate  handling on its own. This makes many things
>> much easier to implement
>> and removes the bottleneck enforced by the glue, and also lessens the
>> required resource allocation. Of course this may cause new bugs occasionally
>> and we fix them
>> as fast as we can.
>> If you want to try out the latest changes to fix the DSS-Params bug you can
>> get the branch ia/ssl-asn1-spec-dss-params at my github account
>> :IngelaAndin/otp.git
> Hi,
> Ingela, I tried your git branch  ssl-asn1-spec-dss-params but unfortunatelly
> I still get an exception:
> =ERROR REPORT==== 21-Sep-2010::11:57:03 ===
> SSL: 1060: error:{error,
>                      {asn1,
>                          {{case_clause,19},
>                           [{'OTP-PUB-KEY',
>                                check_and_convert_restricted_string,5},
>                            {'OTP-PUB-KEY',decode,2},
>                            {pubkey_cert_records,transform,2},
>                            {lists,map,2},
>                            {lists,map,2},
>                            {pubkey_cert_records,transform,2},
>                            {pubkey_cert_records,decode_tbs,1},
>                            {pubkey_cert_records,decode_cert,2}]}}}
> /home/fdmanana/tmp/ibrowse-test/ca-certificates.crt
>   []
> ** exception error: no match of right hand side value {error,ecacertfile}

Yes I get this too, it seems to be that one of the certificates in the file
has a field that is utf8-encoded but the asn-1-spec says that it should
be a "printableString".  I do not know if openssl tries to decode it, it 
not until it is used, and it might not be. Erlang ssl caches all cert in 
the ca-file.
I have now made new ssl more tolerant so that it
will ignore such ca-certs, that does not follow the spec.  I have pushed 
the change to
the ia/ssl-asn1-spec-dss-params branch.

> And btw, with the old ssl implementation, using a ssl socket in {active,
> once} mode, I receive very often an error like this:
> [Thu, 16 Sep 2010 00:10:34 GMT] [error] [<0.604.0>] ** Generic server
> <0.604.0> terminating
> ** Last message in was {tcp,#Port<0.2288>,
>  <<"\r\n6d\r\n,\n{\"seq\":70,\"id\":\"97b36d5003934d0c9dd58057b05fa167\",\"changes\":[{\"rev\":\"1-0d6deda5b380ae207ba87a7a3a32d0a1\"}]}\r\n6d\r\n,\n{\"seq\":71,\"id\":\"8a1c475b8dc5426e9172d6b970ae7c03\",\"changes\":[{\"rev\":\"1-72851f645fb6ab77f36866cbe505d82c\"}]}\r\n6d\r\n,\n{\"seq\":72,\"id\":\"fdb1d5b1c5b24ce481463ad668c13c40\",\"changes\":[{\"rev\":\"1-c37b5444eec8375631c326a0e77ca427\"}]}\r\n6d\r\n,\n{\"seq\":73,\"id\":\"b612465dafc44699b09d8bef5d4d4d8d\",\"changes\":[{\"rev\":\"1-be951f78ba830f5a1002abe0ce479c2d\"}]}\r\n6d\r\n,\n{\"seq\":74,\"id\":\"d2c2b5a771ef4b57b6d58fce2808cf7c\",\"changes\":[{\"rev\":\"1-c628443ff4dd7c3d9b4fd226727e2841\"}]}\r\n6d\r\n,\n{\"seq\":75,\"id\":\"8d669c377f08442981ce2d18a21d920b\",\"changes\":[{\"rev\":\"1-6db3a14c76701b87b0686412093ac103\"}]}\r\n6d\r\n,\n{\"seq\":76,\"id\":\"367bf0948d9d459582d187c9232844b8\",\"changes\":[{\"rev\":\"1-16ae7cf1c04c4f7c024493de1f18c8ed\"}]}\r\n6d\r\n,\n{\"seq\":77,\"id\":\"f2c805327ae740098e5db221c3f27b4b\",\"changes\":[{\"rev\":\"1-b22aa541f7e353a4cd430a9293239c77\"}]}\r\n6d\r\n,\n{\"seq\":78,\"id\":\"6ddf8033cec845c8986ee4bd03ff8ed6\",\"changes\":[{\"rev\":\"1-23f5957d250f5079277e6e4a86def1f1\"}]}\r\n6d\r\n,\n{\"seq\":79,\"id\":\"738365bd4fed44158516211847c13616\",\"changes\":[{\"rev\":\"1-6dcd375366f107fb2575c8eda6c6bdec\"}]}\r\n6d\r\n,\n{\"seq\":80,\"id\":\"2d66c797761b4506934d00b2fd260f90\",\"changes\":[{\"rev\":\"1-cc7dddd31fd753a9b4577607ce321cef\"}]}\r\n6d\r\n,\n{\"seq\":81,\"id\":\"0c01c012d4f540a3a015d57681a0af4f\",\"changes\":[{\"rev\":\"1-ff288fbba546fbfbf78c602e2fa39ea2\"}]}\r\n6d\r\n,\n{\"seq\":82,\"id\":\"dc8a7ff04d37428ea83c3515a801bd32\",\"changes\":[{\"rev\":\"1-2">>}
> ** When Server state ==
> {st,connector,<0.119.0>,<0.603.0>,<0.603.0>,11,false,
>                            [{mode,binary},
>                              {nodelay,true},
>                             {active,once},
>                              {packet,0},
>                             {ip,{0,0,0,0}},
>                              {verify,0},
>                             {depth,1}],
>                             {sslsocket,11,<0.604.0>},
>                            #Port<0.2288>,nil,open,false,false}
> The data, third argument of the tuple, is what is supposed to be. However
> the ssl module trows that exception (since it was expecting to receive only
> messages like {ssl, Socket, Data}). Is this a known issue?

Humm ... not that I know of.  We are aiming to remove the old 
ssl-implementation as soon as the new one is compleate enough and
in first hand we do not fix things in the old implementation.

Regards Ingela Erlang/OTP team - Ericsson AB

More information about the erlang-bugs mailing list