Failed to assert middlebox server message in ssl:connect on OTP 26 and 27

ruslandoga commented 2 months ago

Describe the bug I noticed that TLS connections to eagle.mxlogin.com:465 fail unless either [{versions, ['tlsv1.2']}] or [{versions, ['tlsv1.3']}, {middlebox_comp_mode, false}] options are provided.

To Reproduce

$ erl
Erlang/OTP 27 [RELEASE CANDIDATE 3] [erts-15.0] [source] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:1] [jit]
Eshell V15.0 (press Ctrl+G to abort, type help(). for help)

1> ssl:start(), ssl:connect('eagle.mxlogin.com', 465, [{verify, verify_none}]).
%> {error,{tls_alert,{unexpected_message,"TLS client: In state hello_middlebox_assert at ssl_gen_statem.erl:763 generated CLIENT ALERT: Fatal - Unexpected Message\n {unexpected_msg,{internal,{encrypted_extensions,#{}}}}"}}}

=WARNING REPORT==== 9-May-2024::14:34:19.919593 ===
Description: "Failed to assert middlebox server message"
     Reason: [{missing,{change_cipher_spec,1}}]

=NOTICE REPORT==== 9-May-2024::14:34:19.924557 ===
TLS client: In state hello_middlebox_assert at ssl_gen_statem.erl:763 generated CLIENT ALERT: Fatal - Unexpected Message
 - {unexpected_msg,{internal,{encrypted_extensions,#{}}}}

These work:

1> ssl:connect('eagle.mxlogin.com', 465, [{verify, verify_none}, {versions, ['tlsv1.2']}]).
%> {ok,{sslsocket,{gen_tcp,#Port<0.4>,tls_connection,undefined},
%>               [<0.115.0>,<0.114.0>]}}
2> ssl:connect('eagle.mxlogin.com', 465, [{verify, verify_none}, {versions, ['tlsv1.3']}, {middlebox_comp_mode, false}]).
%> {ok,{sslsocket,{gen_tcp,#Port<0.4>,tls_connection,undefined},
%>                [<0.115.0>,<0.114.0>]}}

Expected behavior The client connects with no extra options provided, as does openssl.

openssl s_client -connect eagle.mxlogin.com:465

``` Connecting to 45.43.208.25 CONNECTED(00000005) depth=2 C=US, O=Internet Security Research Group, CN=ISRG Root X1 verify return:1 depth=1 C=US, O=Let's Encrypt, CN=R3 verify return:1 depth=0 CN=eagle.mxlogin.com verify return:1 --- Certificate chain 0 s:CN=eagle.mxlogin.com i:C=US, O=Let's Encrypt, CN=R3 a:PKEY: id-ecPublicKey, 384 (bit); sigalg: RSA-SHA256 v:NotBefore: Apr 8 23:22:16 2024 GMT; NotAfter: Jul 7 23:22:15 2024 GMT 1 s:C=US, O=Let's Encrypt, CN=R3 i:C=US, O=Internet Security Research Group, CN=ISRG Root X1 a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256 v:NotBefore: Sep 4 00:00:00 2020 GMT; NotAfter: Sep 15 16:00:00 2025 GMT --- Server certificate -----BEGIN CERTIFICATE----- MIIEQTCCAymgAwIBAgISBHAMqx9KZp7foiGZf9lZPEy/MA0GCSqGSIb3DQEBCwUA MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD EwJSMzAeFw0yNDA0MDgyMzIyMTZaFw0yNDA3MDcyMzIyMTVaMBwxGjAYBgNVBAMT EWVhZ2xlLm14bG9naW4uY29tMHYwEAYHKoZIzj0CAQYFK4EEACIDYgAEMUTegj5F u6P5Un6efi0lXOzxxxg7j6VECndsSlDKgeLUi+SR6s+ejGa2wrgeIqMfaIDINGyZ oRaa8m/5RFe1LbnC6odeJNI2DFFRZ23IRM3mq38nwpOW7NbixxC3bDF8o4ICEzCC Ag8wDgYDVR0PAQH/BAQDAgeAMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcD AjAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBRgaHWK0EOYDex82Dig4fnUAe0fZDAf BgNVHSMEGDAWgBQULrMXt1hWy65QCUDmH6+dixTCxjBVBggrBgEFBQcBAQRJMEcw IQYIKwYBBQUHMAGGFWh0dHA6Ly9yMy5vLmxlbmNyLm9yZzAiBggrBgEFBQcwAoYW aHR0cDovL3IzLmkubGVuY3Iub3JnLzAcBgNVHREEFTATghFlYWdsZS5teGxvZ2lu LmNvbTATBgNVHSAEDDAKMAgGBmeBDAECATCCAQQGCisGAQQB1nkCBAIEgfUEgfIA 8AB1AN/hVuuqBa+1nA+GcY2owDJOrlbZbqf1pWoB0cE7vlJcAAABjsA77kgAAAQD AEYwRAIgcG3L+4b49icxtzDFJFszZ5rqNYJ//A0toGNtXZoCLScCIHcUHf/LvGNA ss85sN7mKdVeHXailN3ITMPx5DRQqJsUAHcASLDja9qmRzQP5WoC+p0w6xxSActW 3SyB2bu/qznYhHMAAAGOwDvt2gAABAMASDBGAiEA3AqP2sPW/yq612OF7UzYzJhw 7UNY5PXIuIp9KZu5A0MCIQCHKziZTTJrv0qh4x7iQL3DJpOqzmV+KSZRTE7qKNab MzANBgkqhkiG9w0BAQsFAAOCAQEAj2xeOaKunzpnh9YcmTMvR0/dS1F1+vV9Z6cy iVdlr2hveKx5TZYn1yrjnqGntVuQ8e/ED+nKml6usAQ7uTUh7KCYQpmVNSVIVJGG YGiM9UZ3GXK3HFUH6PHs3bKoVmQEYH40/SYWlH8YsYXr5JAvTFpW+Yf4beYzXFTU evM+UDEqe7/+FezxEdWZ8vfKOCd79Heal7x4GfU2OXOsfbC1L3Ppr6fIFeT1+StI TZZckVwcMU8erdI/QyeErfvFBs63bE/CDlvTdRODKqy1EkG1REagwXuhpuw776A6 /tmfuFtN5eUAl1/gyEhvDfjTdLV55GqbrxY5pmkgvoadmqiyeQ== -----END CERTIFICATE----- subject=CN=eagle.mxlogin.com issuer=C=US, O=Let's Encrypt, CN=R3 --- No client certificate CA names sent Peer signing digest: SHA384 Peer signature type: ECDSA Server Temp Key: X25519, 253 bits --- SSL handshake has read 2805 bytes and written 405 bytes Verification: OK --- New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 Server public key is 384 bit This TLS version forbids renegotiation. Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok) --- 220 eagle.mxlogin.com ESMTP Exim 4.97.1 Thu, 09 May 2024 07:40:57 +0000 ```

Affected versions I've tried the following kerl versions:

  26.1.2
  26.2.1
 *27.0-rc3

All of them return the same error and log the same warnings.

Additional context

It might be related to https://github.com/erlang/otp/issues/6772

IngelaAndin commented 2 months ago

I do not think it is a bug to adhere to the protocol. If the server is broken just turn off the middlebox mode. Just because OpenSSL implementation does not assert the protocol in this case does not make it a bug to follow the spec. Maybe makes us less pragmatic, but such pragmatism has been bad earlier and actually turned out to make implementations vulnerable so we prefer to adhere to the spec.

Middlebox Compatibility Mode

Field measurements [Ben17a] [Ben17b] [Res17a] [Res17b] have found that a significant number of middleboxes misbehave when a TLS client/server pair negotiates TLS 1.3. Implementations can increase the chance of making connections through those middleboxes by making the TLS 1.3 handshake look more like a TLS 1.2 handshake:

The client always provides a non-empty session ID in the ClientHello, as described in the legacy_session_id section of Section 4.1.2.
If not offering early data, the client sends a dummy change_cipher_spec record (see the third paragraph of Section 5) immediately before its second flight. This may either be before its second ClientHello or before its encrypted handshake flight. If offering early data, the record is placed immediately after the first ClientHello.
The server sends a dummy change_cipher_spec record immediately after its first handshake message. This may either be after a ServerHello or a HelloRetryRequest.

When put together, these changes make the TLS 1.3 handshake resemble TLS 1.2 session resumption, which improves the chance of successfully connecting through middleboxes. This "compatibility mode" is partially negotiated: the client can opt to provide a session ID or not, and the server has to echo it. Either side can send

change_cipher_spec at any time during the handshake, as they must be ignored by the peer, but if the client sends a non-empty session ID, the server MUST send the change_cipher_spec as described in this appendix.

ruslandoga commented 2 months ago

👋 @IngelaAndin

Thank you for your reply and the additional information! What surprised me was that middlebox_comp_mode needed to be set to false for the client to connect successfully and not to true. I assumed middlebox_comp_mode set to true increases the chance to connect using TLSv1.3 but it could be the opposite?

I agree that it's not a bug but there were only two options provided on issue creation, a feature request and a bug report. Would it be OK for me to PR an issue template for something like "unexpected behaviour" or "usability issue"?

IngelaAndin commented 2 months ago

The assumption was that the default true would be the choice that would make as many connections as possible work out of the box, but in hindsight I am not sure that is how it turned out!

I think you may call it a feature request, even if it is more of an enhancement.

erlang / otp

Failed to assert middlebox server message in ssl:connect on OTP 26 and 27 #8470