Netty

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Fix assume

Add whitelist entry to BlockHound config to workaround issue when TLS1.3 is enabled and the SslProvider.JDK is used

Motivation:

SSLEngineImpl.unwrap(...) may call FileInputStream.read(...) internally when TLS1.3 is used. This will cause an BlockingOperationError when BlockHound is enabled.

For more details see https://mail.openjdk.java.net/pipermail/security-dev/2020-August/022271.html

Modifications:

- Add whitelist entry to BlockHound config for now

- Update NettyBlockHoundIntegrationTest to include testing for this workaround

Result:

No BlockingOperationError when TLS1.3 is used with JDK SSL implementation and BlockHound is enabled

Fix #10449, buffer.getBytes(...) not change a file channel position (#10453)

Motivation:

Regression appeared after making changes in fix #10360 .

The main problem here that `buffer.getBytes(buffer.readerIndex(), fileChannel, fileChannel.position(), localsize)`

doesn't change channel position after writes.

Modification:

Manually set position according to the written bytes.

Result:

Fixes #10449 .

Fix #10449, buffer.getBytes(...) not change a file channel position (#10453)

Motivation:

Regression appeared after making changes in fix #10360 .

The main problem here that `buffer.getBytes(buffer.readerIndex(), fileChannel, fileChannel.position(), localsize)`

doesn't change channel position after writes.

Modification:

Manually set position according to the written bytes.

Result:

Fixes #10449 .

Upgrade jctools from 3.0.0 to 3.1.0

Motivation:

JCTools 3.1.0 is out and includes several fixes, see https://github.com/JCTools/JCTools/releases/tag/v3.1.0

Modification:

Upgrade jctools-core version in pom.xml

Result:

Netty ships latest version of jctools.

