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

Add support for TLSv1.3 #8293

Merged
merged 1 commit into from Oct 17, 2018
Merged

Add support for TLSv1.3 #8293

merged 1 commit into from Oct 17, 2018

Conversation

normanmaurer
Copy link
Member

Motivation:

TLSv1.3 support is included in java11 and is also supported by OpenSSL 1.1.1, so we should support when possible.

Modifications:

  • Add support for TLSv1.3 using either the JDK implementation or the native implementation provided by netty-tcnative when compiled against openssl 1.1.1
  • Adjust unit tests for semantics provided by TLSv1.3
  • Correctly handle custom Provider implementations that not support TLSv1.3

Result:

Be able to use TLSv1.3 with netty.

@normanmaurer
Copy link
Member Author

This depends on netty/netty-tcnative#389.

synchronized (this) {
if (!isDestroyed()) {
// TODO: Should we also adjust the protocols based on if there are any ciphers left that can be used
// for TLSv1.3 or for previor SSL/TLS versions ?
Copy link
Member Author

Choose a reason for hiding this comment

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

Copy link
Member

Choose a reason for hiding this comment

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

Sounds kinda niche. Maybe we can wait until someone asks for it?

@@ -2199,6 +2209,10 @@ public int getPeerPort() {

@Override
public int getPacketBufferSize() {
// TODO: Do a better job for TLSv1.3 here.
Copy link
Member Author

Choose a reason for hiding this comment

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

@carl-mastrangelo @ejona86 @ryanoneill @bryce-anderson @Scottmitch @trustin this needs to be fixed before merging as it may waste memory.

Copy link
Member Author

Choose a reason for hiding this comment

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

Currently checking what to do best...

@normanmaurer
Copy link
Member Author

Once this is merged I have a followup PR that will allow to use TLSv1.3 also on Java8,9 and 10 :) But I want to have this one merged first to keep the scope small

@normanmaurer
Copy link
Member Author

Also another question is if we should add TLSv1.3 by default to the protocols used or if the user should enable it explicit... thoughts ?

@carl-mastrangelo
Copy link
Member

IIRC TLS 1.3 was subject (sometimes) to replay attacks, which considered ok for idempotent requests like GETs. I have no idea about the details, but I remember that and being surprised. Probably worth checking before turning it on by default.

synchronized (this) {
if (!isDestroyed()) {
// TODO: Should we also adjust the protocols based on if there are any ciphers left that can be used
// for TLSv1.3 or for previor SSL/TLS versions ?
Copy link
Member

Choose a reason for hiding this comment

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

Sounds kinda niche. Maybe we can wait until someone asks for it?

@@ -1470,13 +1473,20 @@ public final void setEnabledProtocols(String[] protocols) {
if (maxProtocolIndex < OPENSSL_OP_NO_PROTOCOL_INDEX_TLSv1_2) {
maxProtocolIndex = OPENSSL_OP_NO_PROTOCOL_INDEX_TLSv1_2;
}
} else if (p.equals(PROTOCOL_TLS_V1_3)) {
if (minProtocolIndex > OPENSSL_OP_NO_PROTOCOL_INDEX_TLSv1_3) {
Copy link
Member

Choose a reason for hiding this comment

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

minProtocolIndex = Math.min(minProtocolIndex, OPENSSL_OP_NO_PROTOCOL_INDEX_TLSv1_3);

Copy link
Member Author

Choose a reason for hiding this comment

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

@carl-mastrangelo I could do this I just wanted to keep it consistent with the rest.

// This may fail or not depending on the OpenSSL version used
// See https://github.com/openssl/openssl/issues/7196
testInvalidCipher(SslProvider.OPENSSL);
if (!OpenSsl.versionString().contains("1.1.1")) {
Copy link
Member

Choose a reason for hiding this comment

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

Why not also asume the version string above?

Copy link
Member Author

Choose a reason for hiding this comment

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

@carl-mastrangelo because I want to have the test run with all versions and just test for different things.

@normanmaurer normanmaurer force-pushed the openssl_1_1_1 branch 2 times, most recently from 79ee03c to 344505f Compare September 24, 2018 10:52
@normanmaurer
Copy link
Member Author

@carl-mastrangelo @ejona86 @Scottmitch @trustin any more comments ? I would love to pull this in...

Copy link
Member

@trustin trustin left a comment

Choose a reason for hiding this comment

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

Looks good in general. Didn't review very very closely though because I'm traveling.

@@ -450,4 +489,8 @@ static void releaseIfNeeded(ReferenceCounted counted) {
ReferenceCountUtil.safeRelease(counted);
}
}

static boolean isTlsv13Supported() {
Copy link
Member

Choose a reason for hiding this comment

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

Tls13 or TlsV13?

Copy link
Member Author

Choose a reason for hiding this comment

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

I actually like isTlsv13Supported best... are you strong here ?

Copy link
Member

Choose a reason for hiding this comment

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

Lowercase v is what Google's style guide says, if it matters.

import static io.netty.handler.ssl.SslUtils.PROTOCOL_TLS_V1_2;
import static io.netty.handler.ssl.SslUtils.SSL_RECORD_HEADER_LENGTH;

import static io.netty.handler.ssl.SslUtils.*;
Copy link
Member

Choose a reason for hiding this comment

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

Hmm, did we change our coding style?

Copy link
Member Author

Choose a reason for hiding this comment

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

not sure :D I can revert this if you want.

Copy link
Member

Choose a reason for hiding this comment

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

Maybe it's time to adopt https://github.com/google/google-java-format for love and peace? 😄

@normanmaurer normanmaurer force-pushed the openssl_1_1_1 branch 2 times, most recently from 19bc197 to 20f3043 Compare September 28, 2018 09:36
@normanmaurer
Copy link
Member Author

@carl-mastrangelo @trustin anything else ?

Copy link
Member

@carl-mastrangelo carl-mastrangelo left a comment

Choose a reason for hiding this comment

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

No other comments from me. LGTM

@normanmaurer
Copy link
Member Author

@netty-bot test this please

@normanmaurer
Copy link
Member Author

@netty-bot test this please

Motivation:

TLSv1.3 support is included in java11 and is also supported by OpenSSL 1.1.1, so we should support when possible.

Modifications:
- Add support for TLSv1.3 using either the JDK implementation or the native implementation provided by netty-tcnative when compiled against openssl 1.1.1
- Adjust unit tests for semantics provided by TLSv1.3
- Correctly handle custom Provider implementations that not support TLSv1.3

Result:

Be able to use TLSv1.3 with netty.
@thekalinga
Copy link

Once this is merged I have a followup PR that will allow to use TLSv1.3 also on Java8,9 and 10 :) But I want to have this one merged first to keep the scope small

Is it fair to say netty does not yet support TLS 1.3 if the jdk used is Java 8?

@normanmaurer
Copy link
Member Author

@thekalinga nope... as long as you use netty-tcnative-boringssl-static it will also support TLSv1.3 with Java8

@thekalinga
Copy link

@normanmaurer Thanks for the clarification

@thekalinga
Copy link

thekalinga commented Nov 6, 2018

@normanmaurer Request for one small clarification. If netty-tcnative-boringssl-static enables TLS 1.3 with java 8, can you please elaborate on what you mentioned in the comment (please note that I am complete noob to netty), as I'm a bit puzzled

@normanmaurer
Copy link
Member Author

@thekalinga sorry I dont get what you are asking for... Can you clarify ?

@thekalinga
Copy link

I just came across the other pull request of yours where you added support for Java < 11 support

This clarifies my confusion

Please ignore my previous comment. Looks like my question caused more confusion

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

Successfully merging this pull request may close these issues.

None yet

4 participants