[erlang-questions] Making SSL fail silently

[Danil Zagoskin]

Yes, I have reproduced a crash in handshake parsing.
Pull Request with test case is available at
https://github.com/erlang/otp/pull/286

By the way, there is another crash when talking to security scanner —
badarg at crypto:rsa_sign_nif:
** Reason for termination =
** {badarg,[{crypto,rsa_sign_nif,
                    [md5sha,

 {digest,<<124,187,138,41,125,55,222,61,16,209,73,157,86,

 21,130,223,96,214,189,59,0,64,136,130,168,238,
                               245,220,105,191,145,194,112,201,251,184>>},
                     _LARGE_IOLIST_HERE_ ],
                    []},
            {crypto,sign,4,[{file,"crypto.erl"},{line,467}]},
            {ssl_handshake,enc_server_key_exchange,6,
                           [{file,"ssl_handshake.erl"},{line,660}]},
            {tls_connection,key_exchange,1,
                            [{file,"tls_connection.erl"},{line,1661}]},
            {tls_connection,server_certify_and_key_exchange,1,
                            [{file,"tls_connection.erl"},{line,1553}]},
            {tls_connection,new_server_hello,2,
                            [{file,"tls_connection.erl"},{line,1470}]},
            {tls_connection,next_state,4,
                            [{file,"tls_connection.erl"},{line,2548}]},
            {gen_fsm,handle_msg,7,[{file,"gen_fsm.erl"},{line,505}]}]}

I'll look at this later.



2014-03-09 20:11 GMT+04:00 Andreas Schultz <aschultz@REDACTED>:

> Hi,
>
> ----- Original Message -----
> > I've investigated this case a bit and it seems to me that ECC handshake
> > implementation has a bug:
> > As fas as I understand RFC 4492 (
> > https://tools.ietf.org/html/rfc4492#section-5.1 ), it tells that it's
> OK for
> > server to not support all curves supported by client if there are enough
> > curves supported by both of them.
> > So if I'm correct, the tls_v1:enum_to_oid/1 function should have a
> default
> > clause returning some magic value ('unsupported_curve' ?) which should be
> > filtered out from EllipticCurves list in ?ELLIPTIC_CURVES_EXT clause of
> > ssl_handshake:dec_hello_extensions/2 (line 1654).
>
> There have been several changes that went into R16B03 and R17 concerning
> the curve selection. Did you check if your problem also occurs with those
> releases?
>
> Andreas
>
> >
> > I hope to fix it today.
> >
> >
> > 2014-03-09 1:49 GMT+04:00 Ingela Andin < ingela.andin@REDACTED > :
> >
> >
> >
> > Hi!
> >
> > 2014-03-07 11:14 GMT+01:00 Danil Zagoskin < z@REDACTED > :
> >
> >
> >
> >
> > Thank you!
> >
> > May I help you? Test case, pull request, etc?
> >
> >
> > You are always welcome to make a pull request which, if you follow the
> guide
> > lines, should include a test case.
> >
> >
> > Regards Ingela Erlang/OTP team - Ericsson AB
> >
> >
> >
> >
> >
> > 2014-03-07 1:39 GMT+04:00 Ingela Andin < ingela.andin@REDACTED > :
> >
> >
> >
> > Hi!
> >
> > 2014-03-06 11:50 GMT+01:00 Danil Zagoskin < z@REDACTED > :
> >
> >
> >
> >
> > Hello!
> >
> > My application is listening SSL port using ssl:listen,
> ssl:transport_accept
> > and ssl:ssl_accept (indeed it uses some old patched mochiweb).
> > Erlang/OTP release is R16B02.
> > I use SASL for error logging.
> >
> > Due to existence of network scanners, network errors and buggy clients
> some
> > of connections fail to negotiate. This leads to two kind of log entries:
> > 1. "insufficient security", etc.
> > 2. Crash reports due to a function_clause error in tls_v1:enum_to_oid(0)
> > (this may be not the only one, but definitely the most popular)
> >
> > First one seems to be fixed by {log_alert, false} ssl option.
> > Second one keeps flooding logs with huge state printouts.
> >
> > So, my question is: How to make all SSL-related troubles not to generate
> > error reports? Simple {error, handshake_failed} returned by one of
> accepting
> > functions would be enough.
> >
> >
> >
> >
> > The first option should logically be enough. I think the problem is that
> > tls_v1:enum_to_oid
> > should have a try and throw a handshake alert if it fails or be ignored,
> > depending on situation, i.e. be an expected error instead of an
> unexpected
> > error. I will create an issue to handle that.
> >
> > Regards Ingela Erlang/OTP team - Ericsson AB
> >
> > _______________________________________________
> > erlang-questions mailing list
> > erlang-questions@REDACTED
> > http://erlang.org/mailman/listinfo/erlang-questions
> >
> >
> >
> >
> > --
> > ---------------------------------------------
> > Данил Загоскин | +7 906 064 20 47 | z@REDACTED
> >
> >
> >
> >
> > --
> > ---------------------------------------------
> > Данил Загоскин | +7 906 064 20 47 | z@REDACTED
> >
> > _______________________________________________
> > erlang-questions mailing list
> > erlang-questions@REDACTED
> > http://erlang.org/mailman/listinfo/erlang-questions
> >
>
> --
> --
> Dipl. Inform.
> Andreas Schultz
>
> email: as@REDACTED
> phone: +49-391-819099-224
> mobil: +49-170-2226073
>
> ------------------- enabling your networks -------------------
>
> Travelping GmbH               phone:         +49-391-819099229
> Roentgenstr. 13               fax:           +49-391-819099299
> D-39108 Magdeburg             email:       info@REDACTED
> GERMANY                       web:   http://www.travelping.com
>
> Company Registration: Amtsgericht Stendal Reg No.:   HRB 10578
> Geschaeftsfuehrer: Holger Winkelmann | VAT ID No.: DE236673780
> --------------------------------------------------------------
>



-- 
---------------------------------------------
Данил Загоскин | +7 906 064 20 47 | z@REDACTED
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140309/7383976d/attachment.htm>