Commit Graph

1326 Commits

Author SHA1 Message Date
Chris Vest
782d70281e
Reduce reliance on ScheduledFuture (#11635)
Motivation:
If we don't need the scheduled future, then it will be one less complication when we change Netty Future to no longer extend JDK Future.
It would also result in fewer elements in our API.

Modification:
There was only one real use of ScheduledFuture in our code, in Cache.
This has been changed to wrap an ordinary future with a deadline for implementing the Delayed interface.
All other places were effectively overspecifying by relying on ScheduledFuture.
A few places were also specifying JDK Futures - these have been changed to specify Netty Futures.

Result:
Reduced dependency on the ScheduledFuture interfaces.
2021-08-31 16:06:34 +02:00
Norman Maurer
a3c44f5a99
Adjust usage of ChannelFutureListeners.CLOSE to use the ChannelHandlerContext (#11631)
Motivation:

Usually the outbound operation should start at the "current" ChanneöHandlercontext which was often not the case

Modifications:

Use the ChannelHandlerContext for closing the connection

Result:

Start the operation on the right position of the pipeline
2021-08-31 12:49:30 +02:00
Norman Maurer
c039f82483 Add missing annotations to test overrides (#11630)
Motivation:

When we override a test with params we also need to ensure we add the correct annotations to the override

Modifications:

Add the correct annotations so the tests are actually run in intellij

Result:

Each test can be run
2021-08-31 08:08:08 +02:00
kushalagrawal
4f1c5b9f95 Added "RSASSA-PSS" algorithm in allowed algorithm list. (#11626)
Motivation:
While OpenSSK is provided support for the "RSASSA-PSS" algorithm this was still not valid from netty. Which was causing issue in validating certificates which was signed using this algorithm.

Modification:
Added "RSASSA-PSS" in LOCAL_SUPPORTED_SIGNATURE_ALGORITHMS.
validation:
Validated and tested with CA and User cert singed with RSASSA-PSS algorithm.

Result:
Fixes #11360

Co-authored-by: Norman Maurer <norman_maurer@apple.com>
2021-08-30 17:24:48 -07:00
Norman Maurer
d7580b526a
Remove public API's that take Promise (#11625)
Motivation:

We did recently change the Channel / ChannelHandler API to always act on the Future only. We should do the same for our handlers.

Modifications:

- Adjust http2 API
- Adjust other handlers API

Result:

Easier to use API and more consistent
2021-08-30 13:15:14 +02:00
Norman Maurer
e04f48d802
Add cascadeTo methods to Future (#11623)
Motivation:

The need of cascade from a Future to a Promise exists. We should add some default implementation for it.

Modifications:

- Merge PromiseNotifier into Futures
- Add default cascadeTo(...) methods to Future
- Add tests to FuturesTest
- Replace usage of PromiseNotifier with Future.cascadeTo
- Use combination of map(...) and cascadeTo(...) in *Bootstrap to reduce code duplication

Result:

Provide default implementation of cascadeTo.
2021-08-29 15:44:34 +02:00
Chris Vest
edf4e28afa
Change !future.isSuccess() to future.isFailed() where it makes sense (#11616)
Motivation:
The expression "not is success" can mean that either the future failed, or it has not yet completed.
However, many places where such an expression is used is expecting the future to have completed.
Specifically, they are expecting to be able to call `cause()` on the future.
It is both more correct, and semantically clearer, to call `isFailed()` instead of `!isSuccess()`.

Modification:
Change all places that used `!isSuccess()` to  mean that the future had failed, to use `isFailed()`.
A few places are relying on `isSuccess()` returning `false` for _incomplete_ futures, and these places have been left unchanged.

Result:
Clearer code, with potentially fewer latent bugs.
2021-08-26 09:43:17 +02:00
Norman Maurer
a873932985
Remove deprecated Channel*Handler* classes (#11615)
* Remove deprecated Channel*Handler* classes

Motivation:

There is no need to keep the older adapter and duplex classes around.

Modifications:

- Remove old adapter and duplex classes
- Adjust javadocs

Result:

Cleanup

* Address nit
2021-08-25 19:04:32 +02:00
Norman Maurer
c4dbbe39c9
Add executor() to ChannelOutboundInvoker and let it replace eventLoop() (#11617)
Motivation:

We should just add `executor()` to the `ChannelOutboundInvoker` interface and override this method in `Channel` to return `EventLoop`.

Modifications:

- Add `executor()` method to `ChannelOutboundInvoker`
- Let `Channel` override this method and return `EventLoop`.
- Adjust all usages of `eventLoop()`
- Add some default implementations

Result:

API cleanup
2021-08-25 18:31:24 +02:00
Norman Maurer
5c879bc963
Don't take Promise as argument in Channel API. (#11346)
Motivation:

At the moment the outbound operations of ChannelHandler take a Promise as argument. This Promise needs to be carried forward to the next handler in the pipeline until it hits the transport. This is API choice has a few quirks which we should aim to remove:

 - There is a difference between if you add a FutureListener to the Promise or the Future that is returned by the outbound method in terms of the ordering of execution of the listeners. Sometimes we add the listener to the promise while in reality we usually always want to add it to the future to ensure the listerns are executed in the "correct order".
- It is quite easy to "loose" a promise by forgetting to use the right method which also takes a promise
- We have no idea what EventExecutor is used for the passed in Promise which may invalid our assumption of threading.

While changing the method signature of the outbound operations of the ChannelHandler is a good step forward we should also take care of just remove all the methods from ChannelOutboundInvoker (and its sub-types) that take a Promise and just always use the methods that return a Future only.

Modifications:

- Change the signature of the methods that took a Promise to not take one anymore and just return a Future
- Remove all operations for ChannelOutboundInvoker that take a Promise.
- Adjust all code to cope with the API changes

Result:

Cleaner API which is easier to reason about and easier to use.
2021-08-25 14:12:33 +02:00
Chris Vest
b8e1341142
Future methods getNow() and cause() now throw on incomplete futures (#11594)
Motivation:
Since most futures in Netty are of the `Void` type, methods like `getNow()` and `cause()` cannot distinguish if the future has finished or not.
This can cause data race bugs which, in the case of `Void` futures, can be silent.

Modification:
The methods `getNow()` and `cause()` now throw an `IllegalStateException` if the future has not yet completed.
Most use of these methods are inside listeners, and so are not impacted.
One place in `AbstractBootstrap` was doing a racy read and has been adjusted.

Result:
Data race bugs around `getNow()` and `cause()` are no longer silent.
2021-08-24 15:47:27 +02:00
Norman Maurer
f0ffb6ac2e Fix compile error introduced by bad cherry-pick of 3c5b6c3e66 2021-08-20 19:02:09 +02:00
Norman Maurer
3c5b6c3e66 Allow server initiated renegotiate when using OpenSSL / BoringSSL based SSLEngine (#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 https://github.com/netty/netty/issues/11529
2021-08-20 18:52:43 +02:00
Chen Liu
ea5bc27c83 Always release the sslEngine inside SslHandler's handlerRemoved0 (#11605)
Motivation:
Make SslHandler's handlerRemoved0 method release the sslEngine
even if it fails in the middle.
See details in https://github.com/netty/netty/issues/11595.

Modifications:
Wrap the release of sslEngine into a finally block.

Result:
The sslEngine would be released eventually.

Co-authored-by: Chen Liu <cliu@splunk.com>
2021-08-20 18:51:24 +02:00
Norman Maurer
fb1face924 Only suppert TLSv1.3 when JDK does support it as well (#11604)
Motivation:

We tightly integrate the TrustManger and KeyManager into our native SSL implementation which means that both of them need to support TLSv1.3 as protocol. This is not always the case and so can produce runtime exceptions.

As TLSv1.3 support was backported to Java8 quite some time now we should be a bit more conservative and only enable TLSv1.3 for our native implementation if the JDK implementation supports it as well. This also allows us to remove some hacks we had in place to be able to support it before in Java8.

Modifications:

- Only enable TLSv1.3 support for our native SSL implementation when the JDK supports it as well
- Remove OpenSslTlsv13X509ExtendedTrustManager as its not needed anymore

Result:

Fixes https://github.com/netty/netty/issues/11589
2021-08-20 11:42:29 +02:00
Chris Vest
7971a252a5
Clean up Future/Promises API (#11575)
Motivation:
The generics for the existing futures, promises, and listeners are too complicated.
This complication comes from the existence of `ChannelPromise` and `ChannelFuture`, which forces listeners to care about the particular _type_ of future being listened on.

Modification:
* Add a `FutureContextListener` which can take a context object as an additional argument. This allows our listeners to have the channel piped through to them, so they don't need to rely on the `ChannelFuture.channel()` method.
* Make the `FutureListener`, along with the `FutureContextListener` sibling, the default listener API, retiring the `GenericFutureListener` since we no longer need to abstract over the type of the future.
* Change all uses of `ChannelPromise` to `Promise<Void>`.
* Change all uses of `ChannelFuture` to `Future<Void>`.
* Change all uses of `GenericFutureListener` to either `FutureListener` or `FutureContextListener` as needed.
* Remove `ChannelFutureListener` and `GenericFutureListener`.
* Introduce a `ChannelFutureListeners` enum to house the constants that previously lived in `ChannelFutureListener`. These constants now implement `FutureContextListener` and take the `Channel` as a context.
* Remove `ChannelPromise` and `ChannelFuture` — all usages now rely on the plain `Future` and `Promise` APIs.
* Add static factory methods to `DefaultPromise` that allow us to create promises that are initialised as successful or failed.
* Remove `CompleteFuture`, `SucceededFuture`, `FailedFuture`, `CompleteChannelFuture`, `SucceededChannelFuture`, and `FailedChannelFuture`.
* Remove `ChannelPromiseNotifier`.

Result:
Cleaner generics and more straight forward code.
2021-08-20 09:55:16 +02:00
Norman Maurer
afd812c3a4 Call OpenSsl.ensureAvailability() before trying to construct OpenSsl*Context (#11602)
Motivation:

At the moment why you try to build a SslContext via SslProvider.OPENSSL* and netty-tcnative* is not on the classpath it will fail with:

```
Exception in thread "main" java.lang.NoClassDefFoundError: io/netty/internal/tcnative/SSLPrivateKeyMethod
	at io.netty.handler.ssl.SslContext.newClientContextInternal(SslContext.java:830)
	at io.netty.handler.ssl.SslContextBuilder.build(SslContextBuilder.java:611)
	at io.netty.handler.codec.http.Main.main(Main.java:34)
Caused by: java.lang.ClassNotFoundException: io.netty.internal.tcnative.SSLPrivateKeyMethod
	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581)
	at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
	... 3 more
```

We should do better here.

Modifications:

Call `OpenSsl.ensureAvailability()` before trying to construct OpenSsl*Context instances

Result:

More clear error message like:

```
java.lang.UnsatisfiedLinkError: failed to load the required native library

	at io.netty.handler.ssl.OpenSsl.ensureAvailability(OpenSsl.java:540)
	at io.netty.handler.ssl.SslContext.newClientContextInternal(SslContext.java:830)
	at io.netty.handler.ssl.SslContextBuilder.build(SslContextBuilder.java:611)
        ...
Caused by: java.lang.ClassNotFoundException: io.netty.internal.tcnative.SSLContext
	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581)
	at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
	at java.base/java.lang.Class.forName0(Native Method)
	at java.base/java.lang.Class.forName(Class.java:398)
	at io.netty.handler.ssl.OpenSsl.<clinit>(OpenSsl.java:126)
	... 68 more
```
2021-08-19 20:56:17 +02:00
Norman Maurer
8549d7dc87 Add cast to help compiler to build (#11587)
Motivation:

Sometimes intellij fails to build because the compiler cant really figure out what to do. We can workaround this by adding some explicit casts.

Modifications:

Add explicits casts

Result:

No more problems with intellij
2021-08-18 09:43:03 +02:00
Norman Maurer
8083818b45 Ensure we only log message on BoringSSL when the ciphers really are not the default (#11583)
Motivation:

0c9a86db81 added a change to log a message if someone tried to change the TLSv1.3 ciphers when using BoringSSL. Unfortunally the code had some error and so even if the user did not change these we logged something.

Modifications:

- Ensure there are no duplicates in the ciphers
- Correctly take TLSv1.3 extra ciphers into account when using BoringSSL

Result:

Correctly log or not log
2021-08-16 22:26:55 +02:00
Aayush Atharva
ea8f6774d5 Simplify Bitwise operations (#11547)
Motivation:
We should keep bitwise operations simple and easy to understand.

Modification:
Simplify few Bitwise operations.

Result:
Less complicated bitwise operation code
2021-08-06 09:17:02 +02:00
Chris Vest
ef203fa6cb
Fix a number of javadoc issues (#11544)
Motivation:
Let's have fewer warnings about broken, missing, or abuse of javadoc comments.

Modification:
Added descriptions to throws clauses that were missing them.
Remove link clauses from throws clauses - these are implied.
Turned some javadoc comments into block comments because they were not applied to APIs.
Use code clauses instead of code tags.

Result:
Fewer javadoc crimes.
2021-08-06 09:14:04 +02:00
Aayush Atharva
b700793951 Remove Unused Imports (#11546)
Motivation:
There are lots of imports which are unused. We should get rid of them to make the code look better,

Modification:
Removed unused imports.

Result:
No unused imports.
2021-08-05 14:08:07 +02:00
Chris Vest
6b11f7fbc2
All *Bootstrap methods that used to return ChannelFuture now return Future<Channel> (#11517)
Bootstrap methods now return Future<Channel> instead of ChannelFuture

Motivation:
In #8516 it was proposed to at some point remove the specialised ChannelFuture and ChannelPromise.
Or at least make them not extend Future and Promise, respectively.
One pain point encountered in this discussion is the need to get access to the channel object after it has been initialised, but without waiting for the channel registration to propagate through the pipeline.

Modification:
Add a Bootstrap.createUnregistered method, which will return a Channel directly.
All other Bootstrap methods that previously returned ChannelFuture now return Future<Channel>

Result:
It's now possible to obtain an initialised but unregistered channel from a bootstrap, without blocking.
And the other bootstrap methods now only release their channels through the result of their futures, preventing racy access to the channels.
2021-08-03 19:43:38 +02:00
Chris Vest
4f0f889dbf Fix a bug with delegate/async SSL (#11537)
Motivation:
This bug could occasionally cause SSL handshakes to time out, because the server-side handshake would fail to resume its event loop.

Modification:
Async delegate SSL tasks now lower their NEED_TASK status after they have executed, but before they run their completion callback.
This is important because the completion callback could be querying the handshake status.
This could cause the task delegator thread and the event look to race.
If the event look queries the handshake status first, it might think that it still needs to delegate another task.
If this happens, the delegator find a null task, and then fail to resume the event loop, causing the handshake to stall.

Result:
This data race no longer causes handshake timeouts.
2021-08-03 10:14:41 +02:00
Norman Maurer
202aee34c4 Ensure we always wrap if there is something left to be send to the remote peer (#11535)
Motivation:

We need to ensure we call wrap as long as there is something left to be send to the remote peer in cases of non-application data (like for example alerts).

Modifications:

Check the pending data and based on it return NEED_WRAP even when the handshake was done.

Result:

Always produce alerts etc
2021-08-02 10:14:11 +02:00
Chris Vest
fc922c98d8
Remove overrides of Throwable.fillInStackTrace (#11514)
Motivation:
Since Java 7, there are new constructors available that allow us to avoid initialising the stack traces of certain exceptions.

Modification:
Use these constructors instead of overriding Throwable.fillInStackTrace.

Result:
Cleaner code
2021-07-27 13:29:09 +02:00
Norman Maurer
f645982a94 Remove ApplicationProtocolNegotiationHandler when no SslHandler is present (#11503)
Motivation:

750d235 did introduce a change in ApplicationProtocolNegotiationHandler that let the handler buffer all inbound data until the SSL handshake was completed. Due of this change a user might get buffer data forever if the SslHandler is not in the pipeline but the ApplicationProtocolNegotiationHandler was added. We should better guard the user against this "missconfiguration" of the ChannelPipeline.

Modifications:

- Remove the ApplicationProtocolNegotiationHandler when no SslHandler is present when the first message was received
- Add unit test

Result:

No possible that we buffer forever
2021-07-26 20:20:59 +02:00
Norman Maurer
0764e79d91 Disable mutual auth tests on windows for now (#11513)
Motivation:

We did observe that the mutal auth tests are flaky on windows when running on the CI. Let's disable these for now.

Modifications:

Disable mutual auth tests on windows

Result:

More stable build. Related to https://github.com/netty/netty/issues/11489
2021-07-26 14:10:57 +02:00
Aayush Atharva
6e5537f312 Fix JavaDoc of SelfSignedCertiticate regarding Private Key type (#11510)
Motivation:
SelfSignedCertificate generates EC/RSA key pair and this should be explicitly mentioned in JavaDoc. Currently, only "RSA" was mentioned not "EC".

Modification:
Changed RSA to EC/RSA

Result:
Correct JavaDoc
2021-07-26 08:32:17 +02:00
Norman Maurer
85eb96c68e
Use junit5 methods (#11508)
Motivation:

We missed to update one junit4 method usage to junit5

Modifications:

Use junit5 methods

Result:

No more usage of junit4
2021-07-26 08:28:32 +02:00
Norman Maurer
119f34889d Be able to build on JDK17 (#11500)
Motivation:

As the release of JDK17 is getting closer and there are ea builds already we should ensure we can actually build netty with it.

Modifications:

- Add profile for JDK17
- Remove test-code that would fail with JDK17 due the changes in 4f4d0f5366.

Result:

Be able to build and run testsuite with JDK17
2021-07-23 14:16:18 +02:00
Norman Maurer
23d8fde855 Add PromiseNotifier static method which takes care of cancel propagation (#11494)
Motivation:

At the moment we not correctly propagate cancellation in some case when we use the PromiseNotifier.

Modifications:

- Add PromiseNotifier static method which takes care of cancellation
- Add unit test
- Deprecate ChannelPromiseNotifier

Result:

Correctly propagate cancellation of operation

Co-authored-by: Nitesh Kant <nitesh_kant@apple.com>
2021-07-21 13:47:43 +02:00
Norman Maurer
23bf55206c Migrate the rest of the ssl package to junit5 (#11483)
Motivation:

We should use junit5 everywhere.

Modifications:

- Refactor rest of tests to use junit5

Result:

Part of https://github.com/netty/netty/issues/10757
2021-07-15 08:58:50 +02:00
Norman Maurer
d5ddd8b680 Disable flaky test for now (#11488)
Motivation:

JdkOpenSslEngineInteroptTest.testMutualAuthSameCerts() is flaky on the CI and so fails the PR build quite often.
Let's disable it for now until we were able to reproduce it locally and fix it.

Modifications:

Disable flaky test

Result:

More stable CI builds
2021-07-14 16:51:52 +02:00
Ikko Ashimine
980b6a0801 Fix typo in ReferenceCountedOpenSslEngine (#11467)
Motivation:

There should be no typos in comments

Modifications:
```
alway -> always
```

Result:

Fixed typo.
2021-07-08 16:30:13 +02:00
Norman Maurer
f8796c7eaf Introduce OpenSslAsyncPrivateKeyMethod which allows to asynchronously sign / decrypt the private key (#11390) (#11460)
Motivation:

At the moment we only support signing / decrypting the private key in a synchronous fashion. This is quite limited as we may want to do a network call to do so on a remote system for example.

Modifications:

- Update to latest netty-tcnative which supports running tasks in an asynchronous fashion.
- Add OpenSslAsyncPrivateKeyMethod interface
- Adjust SslHandler to be able to handle asynchronous task execution
- Adjust unit tests to test that asynchronous task execution works in all cases

Result:

Be able to asynchronous do key signing operations
2021-07-08 16:28:58 +02:00
Norman Maurer
6ac8ef54f7
Remove throws Exception from ChannelHandler methods that handle o… (#11417)
Motivation:

At the moment all methods in `ChannelHandler` declare `throws Exception` as part of their method signature. While this is fine for methods that handle inbound events it is quite confusing for methods that handle outbound events. This comes due the fact that these methods also take a `ChannelPromise` which actually need to be fullfilled to signal back either success or failure. Define `throws...` for these methods is confusing at best. We should just always require the implementation to use the passed in promise to signal back success or failure. Doing so also clears up semantics in general. Due the fact that we can't "forbid" throwing `RuntimeException` we still need to handle this in some way tho. In this case we should just consider it a "bug" and so log it and close the `Channel` in question. The user should never have an exception "escape" their implementation and just use the promise. This also clears up the ownership of the passed in message etc.

As `flush(ChannelHandlerContext)` and `read(ChannelHandlerContext)` don't take a `ChannelPromise` as argument this also means that these methods can never produce an error. This makes kind of sense as these really are just "signals" for the underlying transports to do something. For `RuntimeException` the same rule is used as for other outbound event handling methods, which is logging and closing the `Channel`.

Motifications:

- Remove `throws Exception` from signature
- Adjust code to not throw and just notify the promise directly
- Adjust unit tests

Result:

Much cleaner API and semantics.
2021-07-08 10:16:00 +02:00
Norman Maurer
54aa4d9b68 Only run one SSL task per delegation (#11462)
Motivation:

We should only run one SSL task per delegation to allow more SSLEngines to make progress in a timely manner

Modifications:

- Only run one task per delegation to the executor
- Only create new SSL task if really needed
- Only schedule if not on the EventExecutor thread

Result:

More fair usage of resources and less allocations
2021-07-08 08:06:07 +02:00
Aayush Atharva
04cb23626d Add SslProtocols and Cipher suites constants (#11457)
Motivation:
Protocols and Cipher suites constants to prevent typos in protocol and cipher suites names and ease of use.

Modification:
Added Protocols and Cipher suites as constants in their respective classes.

Result:
Fixes #11393
2021-07-07 21:20:58 +02:00
Norman Maurer
93d428eb23 Revert "Introduce OpenSslAsyncPrivateKeyMethod which allows to asynchronously sign / decrypt the private key (#11390)"
This reverts commit 2b9f4836be.
2021-07-07 08:27:31 +02:00
Norman Maurer
37d4b5a2f7 Call fireUserEventTriggered(...) before we try to modify the pipeline
Motivation:

We should call fireUserEventTriggered(...) before we try to modify the pipeline as otherwise we may end up in the situation that the handler was already removed.

Modifications:

Change ordering of calls

Result:

Test pass again
2021-07-06 16:43:27 +02:00
Nitesh Kant
c62eb26b09 ApplicationProtocolNegotiationHandler should drain buffer messages on channel close (#11445)
__Motivation__

`ApplicationProtocolNegotiationHandler` buffers messages which are read before SSL handshake complete event is received and drains them when the handler is removed. However, the channel may be closed (or input shutdown) before SSL handshake  event is received in which case we may fire channel read after channel closure (from `handlerRemoved()`).

__Modification__

Intercept `channelInactive()` and input closed event and drain the buffer.

__Result__

If channel is closed before SSL handshake complete event is received, we still maintain the order of message read and channel closure.

Co-authored-by: Norman Maurer <norman_maurer@apple.com>
2021-07-06 14:03:54 +02:00
Norman Maurer
2b9f4836be Introduce OpenSslAsyncPrivateKeyMethod which allows to asynchronously sign / decrypt the private key (#11390)
Motivation:

At the moment we only support signing / decrypting the private key in a synchronous fashion. This is quite limited as we may want to do a network call to do so on a remote system for example.

Modifications:

- Update to latest netty-tcnative which supports running tasks in an asynchronous fashion.
- Add OpenSslAsyncPrivateKeyMethod interface
- Adjust SslHandler to be able to handle asynchronous task execution
- Adjust unit tests to test that asynchronous task execution works in all cases

Result:

Be able to asynchronous do key signing operations
2021-07-06 09:59:15 +02:00
Norman Maurer
cb82277d36 Use Junit5 for handler module (#11444)
Motivation:

We should aim to use junit5 everywhere

Modifications:

Migrate most of the handler module to use junit5

Result:

Part of #10757
2021-07-02 17:43:13 +02:00
Aayush Atharva
7f690783d1 Add ALPN Buffering to support HTTP/2 Prior Knowledge (#11407)
Motivation:
Currently, Netty cannot handle HTTP/2 Preface messages if the client used the Prior knowledge technique. In Prior knowledge, the client sends an HTTP/2 preface message immediately after finishing TLS Handshake. But in Netty, when TLS Handshake is finished, ALPNHandler is triggered to configure the pipeline. And between these 2 operations, if an HTTP/2 preface message arrives, it gets dropped.

Modification:

Buffer messages until we are done with the ALPN handling.

Result:
Fixes #11403.

Co-authored-by: Norman Maurer <norman_maurer@apple.com>
2021-07-01 14:14:32 +02:00
wujimin
ea2654e9cc Add support for GMSSL (#11406) (#11410)
__Motivation__

Add support for GMSSL protocol to SslUtils.

__Modification__

Modify `SslUtils.getEncryptedPacketLength(ByteBuf buffer, int offset)` to get packet length when protocol is GMSSL.
Modify `SslUtils.getEncryptedPacketLength(ByteBuffer buffer)` to get packet length when protocol is GMSSL.

__Result__

`SslUtils.getEncryptedPacketLength` now supports GMSSL protocol. Fixes https://github.com/netty/netty/issues/11406
2021-07-01 08:17:58 +02:00
Unev
57765a7e57
ByteBufFormat constructor for LoggingHandler (#11420)
__Motivation__

`LoggingHandler` misses a constructor variant that only takes `ByteBufFormat`

__Modification__

Added the missing constructor variant.

__Result__

`LoggingHandler` can be constructed with `ByteBufFormat` only.

Co-authored-by: Nitesh Kant <nitesh_kant@apple.com>
2021-06-29 10:24:16 -07:00
Norman Maurer
0a3ffc59e3 Correctly use HandshakeStatus.NEED_WRAP when a handshake failed and a alert was produced (#11412)
Motivation:

We need to ensure we always "consumed" all alerts etc via SSLEngine.wrap(...) before we teardown the engine. Failing to do so may lead to a situation where the remote peer will not be able to see the actual cause of the handshake failure but just see the connection being closed.

Modifications:

Correctly return HandshakeStatus.NEED_WRAP when we need to wrap some data first before we shutdown the engine because of a handshake failure.

Result:

Fixes https://github.com/netty/netty/issues/11388
2021-06-24 10:06:02 +02:00
Norman Maurer
ec518878c3 Log if the user tries to explicit set TLSv1.3 ciphers and using BoringSSL (#11392)
Motivation:

At the moment BoringSSL doesnt support explicit set the TLSv1.3 ciphers that should be used. If TLSv1.3 should be used it just enables all ciphers. We should better log if the user tries to explicit set a specific ciphers and using BoringSSL to inform the user that what is tried doesnt really work.

Modifications:

Log if the user tries to not use all TLSv1.3 ciphers and use BoringSSL

Result:

Easier for the user to understand why always all TLSv1.3 ciphers are enabled when using BoringSSL

Co-authored-by: Trustin Lee <trustin@gmail.com>
2021-06-21 08:55:30 +02:00
Norman Maurer
07baabaac5
Remove Progressive*Promise / Progressive*Future (#11374)
Motivation:

This special case implementation of Promise / Future requires the implementations responsible for completing the promise to have knowledge of this class to provide value. It also requires that the implementations are able to provide intermediate status while the work is being done. Even throughout the core of Netty it is not really supported most of the times and so just brings more complexity without real gain.

Let's remove it completely which is better then only support it sometimes.

Modifications:

Remove Progressive* API

Result:

Code cleanup.... Fixes https://github.com/netty/netty/issues/8519
2021-06-09 08:32:38 +02:00