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

[#4736] Clear disabled SSL protocols before enabling provided SSL pro… #4737

Closed
wants to merge 1 commit into from
Closed

Conversation

blucas
Copy link
Contributor

@blucas blucas commented Jan 20, 2016

…tocols

Motivation:

Attempts to enable SSL protocols which are currently disabled fail when using the OpenSslEngine. Related to #4736

Modifications:

Clear out all options that have disabled SSL protocols before attempting to enable any SSL protocol.

Result:

setEnabledProtocols works as expected.

@blucas
Copy link
Contributor Author

blucas commented Jan 20, 2016

@normanmaurer @Scottmitch PTAL

Note: this pull request assumes that a new netty-tcnative tag (1.1.33.Fork11) has been created. This pull request will not build successfully until that tag exists.

@@ -1076,21 +1076,31 @@ public void setEnabledProtocols(String[] protocols) {
// Enable all and then disable what we not want
SSL.setOptions(ssl, SSL.SSL_OP_ALL);

int opts = SSL.SSL_OP_NO_SSLv2 | SSL.SSL_OP_NO_SSLv3 | SSL.SSL_OP_NO_TLSv1 |
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: i guess there is no need to assign this to a temp variable ... consider just passing in the mask directly to clearOptions

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Initially, I did what you suggested, but then noticed I needed the temp variable for the call to setOptions so thought I might as well use it for clearOptions as well. I'm not bothered either way, let me know your thoughts and I'll make the change if you still think I should.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@blucas please adjust as @Scottmitch suggested.

@Scottmitch
Copy link
Member

@blucas - Any thoughts on a test for this, maybe create peers that don't support the same versions and verify the handshake fails?

I'll assign to @normanmaurer to pull in after tcnative is released.

@@ -298,7 +298,7 @@
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>netty-tcnative</artifactId>
<version>1.1.33.Fork10</version>
<version>1.1.33.Fork11</version>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

revert? this artifact does not exist in central Maven and is the reason why the CI build failed.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No it's fine. We need a new netty-tcnative release for this PR

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@normanmaurer - Do you think we could cut a netty-tcnative release for this soon?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes

Am 21.01.2016 um 11:02 schrieb Brendt notifications@github.com:

In pom.xml:

@@ -298,7 +298,7 @@

${project.groupId}
netty-tcnative

  •    <version>1.1.33.Fork10</version>
    
  •    <version>1.1.33.Fork11</version>
    
    @normanmaurer - Do you think we could cut a netty-tcnative release for this soon?


Reply to this email directly or view it on GitHub.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Release was just done

@blucas
Copy link
Contributor Author

blucas commented Jan 21, 2016

Any thoughts on a test for this, maybe create peers that don't support the same versions and verify the handshake fails?

I think a more fundamental test would be nice. Something that:

  1. Creates an OpenSslEngine
  2. Disables an already enabled protocol (via setEnabledProtocols)
  3. Re-enables the protocol (via setEnabledProtocols) that was disabled in step 2

WDYT?

@normanmaurer
Copy link
Member

+1 ... Maybe you could make it part of SSLEngineTest ?

Am 21.01.2016 um 11:06 schrieb Brendt notifications@github.com:

Any thoughts on a test for this, maybe create peers that don't support the same versions and verify the handshake fails?

I think a more fundamental test would be nice. Something that:

  1. Creates an OpenSslEngine
  2. Disables an already enabled protocol
  3. Re-enables the protocol that was disabled in step 2

WDYT?


Reply to this email directly or view it on GitHub.

@blucas
Copy link
Contributor Author

blucas commented Jan 21, 2016

@normanmaurer @Scottmitch - I've added a test and removed the temp variable. PTAL

@@ -263,6 +267,40 @@ public String select(List<String> protocols) {
}
}

@Test
public void testEnablingAnAlreadyDisabledSslProtocol() throws Exception {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we just have this test live in SSLEngineTest? That way we won't need to duplicate the code.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@blucas to make the same test work with OpenSslEngine and the jdk one you can do and instanceof .

@Scottmitch
Copy link
Member

@blucas - Code looks good! after #4737 (comment) is addressed and squashed we can pull in.

@@ -60,6 +66,42 @@ public void testAlpnCompatibleProtocolsDifferentClientOrder() throws Exception {
runTest(PREFERRED_APPLICATION_LEVEL_PROTOCOL);
}

@Test
public void testEnablingAnAlreadyDisabledSslProtocol() throws Exception {
SSLEngine sslEngine = null;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Check if openssl is present first. See the tests above

@normanmaurer
Copy link
Member

@blucas can you address this today as I want to cut 4.1.0.CR1 today ? If not we will need to include it in the next release.

@johnou
Copy link
Contributor

johnou commented Jan 22, 2016

@normanmaurer #4744

@blucas
Copy link
Contributor Author

blucas commented Jan 22, 2016

@normanmaurer - I've made the changes, if you are happy I can squash them.

@johnou
Copy link
Contributor

johnou commented Jan 22, 2016

@blucas I think @Scottmitch may have meant moving the entire test to the super class like this johnou@5d8557b it will be run for all concrete classes which will set the correct provider via io.netty.handler.ssl.SSLEngineTest#sslProvider

@blucas
Copy link
Contributor Author

blucas commented Jan 22, 2016

@johnou - Looking at your test, I don't think it will pass in the case where sslEngine is an instance of OpenSslEngine (OpenSslEngine will always include SSLv2Hello when calling getEnabledProtocols). Diff my version to yours. AFAIK Scott wanted me to get rid of the code duplication, which, in essence, I've done.

@normanmaurer
Copy link
Member

@blucas @johnou I will cherry-pick this one once the ci pass.

@blucas
Copy link
Contributor Author

blucas commented Jan 22, 2016

@normanmaurer - Do you need me to squash?

@normanmaurer
Copy link
Member

@blucas yes please

@blucas
Copy link
Contributor Author

blucas commented Jan 22, 2016

@normanmaurer - Can I do that even while the CI build is running?

…tocols

Motivation:

Attempts to enable SSL protocols which are currently disabled fail when using the OpenSslEngine. Related to #4736

Modifications:

Clear out all options that have disabled SSL protocols before attempting to enable any SSL protocol.

Result:

setEnabledProtocols works as expected.
@normanmaurer
Copy link
Member

@blucas yes

@johnou
Copy link
Contributor

johnou commented Jan 22, 2016

@blucas wouldn't it make more sense to have the actual test in the super class so if a new provider is added it is automatically covered?

@blucas
Copy link
Contributor Author

blucas commented Jan 22, 2016

@normanmaurer - Done

@johnou - You are right, but maybe we can worry about fixing that in a separate PR so that Norman can get this one cherry-picked and cut a release.

@johnou
Copy link
Contributor

johnou commented Jan 22, 2016

alright cool, good work with the contribution 👍

@normanmaurer
Copy link
Member

@blucas thanks again!

Cherry-picked into 4.1 as 7090d13 and into 4.0 as 357720e

@Scottmitch
Copy link
Member

good work @blucas !

@blucas
Copy link
Contributor Author

blucas commented Jan 22, 2016

@normanmaurer @Scottmitch @johnou - Thanks guys, I'm glad I could help

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants