CODEWITHSUNDEEP
sslhttpsopenssltls1.25g
Paras Jani
Paras Jani

Reputation: 11

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:

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:

My Questions:

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

Upvotes: 1

Views: 78

Answers (1)

dave_thompson_085
dave_thompson_085

Reputation: 39000

TLDR: TLS is competently designed

But first, your description cannot be correct. Assuming "send client key" means the ClientKeyExchange message, you are using TLS 1.2 or lower (and lower is now prohibited by nearly all standards and rejected by many systems), apparently with 'plain RSA' (no DHE) keyexchange, and the minimum possible handshake for that case, as shown in RFC5246 and tailored, is four 'flights' (groups) of messages:

  1. client sends ClientHello
  2. server sends ServerHello, Certificate, ServerHelloDone
  3. client sends ClientKeyExchange, ChangeCipherSpec, Finished
  4. server sends ChangeCipherSpec, Finished

Now some or all of the messages in each flight can be combined into one network-level packet and frame, so if you are only looking at the packet or frame (or TCP segment) level you may not see all the messages, but they must be there.

Now in order to be secure, TLS must prevent tampering with the handshake because that would allow an active attacker to downgrade and then break the security; see e.g. FREAK and Logjam. Also see the last item in the list on page 34. TLS through 1.2, like SSL3 before it, uses a combination of mechanisms for this:

  1. for all keyexchanges, the full handshake 'transcript' is MACed in the Finished messages (one in each direction)

  2. for DHE (ephemeral Diffie-Hellman) keyexchange only, the ServerKeyExchange message is signed by the server

  3. if client authentication is used (which is rare), the transcript up to that point (including both KeyExchange messages) is signed by the client in CertificateVerify

(TLS1.3 keeps 1 and 3 the same, but always uses DHE and for 2 signs the transcript similar to 3)

Thus if plain-RSA without client-auth is used, tampering with ClientHello is first detected on processing of the first Finished message, which per the flow above is is in the client's second flight shortly after ClientKeyExchange. There are two variants of this:

  • if extended_master_secret option is used (that is, offered by client and agreed by server), the key derivation uses the full transcript, so any tampering will cause the client and server keys to be different, and the MAC on (the record containing) the Finished message does not verify

  • otherwise, the key derivation will use only the two Hello.random values plus the premaster secret, and in your description those aren't tampered and neither is the ciphersuite selection (which controls the hash used) and derivation works and the record MAC succeeds, but the MAC in the Finished message (which uses the full transcript) fails

You case is apparently in the first of these variants.

To 'resolve' this: if you want security (with TLS) don't tamper with the handshake; if you don't want security don't use TLS (and there is no handshake to tamper).

Upvotes: 0

Related Questions