[erlang-bugs] Crash in SSL

[Ingela Anderton Andin]

Hi!

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
problem.
> 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