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

[ruslandoga]

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 #6772

[IngelaAndin]

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]

👋 @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]

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.