Create a new h2 stream only if the parent channel is still active (#10444)

Motivation:

If a request to open a new h2 stream was made from outside of the

EventLoop it will be scheduled for future execution on the EventLoop.

However, during the time before the `open0` task will be executed the

parent channel may already be closed. As the result,

`Http2MultiplexHandler#newOutboundStream()` will throw an

`IllegalStateException` with the message that is hard to

interpret correctly for this use-case: "Http2FrameCodec not found. Has

the handler been added to a pipeline?".

Modifications:

- Check that the parent h2 `Channel` is still active before creating a

new stream when `open0` task is picked up by EventLoop;

Result:

Users see a correct `ClosedChannelException` in case the parent h2

`Channel` was closed concurrently with a request for a new stream.

Create a new h2 stream only if the parent channel is still active (#10444)

Motivation:

If a request to open a new h2 stream was made from outside of the

EventLoop it will be scheduled for future execution on the EventLoop.

However, during the time before the `open0` task will be executed the

parent channel may already be closed. As the result,

`Http2MultiplexHandler#newOutboundStream()` will throw an

`IllegalStateException` with the message that is hard to

interpret correctly for this use-case: "Http2FrameCodec not found. Has

the handler been added to a pipeline?".

Modifications:

- Check that the parent h2 `Channel` is still active before creating a

new stream when `open0` task is picked up by EventLoop;

Result:

Users see a correct `ClosedChannelException` in case the parent h2

`Channel` was closed concurrently with a request for a new stream.

Replace Class.getClassLoader with io.netty.util.internal.PlatformDependent.getClassLoader in Openssl (#10454)

Motivation:

Replace Class.getClassLoader with io.netty.util.internal.PlatformDependent.getClassLoader in Openssl so it also works when a SecurityManager is in place

Modification:

Replace Class.getClassLoader with io.netty.util.internal.PlatformDependent.getClassLoader in Openssl

Result:

No issues when a SecurityManager is in place

Replace Class.getClassLoader with io.netty.util.internal.PlatformDependent.getClassLoader in Openssl (#10454)

Motivation:

Replace Class.getClassLoader with io.netty.util.internal.PlatformDependent.getClassLoader in Openssl so it also works when a SecurityManager is in place

Modification:

Replace Class.getClassLoader with io.netty.util.internal.PlatformDependent.getClassLoader in Openssl

Result:

No issues when a SecurityManager is in place

New H2 stream promise may never complete (#10443)

Motivation:

`Http2StreamChannelBootstrap#open0` invokes

`Http2MultiplexHandler#newOutboundStream()` which may throw an

`IllegalStateException`. In this case, it will never complete

the passed promise.

Modifications:

- `try-catch` all invocations of `newOutboundStream()` and fail

promise in case of any exception;

Result:

New H2 stream promise always completes.

New H2 stream promise may never complete (#10443)

Motivation:

`Http2StreamChannelBootstrap#open0` invokes

`Http2MultiplexHandler#newOutboundStream()` which may throw an

`IllegalStateException`. In this case, it will never complete

the passed promise.

Modifications:

- `try-catch` all invocations of `newOutboundStream()` and fail

promise in case of any exception;

Result:

New H2 stream promise always completes.

More comments

Address stephanes comment

Do not try to use Unsafe.staticFieldOffset() method under a native image. (#10428)

Motivation:

GraalVM's native images built with native-image tool do not support Unsafe.staticFieldOffset() method (at least, currently). If an application using Netty (and causing initialization of io.netty.util.internal.PlatformDependent0 class) is built into a native image and run, this results in the following error thrown during initialization:

Exception in thread "main" com.oracle.svm.core.jdk.UnsupportedFeatureError: Unsupported method of Unsafe

at com.oracle.svm.core.util.VMError.unsupportedFeature(VMError.java:86)

at jdk.internal.misc.Unsafe.staticFieldOffset(Unsafe.java:230)

at sun.misc.Unsafe.staticFieldOffset(Unsafe.java:662)

at io.netty.util.internal.PlatformDependent0$5.run(PlatformDependent0.java:294)

at java.security.AccessController.doPrivileged(AccessController.java:83)

at io.netty.util.internal.PlatformDependent0.<clinit>(PlatformDependent0.java:279)

This seems to be the reason of the behavior described in #10051.

Modification:

The idea of this commit is to only invoke Unsafe.staticFieldOffset() is we are not in a native image; if we are, behave like if we could not find the field at all.

GraalDetector is borrowed from Spring framework.

Result:

Fixes #10051

Do not try to use Unsafe.staticFieldOffset() method under a native image. (#10428)

Motivation:

GraalVM's native images built with native-image tool do not support Unsafe.staticFieldOffset() method (at least, currently). If an application using Netty (and causing initialization of io.netty.util.internal.PlatformDependent0 class) is built into a native image and run, this results in the following error thrown during initialization:

Exception in thread "main" com.oracle.svm.core.jdk.UnsupportedFeatureError: Unsupported method of Unsafe

at com.oracle.svm.core.util.VMError.unsupportedFeature(VMError.java:86)

at jdk.internal.misc.Unsafe.staticFieldOffset(Unsafe.java:230)

at sun.misc.Unsafe.staticFieldOffset(Unsafe.java:662)

at io.netty.util.internal.PlatformDependent0$5.run(PlatformDependent0.java:294)

at java.security.AccessController.doPrivileged(AccessController.java:83)

at io.netty.util.internal.PlatformDependent0.<clinit>(PlatformDependent0.java:279)

This seems to be the reason of the behavior described in #10051.

Modification:

The idea of this commit is to only invoke Unsafe.staticFieldOffset() is we are not in a native image; if we are, behave like if we could not find the field at all.

GraalDetector is borrowed from Spring framework.

Result:

Fixes #10051

Enable TLS1.3 by default of JDK SSLEngine implementation does by default

Motiviation:

When TLSv1.3 was introduced almost 2 years ago, it was decided to disable it by default, even when it's supported by the underlying TLS implementation.

TLSv13 is pretty stable now in Java (out of the box in Java 11, OpenJSSE for Java 8, BoringSSL and OpenSSL) and may be enabled by default.

Modifications:

Ensure TLSv13 is enabled by default when the underyling JDK SSLEngine implementation enables it as well

Result:

TLSv1.3 is now enabled by default, so users don't have to explicitly enable it.

Enable TLS1.3 by default of JDK SSLEngine implementation does by default

Motiviation:

When TLSv1.3 was introduced almost 2 years ago, it was decided to disable it by default, even when it's supported by the underlying TLS implementation.

TLSv13 is pretty stable now in Java (out of the box in Java 11, OpenJSSE for Java 8, BoringSSL and OpenSSL) and may be enabled by default.

Modifications:

Ensure TLSv13 is enabled by default when the underyling JDK SSLEngine implementation enables it as well

Result:

TLSv1.3 is now enabled by default, so users don't have to explicitly enable it.

Co-authored-by: Stephane Landelle <slandelle@gatling.io>

Stop disabling TLSv1.3 by default, close #10439

Motivation:

When TLSv1.3 was introduced almost 2 years ago, it was decided to disable it by default, even when it's supported by the underlying TLS implementation.

TLSv13 is pretty stable now in Java (out of the box in Java 11, OpenJSSE for Java 8, BoringSSL and OpenSSL).

Modifications:

Remove explicit exclusions from default protocols.

Result:

TLSv1.3 is now enabled by default, so users don't have to explicitly enable it.

Fix DnsNameResolver may have LEAK ByteBuf after cancelling the returned future (#10448)

Motivation:

If we cancel the returned future of resolve query, we may get LEAK. Try to release the ByteBuf if netty can't pass the DnsRawRecord to the caller.

Modification:

Using debug mode I saw there are two places that don't handle trySuccess with release. Try to release there.

Result:

Fixes #10447.

Fix DnsNameResolver may have LEAK ByteBuf after cancelling the returned future (#10448)

Motivation:

If we cancel the returned future of resolve query, we may get LEAK. Try to release the ByteBuf if netty can't pass the DnsRawRecord to the caller.

Modification:

Using debug mode I saw there are two places that don't handle trySuccess with release. Try to release there.

Result:

Fixes #10447.

Make `DefaultHttp2FrameStream.stream` private (#10442)

Motivation:

`DefaultHttp2FrameStream.stream` is not used outside of its class and

therefore can be private.

Modifications:

- Make `DefaultHttp2FrameStream.stream` private;

Result:

Correct visibility scoping for `DefaultHttp2FrameStream.stream`.

Make `DefaultHttp2FrameStream.stream` private (#10442)

Motivation:

`DefaultHttp2FrameStream.stream` is not used outside of its class and

therefore can be private.

Modifications:

- Make `DefaultHttp2FrameStream.stream` private;

Result:

Correct visibility scoping for `DefaultHttp2FrameStream.stream`.

Fix bug in Http2FrameClient (#10427)

Motivation:

This request only has headers frame, it should set endOfStream flag, or

it will never get a response.

Modifications:

Set endOfStream=true in header frame.

Result:

Http2FrameClient can get a response now.

Fix bug in Http2FrameClient (#10427)

Motivation:

This request only has headers frame, it should set endOfStream flag, or

it will never get a response.

Modifications:

Set endOfStream=true in header frame.

Result:

Http2FrameClient can get a response now.

Ignore `.shelf/` folder generated by IntelliJ IDEA (#10445)

Motivation:

IntelliJ IDEA may generate a local folder `.shelf/` for version control.

For more information, see

https://www.jetbrains.com/help/idea/shelving-and-unshelving-changes.html

Modifications:

- Add `.shelf/` folder to the `.gitignore` file;

Result:

IntelliJ IDEA's `.shelf/` folder is ignored by git.

Ignore `.shelf/` folder generated by IntelliJ IDEA (#10445)

Motivation:

IntelliJ IDEA may generate a local folder `.shelf/` for version control.

For more information, see

https://www.jetbrains.com/help/idea/shelving-and-unshelving-changes.html

Modifications:

- Add `.shelf/` folder to the `.gitignore` file;

Result:

IntelliJ IDEA's `.shelf/` folder is ignored by git.

Making AES_128_GCM_SHA256 have a higher priority over CHACHA20_POLY1305_SHA256 on HTTP2 (#10418)

Motivation:

From the recent benchmark using gRPC-Java based on Netty's HTTP2, it appears that it prefers `ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256` over `ECDHE_ECDSA_WITH_AES_128_GCM_SHA256` since it uses the Netty HTTPS Cipher list as is. Both are considered safe but `ECDHE_ECDSA_WITH_AES_128_GCM_SHA256` has a good chance to get more optimized implementation. (e.g. AES-NI) When running both on GCP Intel Haswell VM, `TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256` spent 3x CPU time than `TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256`. (Note that this VM supports AES-NI)

From the cipher suites listed on `Intermediate compatibility (recommended)` of [Security/Server Side TLS](https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility), they have a cipher preference which is aligned with this PR.

```

0x13,0x01 - TLS_AES_128_GCM_SHA256 TLSv1.3 Kx=any Au=any Enc=AESGCM(128) Mac=AEAD

0x13,0x02 - TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEAD

0x13,0x03 - TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any Enc=CHACHA20/POLY1305(256) Mac=AEAD

0xC0,0x2B - ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) Mac=AEAD

0xC0,0x2F - ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD

0xC0,0x2C - ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD

0xC0,0x30 - ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD

0xCC,0xA9 - ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=ECDSA Enc=CHACHA20/POLY1305(256) Mac=AEAD

0xCC,0xA8 - ECDHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=RSA Enc=CHACHA20/POLY1305(256) Mac=AEAD

0x00,0x9E - DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD

0x00,0x9F - DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD

```

Modification:

Moving up `AES_128_GCM_SHA256` in the CIPHERS of HTTPS so that it gets priority.

Result:

When connecting to the server supporting both `ECDHE_ECDSA_WITH_AES_128_GCM_SHA256` and `ECDSA_WITH_CHACHA20_POLY1305_SHA256` and respecting the client priority of cipher suites, it will be able to save significant cpu time when running it on machines with AES-NI support.

Making AES_128_GCM_SHA256 have a higher priority over CHACHA20_POLY1305_SHA256 on HTTP2 (#10418)

Motivation:

From the recent benchmark using gRPC-Java based on Netty's HTTP2, it appears that it prefers `ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256` over `ECDHE_ECDSA_WITH_AES_128_GCM_SHA256` since it uses the Netty HTTPS Cipher list as is. Both are considered safe but `ECDHE_ECDSA_WITH_AES_128_GCM_SHA256` has a good chance to get more optimized implementation. (e.g. AES-NI) When running both on GCP Intel Haswell VM, `TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256` spent 3x CPU time than `TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256`. (Note that this VM supports AES-NI)

From the cipher suites listed on `Intermediate compatibility (recommended)` of [Security/Server Side TLS](https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility), they have a cipher preference which is aligned with this PR.

```

0x13,0x01 - TLS_AES_128_GCM_SHA256 TLSv1.3 Kx=any Au=any Enc=AESGCM(128) Mac=AEAD

0x13,0x02 - TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEAD

0x13,0x03 - TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any Enc=CHACHA20/POLY1305(256) Mac=AEAD

0xC0,0x2B - ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) Mac=AEAD

0xC0,0x2F - ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD

0xC0,0x2C - ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD

0xC0,0x30 - ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD

0xCC,0xA9 - ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=ECDSA Enc=CHACHA20/POLY1305(256) Mac=AEAD

0xCC,0xA8 - ECDHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=RSA Enc=CHACHA20/POLY1305(256) Mac=AEAD

0x00,0x9E - DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD

0x00,0x9F - DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD

```

Modification:

Moving up `AES_128_GCM_SHA256` in the CIPHERS of HTTPS so that it gets priority.

Result:

When connecting to the server supporting both `ECDHE_ECDSA_WITH_AES_128_GCM_SHA256` and `ECDSA_WITH_CHACHA20_POLY1305_SHA256` and respecting the client priority of cipher suites, it will be able to save significant cpu time when running it on machines with AES-NI support.

Add test

If user explicit ask to use an Inet6Address we should try to do so in native transports

Motivation:

Even if the system does not support ipv6 we should try to use it if the user explicit pass an Inet6Address. This way we ensure we fail and not try to convert this to an ipv4 address internally.

This incorrect behavior was introduced by https://github.com/netty/netty/commit/70731bfa7ef884ee354a5cf96e1545a8d9d090b8

Modifications:

If the user explicit passed an Inet6Address we force the usage of ipv6

Result:

Fixes https://github.com/netty/netty/issues/10402