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

[Ingela Andin]

Hi Ryan!


2018-05-02 18:08 GMT+02:00 Ryan Stewart <zzantozz@REDACTED>:

>  I actually just checked it in the current release of 20, and it works
> there. It's just broken in 18 and 19 that I know of.
>


Ah, ok the only relevant commit that I can think of that could have fixed
it is: 1364c7308e17d43d1a2244e3f2bf11cfec3789ef

Regards Ingela Erlang/OTP team



>
> On Wed, May 2, 2018 at 10:52 AM Ingela Andin <ingela.andin@REDACTED>
> wrote:
>
>> Hi!
>>
>> I have not had time to check, but it sounds like it could be another bug
>> that  I recently fixed. Could you try out the release candidate for OTP 21.
>>
>> Regards Ingela Erlang/OTP Team - Ericsson AB
>>
>> 2018-05-02 16:38 GMT+02:00 Ryan Stewart <zzantozz@REDACTED>:
>>
>>> 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/20180503/02f70759/attachment.htm>