-
-
Notifications
You must be signed in to change notification settings - Fork 15.9k
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
BoringSSL + TLSv1.2 client side SSL renegociation fails #11529
Comments
As far as I remember we don't support renegotiation when using the OpenSSL / BoringSSL based engines because these are considered not secure anymore. https://boringssl.googlesource.com/boringssl/+/refs/heads/master/include/openssl/ssl.h#4056 |
Here, Netty is client side and the initiator is the server. Also, this request works fine with Chrome, whose TLS implementation is BoringSSL. Doesn't renegotiation only bring security issues when the initiator is the client, not the server? |
I suspect we would need to enable it explicit for BoringSSL: |
Indeed. Does it looks feasible to you to introduce a new option to be passed through |
Yeah I guess something like this. That said I think we will also need to add some changes to |
I'm off on vacation tonight, so I'll only be able to have a look in a few weeks. Thanks for your insights! |
@slandelle no worries... I will also be on vacation soon 😆 |
Again??? You're just back! 😆 |
Let me pick this up this week again |
This is also related to apple/swift-nio-ssl#111 |
Motivation: renegiotion is not supported by BoringSSL by default but sometimes when using on the client-side you might want to support it for CLIENT-AUTH. See also apple/swift-nio-ssl#111 Modifications: Add native / java code to be able to enable support Result: Part of netty/netty#11529
tcnative change that is needed: netty/netty-tcnative#654 |
Motivation: renegiotion is not supported by BoringSSL by default but sometimes when using on the client-side you might want to support it for CLIENT-AUTH. See also apple/swift-nio-ssl#111 Modifications: Add native / java code to be able to enable support Result: Part of netty/netty#11529
…ed SSLEngine Motivation: We should allow server initiated renegotiation when OpenSSL / BoringSSL bases SSLEngine is used as it might be used for client auth. Modifications: - Upgrade netty-tcnative version to be able to allow renegotiate once - Adjust code Result Fixes #11529
…ed SSLEngine Motivation: We should allow server initiated renegotiation when OpenSSL / BoringSSL bases SSLEngine is used as it might be used for client auth. Modifications: - Upgrade netty-tcnative version to be able to allow renegotiate once - Adjust code Result Fixes #11529
…ed SSLEngine (netty#11601) Motivation: We should allow server initiated renegotiation when OpenSSL / BoringSSL bases SSLEngine is used as it might be used for client auth. Modifications: - Upgrade netty-tcnative version to be able to allow renegotiate once - Adjust code Result Fixes netty#11529
…ed SSLEngine (netty#11601) Motivation: We should allow server initiated renegotiation when OpenSSL / BoringSSL bases SSLEngine is used as it might be used for client auth. Modifications: - Upgrade netty-tcnative version to be able to allow renegotiate once - Adjust code Result Fixes netty#11529
…ed SSLEngine (netty#11601) Motivation: We should allow server initiated renegotiation when OpenSSL / BoringSSL bases SSLEngine is used as it might be used for client auth. Modifications: - Upgrade netty-tcnative version to be able to allow renegotiate once - Adjust code Result Fixes netty#11529
Expected behavior
BoringSSL based SSLEngine should support SSL renegociation out of the box like the JDK one.
Actual behavior
SSLEngine and connection crashes during renegociation.
This issue was originally reported against Gatling, see gatling/gatling#4120 for more details.
Steps to reproduce
See pure Netty reproducer below.
Minimal yet complete reproducer code (or URL to code)
https://github.com/slandelle/netty-ssl-renegociation
Netty version
4.1.66.Final
JVM version (e.g.
java -version
)openjdk version "1.8.0_292"
OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_292-b10)
OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.292-b10, mixed mode)
OS version (e.g.
uname -a
)Darwin Kernel Version 20.5.0: Sat May 8 05:10:33 PDT 2021; root:xnu-7195.121.3~9/RELEASE_X86_64 x86_64
The text was updated successfully, but these errors were encountered: