<div dir="ltr"> 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.<br></div><br><div class="gmail_quote"><div dir="ltr">On Wed, May 2, 2018 at 10:52 AM Ingela Andin <<a href="mailto:ingela.andin@gmail.com">ingela.andin@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi!<div><br></div><div>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.</div><div><br></div><div></div></div><div dir="ltr"><div>Regards Ingela Erlang/OTP Team - Ericsson AB<br></div></div><div dir="ltr"><div><div class="gmail_extra"><br><div class="gmail_quote">2018-05-02 16:38 GMT+02:00 Ryan Stewart <span dir="ltr"><<a href="mailto:zzantozz@gmail.com" target="_blank">zzantozz@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>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 <a href="https://tools.ietf.org/html/rfc5246#section-7.4.4" target="_blank">https://tools.ietf.org/html/rfc5246#section-7.4.4</a>. 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:<br><br>$ openssl req -x509 -newkey rsa:2048 -keyout private.pem -out public.pem -days 365 -nodes<br>$ openssl s_server -accept 12345 -cert public.pem -key private.pem -CAfile /etc/pki/tls/certs/ca-bundle.crt -verify 1<br><br></div>Then from Erlang:<br><br>1> application:ensure_all_started(ssl).<br>{ok,[crypto,asn1,public_key,ssl]}<br>2> ssl:connect("localhost", 12345, []).<br><br>=ERROR REPORT==== 2-May-2018::14:30:13 ===<br>SSL: certify: tls_connection.erl:774:Fatal error: handshake failure<br>{error,{tls_alert,"handshake failure"}}<br><br></div>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.<br></div><div class="m_-8686707403195451664HOEnZb"><div class="m_-8686707403195451664h5"><br><div class="gmail_quote"><div dir="ltr">On Wed, May 2, 2018 at 5:32 AM Ingela Andin <<a href="mailto:ingela.andin@gmail.com" target="_blank">ingela.andin@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi!<br><div><div class="gmail_extra"><br><div class="gmail_quote"></div></div></div></div><div dir="ltr"><div><div class="gmail_extra"><div class="gmail_quote">2018-05-01 19:23 GMT+02:00 Ryan Stewart <span dir="ltr"><<a href="mailto:zzantozz@gmail.com" target="_blank">zzantozz@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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 <a href="https://bugs.erlang.org/browse/ERL-83" target="_blank">https://bugs.erlang.org/browse/ERL-83</a>. That issue is with Erlang as the TLS server. I'm seeing the same thing with it being the client. Is this addressed somewhere?<br></div>
<br></blockquote><div><br></div></div></div></div></div><div dir="ltr"><div><div class="gmail_extra"><div class="gmail_quote"><div>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<br></div><div>decoding. Can you tell us more details of how you reached your conclusion?<br><br></div><div>Regards Ingela Erlang/OTP Team - Ericsson AB<br></div><div><br><br><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></div><br></div></div></div>
</blockquote></div>
</div></div></blockquote></div><br></div></div></div></blockquote></div>