[erlang-questions] TLS handshake records don't handle fragments?

[Ryan Stewart]

Hi Ingela! Yeah, let me be more clear. The issue is when Erlang is acting
as a client and receives a "certificate request" from a server during the
handshake, as described at https://tools.ietf.org/html/rfc5246#section-7.4.4.
Since Erlang is receiving the message, it's a decode rather than an encode,
but the problem is that it's not handling fragmented messages, similar to
the story I linked. I'm able to recreate the issue easily by starting a
server that sends certificate requests using the system-installed CAs on a
CentOS box, like this:

$ openssl req -x509 -newkey rsa:2048 -keyout private.pem -out public.pem
-days 365 -nodes
$ openssl s_server -accept 12345 -cert public.pem -key private.pem -CAfile
/etc/pki/tls/certs/ca-bundle.crt -verify 1

Then from Erlang:

1> application:ensure_all_started(ssl).
{ok,[crypto,asn1,public_key,ssl]}
2> ssl:connect("localhost", 12345, []).

=ERROR REPORT==== 2-May-2018::14:30:13 ===
SSL: certify: tls_connection.erl:774:Fatal error: handshake failure
{error,{tls_alert,"handshake failure"}}

There are so many CAs included by default these days, it's enough to
trigger this bug. If you add a "-msg" to the s_server, you'll see the (very
long) certificate request sent out, followed by a handshake_failure alert
received from the client (Erlang). On the off chance you try this on a
system without enough CAs, I guess we could just generate a bunch of certs
and make our own, big CA file. The certificate request in my test above was
19185 bytes, which is larger than a TLS record is allowed to be, so it
forces fragmentation.

On Wed, May 2, 2018 at 5:32 AM Ingela Andin <ingela.andin@REDACTED> wrote:

> Hi!
>
> 2018-05-01 19:23 GMT+02:00 Ryan Stewart <zzantozz@REDACTED>:
>
>> I've been getting handshake_failure alerts when trying to connect to a
>> particular server, and I think I've traced it to the fact that the TLS
>> records aren't being handled correctly with respect to fragments. In
>> particular, this server is sending a rather large "certificate request" to
>> allow for client cert auth, and the list is too long to fit in one TLS
>> record. That's breaking the TLS handshake in at least Erlang 18 and 19, I
>> believe. It's basically a mirror image of the problem described in
>> https://bugs.erlang.org/browse/ERL-83. That issue is with Erlang as the
>> TLS server. I'm seeing the same thing with it being the client. Is this
>> addressed somewhere?
>>
>>
> Can you give me a possibility to recreate the issue?  That issue you
> described was fixed in 18 and both the client and the server uses the same
> code to encode handshakes. The issue was in the encoding and not in the
> decoding. Can you tell us more details of how you reached your conclusion?
>
> Regards Ingela Erlang/OTP Team - Ericsson AB
>
>
>
>
>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20180502/c6e9a8d4/attachment.htm>