TLS 1.2 connection to erlang server (RabbitMQ) is setting Extended master secret: no

[graorane]

Describe the bug
Hi,
We are using RabbitMQ, an Erlang based application.
Erlang version : 26.2.5.2
OpenSSL version : 3.0.14 (used to build Erlang and consumed at runtime.)
RabbitMQ version : 3.13.2

RabbitMQ server is listening on TLS 1.2 as well as TLS 1.3.
Whenever client connects to server on TLS1.2, it appears that connection has "Extended master secret: no"

SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: 16DB7E207C12415D26EAF40CFC06B17F5912424E24560C31937E11C9CA3713D4
Session-ID-ctx:
Master-Key: 90B8DA82C810AFBD3F62D2E7949875C948193832DFCB391C38828D6CD223FA6F7457D20DF1D1E0F01781718E43CE5E22
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1734696006
Timeout : 7200 (sec)
Verify return code: 20 (unable to get local issuer certificate)
Extended master secret: no

How to set it to Yes i.e.
Extended master secret: yes

[lukebakken]

@graorane your issue report is lacking very important information such as:

• The version of Erlang you are using.
• Steps to reproduce the issue you report.

I had time, so I put together the following repository with explicit steps and code to reproduce the issue you report. Hopefully it'll make @IngelaAndin's life easier:

https://github.com/lukebakken/erlang-otp-9235

Extended master secret is irrelevant for TLS1.3 - openssl/openssl#7421

[graorane]

Thanks lukebakken for pointing no version in description and adding the steps to reproduce issue.

Updated issue description with version information.

[IngelaAndin]

Alas, this pre TLS-1.3 extension is not supported, so it is not possible to set it to true. We prioritized TLS-1.3 implementation over adding support for various extensions to pre TLS-1.3 versions. We still might consider adding it, and if it is important to you PR's are always welcome as I can not say when this might be high enough priority to happen. I would consider this one of the more interesting extensions, of the ones not supported, to implement due to that legacy lingers longer than most people expect, although it offers better security the attacks it protects against are pretty special. As far as I understand you need to use client certificates, or so called "channel binding" for authentication and then the attack comes into play when TLS-based authentication is used during a renegotiation. In such a case a malicious server might be able to spoof another server.