backport SSL_OP_NO_ENCRYPT_THEN_MAC to 1.1.0#3922
backport SSL_OP_NO_ENCRYPT_THEN_MAC to 1.1.0#3922kaduk wants to merge 3 commits intoopenssl:OpenSSL_1_1_0-stablefrom
Conversation
Reviewed-by: Tim Hudson <[email protected]> Reviewed-by: Matt Caswell <[email protected]> (cherry picked from commit cde6145)
CHANGES
Outdated
Verify that the encrypt-then-mac negotiation is handled correctly. Additionally, when compiled with no-asm, this test ensures coverage for the constant-time MAC copying code in ssl3_cbc_copy_mac. The proxy-based CBC padding test covers that as well but it's nevertheless better to have an explicit handshake test for mac-then-encrypt. Reviewed-by: Andy Polyakov <[email protected]> (cherry picked from commit b3618f4)
|
@openssl/omc any advice on how to work around the supposed lack of CLA for dwwm2's Intel address? |
|
He is no longer at Intel. We have Intel’s CCLA with his address. Treat it as covered.
|
|
The git hooks might complain when you try and push it though. We might need to temporarily add him back into the CLA db while you do the push. |
|
I will remove the need-cla label from github for the time being, then. |
|
ping @openssl/omc to review this backport |
|
This looks good to me - @mattcaswell ? |
|
Remind me why we are backporting a feature? I understood that the original Websphere motivation was no longer relevant. |
|
I can tickle a Websphere bug by sending encrypt-then-mac at all, whether or not it's the last extension. |
|
Picking up this old one again. It looks like I have an approval from @t-j-h, so I just want @mattcaswell to confirm that his question about "backporting a feature" has been adequately addressed. |
|
It doesn't seem to have been answered in the above? Am I missing it somewhere? |
|
I claim that if I send encrypt-then-mac in my ClientHello to a Websphere server, regardless of whether it is the last extension, Websphere sends me back malformed HTTP on the resulting connection. |
CHANGES
Outdated
| which is the minimum version we support. | ||
| [Richard Levitte] | ||
| *) Support for SSL_OP_NO_ENCRYPT_THEN_MAC in SSL_CONF_cmd. | ||
| [Emilia Käsper] |
There was a problem hiding this comment.
It seems this CHANGES entry is in the wrong place
Oh, right. I had misunderstood your earlier comment. |
[to be squashed] [skip ci]
|
Okay, new commit (to be squashed) moving the CHANGES entry added. |
mattcaswell
left a comment
There was a problem hiding this comment.
You may need some support from @levitte to get this committed due to the CLA issue noted above.
| *) Ignore the '-named_curve auto' value for compatibility of applications | ||
| with OpenSSL 1.0.2. | ||
| [Tomas Mraz <[email protected]>] | ||
| *) Support for SSL_OP_NO_ENCRYPT_THEN_MAC in SSL_CONF_cmd. |
There was a problem hiding this comment.
Nit: we normally have a space between different CHANGES entries.
Indeed, gitaddrev refuses to process the first commit, which I can of course work around manually, but even if I do so the server's hook is not convinced. @levitte do we want to just temporarily add David's Intel address to the DB? |
|
Considering that David's commit is from before we started with the CLAs, I do find the proposed hack justifiable. I'll do the merge myself. |
|
BTW, do we really need to do a gitaddrev on all the commits? Except for the last commit, they have already been reviewed... |
|
And duh, that commit is to be squashed anyway... |
|
I made a false statement earlier... David's commit was made after we started with CLAs, but at a time when his Intel address was covered... Sorry for the confusion. |
As well as the tests for mac-then-encrypt that Emilia added.
I resolved a couple conflicts (1.1.0 disallows ETM entirely for DTLS already, so the conditional changes, etc.) and moved the CHANGES entry to reflect the new reality.
We're seeing reports that WebSphere 8.x can't handle ETM at all (regardless of whether empty extensions are last). :(