[Backport 3.6] Defragment incoming TLS handshake messages (reuse badmac_seen)

[gilles-peskine-arm]

This is the 3.6 backport of #9872, with extra commits to preserve ABI compatibility in 3.6.

A simpler alternative to #9949, which wasn't possible when #9949 was made. Originally we needed room for a message size and a pointer in the SSL context. Now, after an improvement to the original PR, we only need room for a message size, and that's easier to find.

PR checklist

• changelog provided
• development PR Defragment incoming TLS handshake messages #9872
• TF-PSA-Crypto PR not required because: TLS only
• framework PR not required
• 3.6 PR here
• 2.28 PR not required because: in practice this mostly matters for TLS 1.3 which is not in 2.28
• tests deferred to Basic ssl-opt testing for TLS HS defragmentation #9887, Extended ssl-opt tests for TLS HS defragmentation #9987 and Extended test_suite_ssl testing for TLS HS defragmentation #9968

[minosgalanakis]

Thanks for raising this backport PR and the elegant sollution.

Looks good overall, but it would be good to update the programs, using badmac_seen namely ssl_context_info

[minosgalanakis]

LGTM

[mpg]

@gilles-peskine-arm According to git range-diff, 3 commits from the original PR are missing from the backport:

 7:  afa11db62010 <  -:  ------------ Remove obselete checks due to the introduction of handhsake defragmen...
 8:  eb77e5b1c778 <  -:  ------------ Update the changelog message
 9:  cf4e6a18e664 <  -:  ------------ Remove unused variable in ssl_server.c

Can you explain why?

[mpg]

LGTM except for the 3 missing commits.

As usual, thanks for the nice commit structure of the ABI-fixing refactoring, always appreciated as a reviewer.

[gilles-peskine-arm]

My bad, I had started from #9949 then removed the tests and hadn't noticed the non-ssl-opt commits in the middle of the ssl-opt commits. I've cherry-picked the extra commits now.

[mpg]

LGTM now, thanks!

[minosgalanakis]

LGTM

[mpg]

For the record, I've double-checked the report from the API/ABI compat checked, only two issues are found, both of which are about the renamed field:

• "Renaming of a field in data type may indicate a change in the semantic meaning of the field." yes absolutely, but applications will be blissfully unaware because the field's private;
• "Recompilation of a client program may be broken with the error message: @type_name has no member named @target." again not an issue for a private field.