[erlang-bugs] Crash in SSL

Ingela Anderton Andin <>
Thu Aug 23 12:11:48 CEST 2012


Daniel Luna wrote:
> Hi Kenneth,
> Long time, no see.
> So to me it looks like this is a combination of issues.  It would make
> me very happy if the OTP team could state the intention to fix these
> issues in the near future.
We will do something about it in a near future.
> 1. The Erlang ssl module verifies the validity of the certificate even
> when {verify, verify_none} has been set.  This could most easily be
> fixed by a change to the documentation about what it means to use the
> verify_none verification.
It does not verify the validity of the certificate in verify_none mode, 
it however unpacks (decodes)
the certificate using the ASN-1 spec, we still need to go through the 
certificate path to extract the public key.
The thing that happens is that your certificate for some reason violates 
the ASN-1 spec, however in practice
the value is an allowed one and we could make a workaround to allow it.

> 2. The ssl module *crashes* on bad data instead of returning {error
> Error} or {ok, Conn} (note that this crash happens for {verify,
> verify_none} which should give us a connection back even if the
> certificate is bad)
It would have if there had been a certificate path validation error,  
e.i. that the certificate was
bad in that sense. Your certificate is not on the correct format for a 
certificate and that is the
> 3. A gen_fsm dies in the background (with the main issue of clobbering
> our error logs, and hiding real errors behind all the noise)
I agree that we could make it go down gracefully if the certificate can 
not be decoded,
we will fix that.

> 4. The Erlang ssl module is in disagreement with Chrome and Firefox
> (and probably other browsers) about what is a valid certificate
> 1, 2, and 3 are definitely bugs.  I personally think 4 is a bug too,
> but am willing to listen to arguments stating otherwise.
> (As a side note I don't see how the utf8-encoded string "US" is in 
> any  way bitwise different from the ASCII-encoded string "US" and I don't
> manage to find out if there is a type tag somewhere)
That other implementations relax the spec requirements  intentionally 
or  unintentionally
does not make your certificate correct, however we think that we need to 
be practical about
this and make a workaround so that we accept such certificates as they 
are conceptually
correct (and accepted by other big players) but technically wrong.
Regards Ingela  Erlang/OTP team - Ericsson AB

More information about the erlang-bugs mailing list