Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ERL-803: Server-initiated renegotiation after client data fails with 'bad_record_mac' #3763

Closed
OTP-Maintainer opened this issue Dec 16, 2018 · 5 comments
Assignees
Labels
bug Issue is reported as a bug priority:high team:PS Assigned to OTP team PS
Milestone

Comments

@OTP-Maintainer
Copy link

Original reporter: voltone
Affected versions: OTP-21.1, OTP-21.2
Fixed in version: OTP-21.2.1
Component: ssl
Migrated from: https://bugs.erlang.org/browse/ERL-803


Originally reported by Nico Caille on ElixirForum:
https://elixirforum.com/t/hackney-and-client-certificates-error-closed/18723

Since OTP 21.1, if an Erlang client has previously sent data to a server and subsequently responds to a HelloRequest from the server with a renegotiation ClientHello, that message is malformed, causing the connection to fail. Note that this scenario is not covered by the ssl test suite (it tests renegotiation without prior data exchange).

It was originally reported with Hackney in combination with a Microsoft IIS server, which parses the client's HTTP request before deciding it wants to ask for a client certificate. IIS does not send an alert, but closes the TCP connection.

The issue can be reduced to a minimal case with 'ssl:connect' to 'openssl s_server', sending some data from the client and then triggering renegotiation on the server. This results in a bad_record_mac fatal alert.

In OTP 21.0.9 and earlier releases, the same scenario succeeds, so I suspect the issue was introduced in https://github.com/erlang/otp/commit/d87ac1c55188f5ba5cdf72384125d94d42118c18

I created a crude test case that reproduces the issue. A diff for the test suite (against master) and the test output attached.
@OTP-Maintainer
Copy link
Author

ingela said:

Thank you for the test case, I have confirmed that it fails.  I agree with you that the sender process
commit is a suspect. It is needed to avoid a deadlock but alas it makes renegotiation harder to get correct. We will investigate.

@OTP-Maintainer
Copy link
Author

ingela said:

The following branch  ingela/ssl/renegotiate-with-new-tls-sender
 in my git repo:  https://github.com/IngelaAndin/otp.git fixes the problem for me.


@OTP-Maintainer
Copy link
Author

voltone said:

Confirmed against the original IIS server, with both httpc and Hackney

@OTP-Maintainer
Copy link
Author

ingela said:

Thank you, I have included the patch in our nightly build and  we will make a patch soonish.
Can not promise before new year but with a little luck... 

@OTP-Maintainer
Copy link
Author

voltone said:

Thanks!

@OTP-Maintainer OTP-Maintainer added bug Issue is reported as a bug team:PS Assigned to OTP team PS priority:high labels Feb 10, 2021
@OTP-Maintainer OTP-Maintainer added this to the OTP-21.2.1 milestone Feb 10, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Issue is reported as a bug priority:high team:PS Assigned to OTP team PS
Projects
None yet
Development

No branches or pull requests

2 participants