Commit Graph

1231 Commits

Author SHA1 Message Date
Norman Maurer
4f7e6d4841 Workaround possible JDK bug in SSLEngineImpl when using TLSv1.3 that lead to multiple notifications (#10860)
Motivation:

When using the JDKs SSLEngineImpl with TLSv1.3 it sometimes returns HandshakeResult.FINISHED multiple times. This can lead to have SslHandshakeCompletionEvents to be fired multiple times.

Modifications:

- Keep track of if we notified before and if so not do so again if we use TLSv1.3
- Add unit test

Result:

Consistent usage of events
2020-12-15 08:07:19 +01:00
terrarier2111
38e06ef7ae Removed redundant assignment (#10853)
Motivation:

Found a redundant assignment.

Modification:

Removed the redundant assignment.

Result:

Minor performance improvement.
2020-12-10 10:29:49 +01:00
Norman Maurer
6c446d14fd OpenSsl.memoryAddress(...) should use internalNioBuffer(...) if it can't access the memoryAddress (#10818)
Motivation:

We can make use of internalNioBuffer(...) if we cant access the memoryAddress. This at least will reduce the object creations.

Modifications:

Use internalNioBuffer(...) and so reduce the GC

Result:

Less object creation if we can't access the memory address.
2020-11-25 10:32:43 +01:00
Norman Maurer
eeece4cfa5 Use http in xmlns URIs to make maven release plugin happy again (#10788)
Motivation:

https in xmlns URIs does not work and will let the maven release plugin fail:

```
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  1.779 s
[INFO] Finished at: 2020-11-10T07:45:21Z
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-release-plugin:2.5.3:prepare (default-cli) on project netty-parent: Execution default-cli of goal org.apache.maven.plugins:maven-release-plugin:2.5.3:prepare failed: The namespace xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" could not be added as a namespace to "project": The namespace prefix "xsi" collides with an additional namespace declared by the element -> [Help 1]
[ERROR]
```

See also https://issues.apache.org/jira/browse/HBASE-24014.

Modifications:

Use http for xmlns

Result:

Be able to use maven release plugin
2020-11-10 10:51:05 +01:00
Norman Maurer
70cbe74367 Use special exception when failing because the SSLEngine was closed (#10783)
Motivation:

Sometimes it would be helpful to easily detect if an operation failed due the SSLEngine already be closed.

Modifications:

Add special exception that is used when the engine was closed

Result:

Easier to detect a failure caused by a closed exception
2020-11-09 15:33:34 +01:00
Artem Smotrakov
51db4c9a9f Better hash algorithm in FingerprintTrustManagerFactory (#10683)
Motivation:

FingerprintTrustManagerFactory can only use SHA-1 that is considered
insecure.

Modifications:

- Updated FingerprintTrustManagerFactory to accept a stronger hash algorithm.
- Remove the constructors that still use SHA-1.
- Added a test for FingerprintTrustManagerFactory.

Result:

A user can now configure FingerprintTrustManagerFactory to use a
stronger hash algorithm.

Co-authored-by: Norman Maurer <norman_maurer@apple.com>
2020-10-26 14:37:33 +01:00
Artem Smotrakov
b8ae2a2af4 Enable nohttp check during the build (#10708)
Motivation:

HTTP is a plaintext protocol which means that someone may be able
to eavesdrop the data. To prevent this, HTTPS should be used whenever
possible. However, maintaining using https:// in all URLs may be
difficult. The nohttp tool can help here. The tool scans all the files
in a repository and reports where http:// is used.

Modifications:

- Added nohttp (via checkstyle) into the build process.
- Suppressed findings for the websites
  that don't support HTTPS or that are not reachable

Result:

- Prevent using HTTP in the future.
- Encourage users to use HTTPS when they follow the links they found in
  the code.
2020-10-23 15:26:25 +02:00
Norman Maurer
c061bd1798
Ensure SniCompletionEvent is not lost after onLookupComplete(...) (#10709)
Motivation:

In the master branch we fail fire* operations on the ChannelHandlerContext once the handler was removed. This is by design as it is "unspecified" what the semantics could be after the handler was removed and may lead to very hard to debug problems. Because of this we need to select the right ChannelHandlerContext for firing the event.

Modifications:

Choose a valid ChannelHandlerContext based on the state of the context of the handler

Result:

No more test failures
2020-10-20 09:01:15 +02:00
Norman Maurer
3f2c5ccd46 Replace deprecated Assert.assertThat(...) with MatcherAssert.assertThat(...) (#10699)
Motivation:

junit deprecated Assert.assertThat(...)

Modifications:

Use MatcherAssert.assertThat(...) as replacement for deprecated method

Result:

Less deprecation warnings
2020-10-18 14:55:21 +02:00
Aayush Atharva
87719f4fd9 Add null rule check in rules array of RuleBasedIpFilter (#10527)
Motivation:

We can filter out `null` rules while initializing the instance of `RuleBasedIpFilter` so we don't have to keep checking for `null` rules while iterating through `rules` array in `for loop` which is just a waste of CPU cycles.

Modification:
Added `null` rule check inside the constructor.

Result:
No more wasting CPU cycles on check the `null` rule each time in `for loop` and makes the overall operation more faster.
2020-10-17 20:23:52 +02:00
Artem Smotrakov
f0448d6a8a Fix or suppress LGTM findings (#10689)
Motivation:

LGTM reports multiple issues. They need to be triaged,
and real ones should be fixed.

Modifications:
- Fixed multiple issues reported by LGTM, such as redundant conditions,
  resource leaks, typos, possible integer overflows.
- Suppressed false-positives.
- Added a few testcases.

Result:

Fixed several possible issues, get rid of false alarms in the LGTM report.
2020-10-17 09:57:52 +02:00
Norman Maurer
647dbe0244 Fire SniCompletionEvent after onLookupComplete(...) was called (#10688)
Motivation:

Users may want to do special actions when onComplete(...) was called and depend on these once they receive the SniCompletionEvent

Modifications:

Switch order and so call onLookupComplete(...) before we fire the event

Result:

Fixes https://github.com/netty/netty/issues/10655
2020-10-15 21:01:18 +02:00
Chris Vest
6201c6d80f
Add a build profile for JDK 16 (#10675)
Motivation:
Java 16 will come around eventually anyway, and this makes it easier for people to experiment with Early Access builds.

Modification:
- Added Maven profiles for JDK 16 to relevant pom files.
- Removed the `--add-exports java.base/sun.security.x509=ALL-UNNAMED` argument when running tests; we've not needed it since the Java11-as-baseline PR landed.

Result:
Netty now builds on JDK 16 pre-releases (provided they've not broken compatibility in some way).
2020-10-12 16:42:40 +02:00
Chris Vest
a179db8066
Raise the Netty 5 minimum required Java version to Java 11. (#10650)
Raise the Netty 5 minimum required Java version to Java 11.

Motivation:
Java 11 has been out for some time, and Netty 5 is still some ways out.
There are also many good features in Java 11 that we wish to use, such as VarHandles, var-keyword, and the module system.
There is no reason for Netty 5 to not require Java 11, since Netty 4.x will still be supported for the time being.

Modification:
Remove everything in the pom files related to Java versions older than Java 11.
Remove the animal-sniffer plug-in and rely on the `--release` compiler flag instead.
Remove docker files related to Java versions older than Java 11.
Remove the copied SCTP APIs -- we should test this commit independently on Windows.
Remove the OpenJdkSelfSignedCertGenerator.java file and just always use Bouncy Castle for generating self-signed certificates for testing.
Make netty-testsuite tests pass by including Bouncy Castle as a test dependency, so we're able to generate our self-signed certificate.

Result:
Java 11 is now the minimum required Java version.
2020-10-12 14:13:01 +02:00
Aayush Atharva
09dc15aaa0 Add Close method for closing OutputStream and PcapWriteHandler (#10638)
Motivation:
We should implement the Closeable method to properly close `OutputStream` and `PcapWriteHandler`. So whenever `handlerRemoved(ChannelHandlerContext)` is called or the user wants to stop the Pcap writes into `OutputStream`, we have a proper method to close it otherwise writing data to close `OutputStream` will result in `IOException`.

Modification:
Implemented `Closeable` in `PcapWriteHandler` which calls `PcapWriter#close` and closes `OutputStream` and stops Pcap writes.

Result:
Better handling of Pcap writes.
2020-10-08 11:53:13 +02:00
Chris Vest
86c8f24d9a
Replace UNSAFE.throwException with alternatives supported on Java 8 (#10629)
Motivation:
 We wish to use Unsafe as little as possible, and Java 8 allows us
 to take some short-cuts or play some tricks with generics,
 for the purpose of working around having to declare all checked
 exceptions. Ideally all checked exceptions would be declared, but
 the code base is not ready for that yet.

Modification:
 The call to UNSAFE.throwException has been removed, so when we need
 that feature, we instead use the generic exception trick.
 In may cases, Java 8 allows us to throw Throwable directly. This
 happens in cases where no exception is declared to be thrown in a
 scope.
 Finally, some warnings have also been fixed, and some imports have
 been reorganised and cleaned up while I was modifying the files
 anyway.

Result:
 We no longer use Unsafe for throwing any exceptions.
2020-10-02 08:29:07 +02:00
Norman Maurer
ba43065482 Respect the Provider when detecting if TLSv1.3 is used by default / supported (#10621)
Motivation:

We need to take the Provider into account as well when trying to detect if TLSv1.3 is used by default / supported

Modifications:

- Change utility method to respect provider as well
- Change testcode

Result:

Less error-prone tests
2020-09-29 20:49:11 +02:00
Norman Maurer
d77edcb6e2 Use SelfSignedCertificate to fix test-failure related to small key size (#10620)
Motivation:

Some JDKs dissallow the usage of keysizes < 2048, so we should not use such small keysizes in tests.

This showed up on fedora 32:

```
Caused by: java.security.cert.CertPathValidatorException: Algorithm constraints check failed on keysize limits. RSA 1024bit key used with certificate: CN=tlsclient.  Usage was tls client
        at sun.security.util.DisabledAlgorithmConstraints$KeySizeConstraint.permits(DisabledAlgorithmConstraints.java:817)
        at sun.security.util.DisabledAlgorithmConstraints$Constraints.permits(DisabledAlgorithmConstraints.java:419)
        at sun.security.util.DisabledAlgorithmConstraints.permits(DisabledAlgorithmConstraints.java:167)
        at sun.security.provider.certpath.AlgorithmChecker.check(AlgorithmChecker.java:326)
        at sun.security.provider.certpath.PKIXMasterCertPathValidator.validate(PKIXMasterCertPathValidator.java:125)
        ... 23 more
```

Modifications:

Replace hardcoded keys / certs with SelfSignedCertificate

Result:

No test-failures related to small key sizes anymore.
2020-09-29 13:06:54 +02:00
Norman Maurer
fc656f605f Only set the keymaterial once and correctly handle errors during keymaterial setting on the client-side as well (#10613)
Motivation:

We should stop as soon as we were able to set the key material on the server side as otherwise we may select keymaterial that "belongs" to a less prefered cipher. Beside this it also is just useless work.
We also need to propagate the exception when it happens during key material selection on the client side so openssl will produce the right alert.

Modifications:

- Stop once we were able to select a key material on the server side
- Ensure we not call choose*Alias more often then needed
- Propagate exceptions during selection of the keymaterial on the client side.

Result:

Less overhead and more correct behaviour
2020-09-29 09:28:25 +02:00
Norman Maurer
ced5faa440 Correctly report back when we fail to select the key material and ens… (#10610)
Motivation:

We need to let openssl know that we failed to find the key material so it will produce an alert for the remote peer to consume. Beside this we also need to ensure we wrap(...) until we produced everything as otherwise the remote peer may see partial data when an alert is produced in multiple steps.

Modifications:

- Correctly throw if we could not find the keymaterial
- wrap until we produced everything
- Add test

Result:

Correctly handle the case when key material could not be found
2020-09-29 09:21:35 +02:00
Norman Maurer
d92d92a923 Filter out duplicates before trying to find the alias to use (#10612)
Motivation:

Calling chooseServerAlias(...) may be expensive so we should ensure we not call it multiple times for the same auth methods.

Modifications:

Remove duplicated from authMethods before trying to call chooseServerAlias(...)

Result:

Less performance overhead during key material selection
2020-09-25 19:13:33 +02:00
Yosfik Alqadri
c9e42106d1 Fix Javadoc Typo (#10603)
Motivation:

Following Javadoc standard

Modification:

Change from `@param KeyManager` to `@param keyManager`

Result:

The `@param` matches the actual parameter variable name
2020-09-24 15:28:30 +02:00
Aayush Atharva
379be5085f Add PcapWriteHandler Support (#10498)
Motivation:
Write TCP and UDP packets into Pcap `OutputStream` which helps a lot in debugging.

Modification:
Added TCP and UDP Pcap writer.

Result:
New handler can write packets into an `OutputStream`, e.g. a file that can be opened with Wireshark.

Fixes #10385.
2020-09-11 16:15:39 +02:00
Norman Maurer
338b7ce314 Revert "Support session cache for client and server when using native SSLEngine implementation (#10331)"
Motivation:

This reverts commit 7bf1ffb2d4 as it turns out it introduced a big performance regression.

Modifications:

Revert 7bf1ffb2d4

Result:

Performance of TLS is back to normal
2020-09-03 08:33:22 +02:00
Aayush Atharva
a49afaef35 Binary search based IpSubnetFilter (#10492)
Motivation:

`IpSubnetFilter` uses Binary Search for IP Address search which is fast if we have large set of IP addresses to filter.

Modification:

Added `IpSubnetFilter` which takes `IpSubnetFilterRule` for filtering.

Result:
Faster IP address filter.
2020-09-01 11:15:19 +02:00
Aayush Atharva
890c261759 Fix JavaDoc of RuleBasedIpFilter (#10521)
Motivation:

`RuleBasedIpFilter` had JavaDoc `{@link #channelRejected(ChannelHandlerContext, SocketAddress)}` instead of `{@link AbstractRemoteAddressFilter#channelRejected(ChannelHandlerContext, SocketAddress)}`.

Modification:
Added `AbstractRemoteAddressFilter` reference.

Result:
Fixed JavaDoc error and made documentation more clear.
2020-09-01 11:02:52 +02:00
Michael Nitschinger
571e61ab36 Allow to customize how SslMasterKeyHandler is enabled (#10513)
Motivation:

Right now after a SslMasterKeyHandler is added to the pipeline,
it also needs to be enabled via a system property explicitly. In
some environments where the handler is conditionally added to
the pipeline this is redundant and a bit confusing.

Modifications:

This changeset keeps the default behavior, but allows child
implementations to tweak the way on how it detects that it
should actually handle the event when it is being raised.

Also, removed a private static that is not used in the wireshark
handler.

Result:

Child implementations can be more flexible in deciding when
and how the handler should perform its work (without changing
any of the defaults).
2020-08-31 10:35:06 +02:00
Norman Maurer
514d349e1f Enable SSL_MODE_ENABLE_FALSE_START if jdkCompatibilityMode is false (#10407)
Motivation:

To reduce latency and RTTs we should use TLS False Start when jdkCompatibilityMode is not required and its supported

Modifications:

Use SSL_MODE_ENABLE_FALSE_START when jdkCompatibilityMode is false

Result:

Less RTTs and so lower latency when TLS False Start is supported
2020-08-18 19:01:09 +02:00
Norman Maurer
ccca21015b Cleanup Conscrypt initialization (#10466)
Motivation:

How we init our static fields in Conscrypt was kind of error-prone and may even lead to NPE later on when methods were invoked out of order.

Modifications:

- Move all the init code to a static block
- Remove static field which is not needed anymore

Result:

Cleanup and also fixes https://github.com/netty/netty/issues/10413
2020-08-11 21:08:17 +02:00
Norman Maurer
6aa30b2b6e
Fix invokeExact(...) usage in JdkAlpnSslUtils (#10471)
Motivation:

fd0d06e introduced the usage of MethodHandles and so also introduced some usages of invokeExact(...). Unfortunally when calling this method we missed to also cast the return value in the static init block of JdkAlpnSslUtils which lead to an exception to be thrown as the JVM did assume the return value is void which is not true.

Modifications:

Correctly cast the return value of invokeExact(...)

Result:

ALPN can be used in master with JDK again
2020-08-11 16:04:15 +02:00
Norman Maurer
1208f27070 Revert #10326 due regression in FlowControlHandler
Motivation:

This reverts commit b559711f3e due regression introduced by it.

Modification:

Revert commit

Result:

Fixes https://github.com/netty/netty/issues/10464
2020-08-11 09:08:13 +02:00
Norman Maurer
43ae49ed78 Enable TLS1.3 by default of JDK SSLEngine implementation does by default (#10451)
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>
2020-08-10 14:04:29 +02:00
Norman Maurer
a2ebd65322 Fix compilation error on JDK 15 (#10462)
Motivation:

AlgorithmId.sha256WithRSAEncryption_oid was removed in JDK15 and later so we should not depend on it as otherwise we will see compilation errors

Modifications:

Replace AlgorithmId.sha256WithRSAEncryption_oid usage with specify the OID directly

Result:

Compiles on JDK15+
2020-08-10 14:03:43 +02:00
skyguard1
9c5dbfd1b6 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
2020-08-06 09:03:01 +02:00
Norman Maurer
220995f155 Make the TLSv1.3 check more robust and not depend on the Java version… (#10409)
Motivation:

TLSv1.3 is not strictly limited to Java11+ anymore as different vendors backported TLSv1.3 to Java8 as well. We should ensure we make the detection of if TLSv1.3 is supported not depend on the Java version that is used.

Modifications:

- Add SslProvider.isTlsv13Supported(...) and use it in tests to detect if we should run tests against TLSv1.3 as well
- Adjust testcase to work on latest JDK 8 release as well

Result:

Correct detection of TLSv1.3 support even if Java version < 11.
2020-07-17 07:17:56 +02:00
Norman Maurer
7bf1ffb2d4 Support session cache for client and server when using native SSLEngine implementation (#10331)
Motivation:

At the moment we don't support session caching for client side when using native SSLEngine implementation and our implementation of SSLSessionContext is incomplete.

Modification:

- Consume netty-tcnative changes to be able to cache session in an external cache
- Add and adjust unit tests to test session caching
- Add an in memory session cache that is hooked into native SSLEngine

Result:

Support session caching on the client and server side
2020-07-14 15:20:44 +02:00
Norman Maurer
47bbc590ee jdk.tls.client.enableSessionTicketExtension must be respected by OPENSSL and OPENSSL_REFCNT SslProviders (#10401)
Motivation:

jdk.tls.client.enableSessionTicketExtension property must be respect by OPENSSL and OPENSSL_REFCNT SslProvider to ensure a consistent behavior. Due a bug this was not the case and it only worked for OPENSSL_REFCNT but not for OPENSSL.

Modifications:

Move the property check into static method that is used by both

Result:

Correctly respect jdk.tls.client.enableSessionTicketExtension
2020-07-13 16:17:41 +02:00
Norman Maurer
165ade5d9f Correctly return NEED_WRAP if we produced some data even if we could not consume any during SSLEngine.wrap(...) (#10396)
Motivation:

At the moment we may report BUFFER_OVERFLOW when wrap(...) fails to consume data but still prodce some. This is not correct and we should better report NEED_WRAP as we already have produced some data (for example tickets). This way the user will try again without increasing the buffer size which is more correct and may reduce the number of allocations

Modifications:

Return NEED_WRAP when we produced some data but not consumed any.

Result:

Fix ReferenceCountedOpenSslEngine.wrap(...) state machine
2020-07-09 08:52:30 +02:00
Daniel Zou
fca62510f3 Modify OpenSSL native library loading to accommodate GraalVM (#10395)
**Motivation:**

We are interested in building Netty libraries with Ahead-of-time compilation with GraalVM. We saw there was [prior work done on this](https://github.com/netty/netty/search?q=graalvm&unscoped_q=graalvm). We want to introduce a change which will unblock GraalVM support for applications using netty and `netty-tcnative`.

This solves the error [that some others encounter](https://github.com/oracle/graal/search?q=UnsatisfiedLinkError+sslOpCipherServerPreference&type=Issues):

```
Exception in thread "main" java.lang.UnsatisfiedLinkError: io.grpc.netty.shaded.io.netty.internal.tcnative.NativeStaticallyReferencedJniMethods.sslOpCipherServerPreference()I [symbol: Java_io_grpc_netty_shaded_io_netty_internal_tcnative_NativeStaticallyReferencedJniMethods_sslOpCipherServerPreference or Java_io_grpc_netty_shaded_io_netty_internal_tcnative_NativeStaticallyReferencedJniMethods_sslOpCipherServerPreference__]
```

**Modification:**

The root cause of the issue is that in the tcnative libraries, the [`SSL.java` class](783a8b6b69/openssl-dynamic/src/main/java/io/netty/internal/tcnative/SSL.java (L67)) references a native call in the static initialization of the class - the method `sslOpCipherServerPreference()` on line 67 is used to initialize the static variable. But you see that `OpenSsl` also uses[ `SSL.class` to check if `netty-tcnative` is on the classpath before loading the native library](cbe238a95b/handler/src/main/java/io/netty/handler/ssl/OpenSsl.java (L123)). 

So this is the problem because in ahead-of-time compilation, when it references the SSL class, it will try to load those static initializers and make the native library call, but it cannot do so because the native library has not been loaded yet since the `SSL` class is being referenced to check if the library should be loaded in the first place.

**Solution:** So the proposed solution here is to just choose a different class in the `tcnative` package which does not make a native library call during static initialization. I just chose `SSLContext` if this is OK.

This should have no negative effects other than unblocking the GraalVM use-case.

**Result:**

It fixes the unsatisfied link error. It will fix error for future users; it is a common error people encounter.
2020-07-08 10:47:10 +02:00
Norman Maurer
0c79863db5 Update to netty-tcnative 2.0.31.Final and make SslErrorTest more robust (#10392)
Motivation:

There was a new netty-tcnative release which we should use. Beside this the SSLErrorTest was quite fragile and so should be adjusted.

Modifications:

Update netty-tcnative and adjust test

Result:

Use latest netty-tcnative release
2020-07-07 10:56:42 +02:00
Norman Maurer
8950144567 Correctly include TLS1.3 ciphers in the enabled ciphersuites when using BoringSSL (#10388)
Motivation:

BoringSSL behaves differently then OpenSSL and not include any TLS1.3 ciphers in the returned array when calling SSL_get_ciphers(...). This is due the fact that it also not allow to explicit configure which are supported and which not for TLS1.3. To mimic the behaviour expected by the SSLEngine API we should workaround this.

Modifications:

- Add a unit test that verifies enabled protocols / ciphers
- Add special handling for BoringSSL and tls1.3

Result:

Make behaviour consistent
2020-07-02 21:37:04 +02:00
Norman Maurer
91c75a4a8f Ensure we preserve the original cause of the SSLException in all case… (#10372)
Motivation:

We did not correctly preserve the original cause of the SSLException when all the following are true:

 * SSL_read failed
 * handshake was finished
 * some outbound data was produced durigin SSL_read (for example ssl alert) that needs to be picked up by wrap(...)

Modifications:

Ensure we correctly preserve the original cause of the SSLException and rethrow it once we produced all data via wrap(...)

Result:

Be able to understand why we see an error in all cases
2020-06-25 22:08:57 +02:00
Norman Maurer
b2726c4919 X509TrustManager with OPENSSL provider is not wrapped with hostname verification if Conscrypt is inserted in the first place (#10375)
Motivation:

Modifications:

Directly specify the provider which is used to create the SSLContext

Result:

Fixes https://github.com/netty/netty/issues/10374
2020-06-25 20:40:49 +02:00
Norman Maurer
163c2fc220 Ensure we feed all data to the SSLEngine during handshaking in our tests (#10373)
Motivation:

Due a bug in our test we may dropped data on the floor which are generated during handshaking (or slightly after). This could lead to corrupt state in the engine itself and so fail tests. This is especially true for TLS1.3 which generates the sessions on the server after the "actual handshake" is done.

Modifications:

Contine with wrap / unwrap until all data was consumed

Result:

Correctly feed all data to the engine during testing
2020-06-25 14:56:54 +02:00
Norman Maurer
f051b0c297 Ensure ApplicationProtocolNegotiationHandler does handle handshake fa… (#10363)
Motivation:

When ApplicationProtocolNegotiationHandler is in the pipeline we should expect that its handshakeFailure(...) method will be able to completly handle the handshake error. At the moment this is not the case as it only handled SslHandshakeCompletionEvent but not the exceptionCaught(...) that is also triggered in this case

Modifications:

- Call handshakeFailure(...) in exceptionCaught and so fix double notification.
- Add testcases

Result:

Fixes https://github.com/netty/netty/issues/10342
2020-06-24 08:47:31 +02:00
Norman Maurer
e76fc0a577 Fix compilation error in test due bad cherry-pick
Motivation:

I did not correctly adjust the code before cherry-pick, causing a compilation error in the test

Modifications:

Use ChannelHandler

Result:

No more compilation error
2020-06-12 11:21:47 +02:00
Kareem Ali
121daab927 Motivation: (#10326)
The current FLowControlHandler keeps a flag to track whether a read() call is pending.
This could lead to a scenario where you call read multiple times when the queue is empty,
and when the FlowControlHandler Queue starts getting messages, channelRead will be fired only once,
when we should've fired x many times, once for each time the handlers downstream called read().

Modifications:

Minor change to replace the boolean flag with a counter and adding a unit test for this scenario.

Result:

I used TDD, so I wrote the test, made sure it's failing, then updated the code and re-ran the test
to make sure it's successful after the changes.

Co-authored-by: Kareem Ali <kali@localhost.localdomain>
2020-06-04 19:18:23 +02:00
Norman Maurer
feeb3ee920 Update test to directly check for SslHandshakeTimeoutException (#10339)
Motivation:

9b7e091 added a special SSLHandshakeException sub-class to signal handshake timeouts but we missed to update a testcase to directly assert the type of the exception.

Modifications:

Assert directly that SslHandshakeTimeoutException is used

Result:

Test cleanup
2020-06-04 18:30:25 +02:00
feijermu
8bbd89d72a Fix a test case problem: testSwallowedReadComplete(...) may fail with an AssertionError sometimes. (#10313)
Motivation:

It seems that `testSwallowedReadComplete(...)` may fail with an AssertionError sometimes after my tests. The relevant stack trace is as follows:

```
java.lang.AssertionError: expected:<IdleStateEvent(READER_IDLE, first)> but was:<null>
	at org.junit.Assert.fail(Assert.java:88)
	at org.junit.Assert.failNotEquals(Assert.java:834)
	at org.junit.Assert.assertEquals(Assert.java:118)
	at org.junit.Assert.assertEquals(Assert.java:144)
	at io.netty.handler.flow.FlowControlHandlerTest.testSwallowedReadComplete(FlowControlHandlerTest.java:478)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:89)
	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:41)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:542)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:770)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:464)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:210)

```
Obviously the `readerIdleTime` of `IdleStateHandler` and the thread sleep time before `EmbeddedChannel.runPendingTasks` are both 100ms. And if `userEvents.poll()` happened before `userEvents.add(...)` or no `IdleStateEvent` fired at all, this test case would fail.

Modification:

Sleep for a little more time before running all pending tasks in the `EmbeddedChannel`.

Result:

Fix the problem of small probability of failure.
2020-06-03 09:19:54 +02:00
Scott Mitchell
32a77394a3 SslHandler#wrap to preserve exception if SSLEngine is closed (#10327)
Motivation:
SslHandler currently throws a general SSLException if a wrap attempt
fails due to the SSLEngine being closed. If writes are queued the
failure rational typically requires more investigation to track down the
original failure from a previous event. We may have more informative
rational for the failure and so we should use it.

Modifications:
- SslHandler#wrap to use failure information from the handshake or prior
transport closure if available

Result:
More informative exceptions from SslHandler#wrap if the SSLEngine has
been previously closed.
2020-06-02 09:51:43 +02:00