SSL Handshake Error (BAD RECORD MAC) when Sending Mobile Number in Client Hello via HAProxy

Description:

I am working on a mobile application where the client (mobile) sends a request to generate a token through the cellular network to a 5G Core network. The 5G Core adds the mobile number (MSISDN) in the Client Hello message extension before sending it to HAProxy. The request from the mobile app is successfully received by the server, including the mobile number in the Client Hello message.

Here’s the sequence of events:

  • The server receives the Client Hello message with the mobile number in the extension.
  • The server sends a Hello message and a certificate to the client.
  • The mobile client sends the client key to the HAProxy server (through 5gc).

At this point, HAProxy throws an error: SSL Handshake Error with the following message in the PCAP: Level: 2 Fatal Description: BAD RECORD MAC

Troubleshooting Steps Taken:

  • I tried the same configuration with Nginx but faced the same error.
  • I changed the SSL certificate, but the error persists.
  • If I disable the 5G Core task (which adds the MSISDN in the Client Hello message extension), the SSL handshake error does not occur.
  • If I enable the 5G Core but do not include the MSISDN extension in the Client Hello message, the error is also avoided.

My Questions:

  • What could be causing the "BAD RECORD MAC" error when the mobile number (MSISDN) is added to the Client Hello message?
  • Is there any specific configuration or setting in HAProxy or SSL/TLS that could help resolve this issue?
  • Why does disabling the 5G Core task prevent the SSL handshake error?

I would appreciate any insights or suggestions on how to resolve this SSL handshake error.

Bad Record MAC indicates that a TLS record (ie, a message) has been modified in transit. The message authentication code (MAC) is "bad" because it doesn't match the message, because the message has been modified.

Which it sounds like is what's happening when the 5G core is injecting the extension.

I think you need to talk to your 5G core vendor who is modifying the messages to figure out what they expect, as this is very non-standard behaviour.

TLS is designed to provide integrity and not allow connections to be modified. If you're adding some extra data into the client hello, you probably have to remove it with specialized code before handling the rest of the connection with a stock TLS library.

While this forum is happy to help with issues adjacent to Let's Encrypt issuance, I think you're not likely to get help here.

8 Likes

Thanks @mcpherrinm for response.

It is our requirement.

5GC needs to add msisdn in the request, so how is it possible?

Session ID and random id are not changed for a single request, it means not any issue with adding an extension in Client Hello Message.

Is it possible to add a header in the HTTPS flow? if yes, then how?

TLS protects the entire TCP message, not just the IDs or randoms. Any manipulation of the message is detected.

5 Likes

You have to do that on the device that initiates the request, not on the service providers layer.

Your application design is effectively creating a MITM Attack (Man-in-the-middle attack - Wikipedia), and the various components are correctly raising fatal exceptions.

4 Likes

I'd like to emphasize the above: this Community mainly deals with Let's Encrypt related TLS issues. Your issue doesn't sound directly Let's Encrypt or certificate related, but with the more intricate details of TLS.

Chances are you can get better help/results on other Communities.

2 Likes

@jvanasco Thanks for prompt response.

It is based on URL filter, 5GCore adding MSISDN in TLS flow Client Hello Message (Add Extension and DATA)

For OpenResty and HAProxy, a Lua script needs to:

:one: Extract the custom extension (MSISDN) from the TLS Client Hello message.
:two: Restore the original TLS Client Hello message by removing the custom extension and recalculating lengths and hashes.