TLS handshake records don't handle fragments?

TLS handshake records don't handle fragments?

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?

Re: TLS handshake records don't handle fragments?

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?

Re: TLS handshake records don't handle fragments?

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:

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.

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?

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:

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.

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?

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:

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.

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?

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:

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.

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?

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:

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.

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?