andreacavalli
/
netty5
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
netty5/handler/src/main/java/io/netty/handler/ssl/OpenSsl.java

593 lines
27 KiB
Java
Raw Normal View History

Add an OpenSslEngine and the universal API for enabling SSL Motivation: Some users already use an SSLEngine implementation in finagle-native. It wraps OpenSSL to get higher SSL performance. However, to take advantage of it, finagle-native must be compiled manually, and it means we cannot pull it in as a dependency and thus we cannot test our SslHandler against the OpenSSL-based SSLEngine. For an instance, we had #2216. Because the construction procedures of JDK SSLEngine and OpenSslEngine are very different from each other, we also need to provide a universal way to enable SSL in a Netty application. Modifications: - Pull netty-tcnative in as an optional dependency. http://netty.io/wiki/forked-tomcat-native.html - Backport NativeLibraryLoader from 4.0 - Move OpenSSL-based SSLEngine implementation into our code base. - Copied from finagle-native; originally written by @jpinner et al. - Overall cleanup by @trustin. - Run all SslHandler tests with both default SSLEngine and OpenSslEngine - Add a unified API for creating an SSL context - SslContext allows you to create a new SSLEngine or a new SslHandler with your PKCS#8 key and X.509 certificate chain. - Add JdkSslContext and its subclasses - Add OpenSslServerContext - Add ApplicationProtocolSelector to ensure the future support for NPN (NextProtoNego) and ALPN (Application Layer Protocol Negotiation) on the client-side. - Add SimpleTrustManagerFactory to help a user write a TrustManagerFactory easily, which should be useful for those who need to write an alternative verification mechanism. For example, we can use it to implement an unsafe TrustManagerFactory that accepts self-signed certificates for testing purposes. - Add InsecureTrustManagerFactory and FingerprintTrustManager for quick and dirty testing - Add SelfSignedCertificate class which generates a self-signed X.509 certificate very easily. - Update all our examples to use SslContext.newClient/ServerContext() - SslHandler now logs the chosen cipher suite when handshake is finished. Result: - Cleaner unified API for configuring an SSL client and an SSL server regardless of its internal implementation. - When native libraries are available, OpenSSL-based SSLEngine implementation is selected automatically to take advantage of its performance benefit. - Examples take advantage of this modification and thus are cleaner.
2014-05-17 19:26:01 +02:00
/*
* Copyright 2014 The Netty Project
*
* The Netty Project licenses this file to you under the Apache License,
* version 2.0 (the "License"); you may not use this file except in compliance
* with the License. You may obtain a copy of the License at:
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
* WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
* License for the specific language governing permissions and limitations
* under the License.
*/
package io.netty.handler.ssl;
[#4828] OpenSslContext throws UnsupportedOperationException when Unsafe not available Motivation: OpenSslContext constructor fails with a UnsupportedOperationException if Unsafe is not present on the system. Modifications: Make OpenSslContext work also when Unsafe is not present by fallback to using JNI to get the memory address. Result: Using OpenSslContext also works on systems without Unsafe.
2016-02-03 20:50:57 +01:00
import io.netty.buffer.ByteBuf;
Use ByteBufAllocator used by the ReferenceCountedOpenSslEngine when build key-material. (#7952) Motivation: When we build the key-material we should use the ByteBufAllocator used by the ReferenceCountedOpenSslEngine when possible. Modifications: Whenever we have access to the ReferenceCountedOpenSslEngine we use its allocator. Result: Use correct allocator
2018-05-18 19:36:57 +02:00
import io.netty.buffer.ByteBufAllocator;
Use SSL.setKeyMaterial(...) to test if the KeyManagerFactory is supported (#8985) Motivation: We use SSL.setKeyMaterial(...) in our implementation when using the KeyManagerFactory so we should also use it to detect if we can support KeyManagerFactory. Modifications: Use SSL.setKeyMaterial(...) as replacement for SSL.setCertificateBio(...) Result: Use the same method call to detect if KeyManagerFactory can be supported as we use in the real implementation.
2019-04-01 12:03:05 +02:00
import io.netty.buffer.UnpooledByteBufAllocator;
Unify default cipher suites betweek JDK and OpenSSL Motivation: Currently the default cipher suites are set independently between JDK and OpenSSL. We should use a common approach to setting the default ciphers. Also the OpenSsl default ciphers are expressed in terms of the OpenSSL cipher name conventions, which is not correct and may be exposed to the end user. OpenSSL should also use the RFC cipher names like the JDK defaults. Modifications: - Move the default cipher definition to a common location and use it in JDK and OpenSSL initialization - OpenSSL should not expose OpenSSL cipher names externally Result: Common initialization and OpenSSL doesn't expose custom cipher names.
2017-07-12 21:53:39 +02:00
import io.netty.internal.tcnative.Buffer;
import io.netty.internal.tcnative.Library;
import io.netty.internal.tcnative.SSL;
import io.netty.internal.tcnative.SSLContext;
Ensure we only call ReferenceCountUtil.safeRelease(...) in finalize() if the refCnt() > 0 Motivation: We need to ensure we only call ReferenceCountUtil.safeRelease(...) in finalize() if the refCnt() > 0 as otherwise we will log a message about IllegalReferenceCountException. Modification: Check for a refCnt() > 0 before try to release Result: No more IllegalReferenceCountException produced when run finalize() on OpenSsl* objects that where explicit released before.
2016-08-09 18:14:22 +02:00
import io.netty.util.ReferenceCountUtil;
import io.netty.util.ReferenceCounted;
Add an OpenSslEngine and the universal API for enabling SSL Motivation: Some users already use an SSLEngine implementation in finagle-native. It wraps OpenSSL to get higher SSL performance. However, to take advantage of it, finagle-native must be compiled manually, and it means we cannot pull it in as a dependency and thus we cannot test our SslHandler against the OpenSSL-based SSLEngine. For an instance, we had #2216. Because the construction procedures of JDK SSLEngine and OpenSslEngine are very different from each other, we also need to provide a universal way to enable SSL in a Netty application. Modifications: - Pull netty-tcnative in as an optional dependency. http://netty.io/wiki/forked-tomcat-native.html - Backport NativeLibraryLoader from 4.0 - Move OpenSSL-based SSLEngine implementation into our code base. - Copied from finagle-native; originally written by @jpinner et al. - Overall cleanup by @trustin. - Run all SslHandler tests with both default SSLEngine and OpenSslEngine - Add a unified API for creating an SSL context - SslContext allows you to create a new SSLEngine or a new SslHandler with your PKCS#8 key and X.509 certificate chain. - Add JdkSslContext and its subclasses - Add OpenSslServerContext - Add ApplicationProtocolSelector to ensure the future support for NPN (NextProtoNego) and ALPN (Application Layer Protocol Negotiation) on the client-side. - Add SimpleTrustManagerFactory to help a user write a TrustManagerFactory easily, which should be useful for those who need to write an alternative verification mechanism. For example, we can use it to implement an unsafe TrustManagerFactory that accepts self-signed certificates for testing purposes. - Add InsecureTrustManagerFactory and FingerprintTrustManager for quick and dirty testing - Add SelfSignedCertificate class which generates a self-signed X.509 certificate very easily. - Update all our examples to use SslContext.newClient/ServerContext() - SslHandler now logs the chosen cipher suite when handshake is finished. Result: - Cleaner unified API for configuring an SSL client and an SSL server regardless of its internal implementation. - When native libraries are available, OpenSSL-based SSLEngine implementation is selected automatically to take advantage of its performance benefit. - Examples take advantage of this modification and thus are cleaner.
2014-05-17 19:26:01 +02:00
import io.netty.util.internal.NativeLibraryLoader;
Only load native transport if running architecture match the compiled library architecture. Motivation: We should only try to load the native artifacts if the architecture we are currently running on is the same as the one the native libraries were compiled for. Modifications: Include architecture in native lib name and append the current arch when trying to load these. This will fail then if its not the same as the arch of the compiled arch. Result: Fixes [#7150].
2017-08-29 14:13:49 +02:00
import io.netty.util.internal.PlatformDependent;
Adding support for tcnative uber jar Motivation: We want to allow the use of an uber jar that contains the shared libraries for all platforms. Modifications: Modified OpenSsl to first check for a platform-specific lib before using the default lib. Result: uber support.
2016-02-19 18:20:35 +01:00
import io.netty.util.internal.SystemPropertyUtil;
Add an OpenSslEngine and the universal API for enabling SSL Motivation: Some users already use an SSLEngine implementation in finagle-native. It wraps OpenSSL to get higher SSL performance. However, to take advantage of it, finagle-native must be compiled manually, and it means we cannot pull it in as a dependency and thus we cannot test our SslHandler against the OpenSSL-based SSLEngine. For an instance, we had #2216. Because the construction procedures of JDK SSLEngine and OpenSslEngine are very different from each other, we also need to provide a universal way to enable SSL in a Netty application. Modifications: - Pull netty-tcnative in as an optional dependency. http://netty.io/wiki/forked-tomcat-native.html - Backport NativeLibraryLoader from 4.0 - Move OpenSSL-based SSLEngine implementation into our code base. - Copied from finagle-native; originally written by @jpinner et al. - Overall cleanup by @trustin. - Run all SslHandler tests with both default SSLEngine and OpenSslEngine - Add a unified API for creating an SSL context - SslContext allows you to create a new SSLEngine or a new SslHandler with your PKCS#8 key and X.509 certificate chain. - Add JdkSslContext and its subclasses - Add OpenSslServerContext - Add ApplicationProtocolSelector to ensure the future support for NPN (NextProtoNego) and ALPN (Application Layer Protocol Negotiation) on the client-side. - Add SimpleTrustManagerFactory to help a user write a TrustManagerFactory easily, which should be useful for those who need to write an alternative verification mechanism. For example, we can use it to implement an unsafe TrustManagerFactory that accepts self-signed certificates for testing purposes. - Add InsecureTrustManagerFactory and FingerprintTrustManager for quick and dirty testing - Add SelfSignedCertificate class which generates a self-signed X.509 certificate very easily. - Update all our examples to use SslContext.newClient/ServerContext() - SslHandler now logs the chosen cipher suite when handshake is finished. Result: - Cleaner unified API for configuring an SSL client and an SSL server regardless of its internal implementation. - When native libraries are available, OpenSSL-based SSLEngine implementation is selected automatically to take advantage of its performance benefit. - Examples take advantage of this modification and thus are cleaner.
2014-05-17 19:26:01 +02:00
import io.netty.util.internal.logging.InternalLogger;
import io.netty.util.internal.logging.InternalLoggerFactory;
Switch to netty-tcnative 2.0.0 which uses different package names Motivation: Previous versions of netty-tcnative used the org.apache.tomcat namespace which could lead to problems when a user tried to use tomcat and netty in the same app. Modifications: Use netty-tcnative which now uses a different namespace and adjust code to some API changes. Result: Its now possible to use netty-tcnative even when running together with tomcat.
2016-08-10 08:55:30 +02:00
Correctly detect if KeyManagerFactory is supported by OpenSSL even when sun.security.x509.* can not be accessed and bouncycastle is not on the classpath. (#8415) Motivation: OpenSsl used SelfSignedCertificate in its static init block to detect if KeyManagerFactory is supported. Unfortunally this only works when either sun.security.x509.* can be accessed or bouncycastle is on the classpath. We should not depend on either of it. This came up in https://github.com/netty/netty-tcnative/issues/404#issuecomment-431551890. Modifications: Just directly use the bytes to generate the X509Certificate and so not depend on sun.security.x509.* / bouncycastle. Result: Correctly be able to detect if KeyManagerFactory can be supported in all cases.
2018-10-23 17:08:23 +02:00
import java.io.ByteArrayInputStream;
Allow to explicit disable usage of KeyManagerFactory when using OpenSsl Motivation: Sometimes it may be useful to explicit disable the usage of the KeyManagerFactory when using OpenSsl. Modifications: Add io.netty.handler.ssl.openssl.useKeyManagerFactory which can be used to explicit disable KeyManagerFactory usage. Result: More flexible usage.
2016-08-01 22:17:30 +02:00
import java.security.AccessController;
import java.security.PrivilegedAction;
Correctly init X509Certificate array when testing if we need to wrap the KeyManager due of TLSv1.3 (#8435) Motivation: 201e984cb3995d59cf8254f851f0ffb9090c2fea added support to use native TLSv1.3 support even with Java versions prior to 11. For this we try to detect if we need to wrap the used KeyManager or not. This testing code did create an X509Certificate[1] but does not correctly also set the certficiate on index 0. While this should be harmless we should better do the right thing and set it. Modifications: Correctly init the array. Result: Cleaner and more correct code.
2018-10-30 08:17:31 +01:00
import java.security.cert.CertificateException;
Correctly detect if KeyManagerFactory is supported by OpenSSL even when sun.security.x509.* can not be accessed and bouncycastle is not on the classpath. (#8415) Motivation: OpenSsl used SelfSignedCertificate in its static init block to detect if KeyManagerFactory is supported. Unfortunally this only works when either sun.security.x509.* can be accessed or bouncycastle is on the classpath. We should not depend on either of it. This came up in https://github.com/netty/netty-tcnative/issues/404#issuecomment-431551890. Modifications: Just directly use the bytes to generate the X509Certificate and so not depend on sun.security.x509.* / bouncycastle. Result: Correctly be able to detect if KeyManagerFactory can be supported in all cases.
2018-10-23 17:08:23 +02:00
import java.security.cert.X509Certificate;
Unify default cipher suites betweek JDK and OpenSSL Motivation: Currently the default cipher suites are set independently between JDK and OpenSSL. We should use a common approach to setting the default ciphers. Also the OpenSsl default ciphers are expressed in terms of the OpenSSL cipher name conventions, which is not correct and may be exposed to the end user. OpenSSL should also use the RFC cipher names like the JDK defaults. Modifications: - Move the default cipher definition to a common location and use it in JDK and OpenSSL initialization - OpenSSL should not expose OpenSSL cipher names externally Result: Common initialization and OpenSSL doesn't expose custom cipher names.
2017-07-12 21:53:39 +02:00
import java.util.ArrayList;
Implement OpenSslEngine.getSupportedCipherSuites() and get/setEnabledCipherSuites() Motivation: To make OpenSslEngine a full drop-in replacement, we need to implement getSupportedCipherSuites() and get/setEnabledCipherSuites(). Modifications: - Retrieve the list of the available cipher suites when initializing OpenSsl. - Improve CipherSuiteConverter to understand SRP - Add more test data to CipherSuiteConverterTest - Add bulk-conversion method to CipherSuiteConverter Result: OpenSslEngine should now be a drop-in replacement for JDK SSLEngineImpl for most cases.
2014-12-30 10:59:30 +01:00
import java.util.Collections;
Raise an exception when the specified cipher suite is not available Motivation: SSL_set_cipher_list() in OpenSSL does not fail as long as at least one cipher suite is available. It is different from the semantics of SSLEngine.setEnabledCipherSuites(), which raises an exception when the list contains an unavailable cipher suite. Modifications: - Add OpenSsl.isCipherSuiteAvailable(String) which checks the availability of a cipher suite - Raise an IllegalArgumentException when the specified cipher suite is not available Result: Fixed compatibility
2014-12-30 11:20:43 +01:00
import java.util.LinkedHashSet;
Unify default cipher suites betweek JDK and OpenSSL Motivation: Currently the default cipher suites are set independently between JDK and OpenSSL. We should use a common approach to setting the default ciphers. Also the OpenSsl default ciphers are expressed in terms of the OpenSSL cipher name conventions, which is not correct and may be exposed to the end user. OpenSSL should also use the RFC cipher names like the JDK defaults. Modifications: - Move the default cipher definition to a common location and use it in JDK and OpenSSL initialization - OpenSSL should not expose OpenSSL cipher names externally Result: Common initialization and OpenSSL doesn't expose custom cipher names.
2017-07-12 21:53:39 +02:00
import java.util.List;
Raise an exception when the specified cipher suite is not available Motivation: SSL_set_cipher_list() in OpenSSL does not fail as long as at least one cipher suite is available. It is different from the semantics of SSLEngine.setEnabledCipherSuites(), which raises an exception when the list contains an unavailable cipher suite. Modifications: - Add OpenSsl.isCipherSuiteAvailable(String) which checks the availability of a cipher suite - Raise an IllegalArgumentException when the specified cipher suite is not available Result: Fixed compatibility
2014-12-30 11:20:43 +01:00
import java.util.Set;
Add an OpenSslEngine and the universal API for enabling SSL Motivation: Some users already use an SSLEngine implementation in finagle-native. It wraps OpenSSL to get higher SSL performance. However, to take advantage of it, finagle-native must be compiled manually, and it means we cannot pull it in as a dependency and thus we cannot test our SslHandler against the OpenSSL-based SSLEngine. For an instance, we had #2216. Because the construction procedures of JDK SSLEngine and OpenSslEngine are very different from each other, we also need to provide a universal way to enable SSL in a Netty application. Modifications: - Pull netty-tcnative in as an optional dependency. http://netty.io/wiki/forked-tomcat-native.html - Backport NativeLibraryLoader from 4.0 - Move OpenSSL-based SSLEngine implementation into our code base. - Copied from finagle-native; originally written by @jpinner et al. - Overall cleanup by @trustin. - Run all SslHandler tests with both default SSLEngine and OpenSslEngine - Add a unified API for creating an SSL context - SslContext allows you to create a new SSLEngine or a new SslHandler with your PKCS#8 key and X.509 certificate chain. - Add JdkSslContext and its subclasses - Add OpenSslServerContext - Add ApplicationProtocolSelector to ensure the future support for NPN (NextProtoNego) and ALPN (Application Layer Protocol Negotiation) on the client-side. - Add SimpleTrustManagerFactory to help a user write a TrustManagerFactory easily, which should be useful for those who need to write an alternative verification mechanism. For example, we can use it to implement an unsafe TrustManagerFactory that accepts self-signed certificates for testing purposes. - Add InsecureTrustManagerFactory and FingerprintTrustManager for quick and dirty testing - Add SelfSignedCertificate class which generates a self-signed X.509 certificate very easily. - Update all our examples to use SslContext.newClient/ServerContext() - SslHandler now logs the chosen cipher suite when handshake is finished. Result: - Cleaner unified API for configuring an SSL client and an SSL server regardless of its internal implementation. - When native libraries are available, OpenSSL-based SSLEngine implementation is selected automatically to take advantage of its performance benefit. - Examples take advantage of this modification and thus are cleaner.
2014-05-17 19:26:01 +02:00
Allow to use TLSv1.3 with netty-tcnative withe java versions prior to 11. (#8394) Motivation: At the moment it's only possible to use TLSv1.3 with netty-tcnative if Java 11 is used. It should be possible to do so even with Java 8, 9 and 10. Modification: Add a workaround to be able to use TLSv1.3 also when using Java version prior to Java 11 and the default X509ExtendedTrustManager is used. Result: Be able to use TLSv1.3 also with past versions of Java.
2018-10-18 13:50:12 +02:00
import static io.netty.handler.ssl.SslUtils.*;
Unify default cipher suites betweek JDK and OpenSSL Motivation: Currently the default cipher suites are set independently between JDK and OpenSSL. We should use a common approach to setting the default ciphers. Also the OpenSsl default ciphers are expressed in terms of the OpenSSL cipher name conventions, which is not correct and may be exposed to the end user. OpenSSL should also use the RFC cipher names like the JDK defaults. Modifications: - Move the default cipher definition to a common location and use it in JDK and OpenSSL initialization - OpenSSL should not expose OpenSSL cipher names externally Result: Common initialization and OpenSSL doesn't expose custom cipher names.
2017-07-12 21:53:39 +02:00
Add an OpenSslEngine and the universal API for enabling SSL Motivation: Some users already use an SSLEngine implementation in finagle-native. It wraps OpenSSL to get higher SSL performance. However, to take advantage of it, finagle-native must be compiled manually, and it means we cannot pull it in as a dependency and thus we cannot test our SslHandler against the OpenSSL-based SSLEngine. For an instance, we had #2216. Because the construction procedures of JDK SSLEngine and OpenSslEngine are very different from each other, we also need to provide a universal way to enable SSL in a Netty application. Modifications: - Pull netty-tcnative in as an optional dependency. http://netty.io/wiki/forked-tomcat-native.html - Backport NativeLibraryLoader from 4.0 - Move OpenSSL-based SSLEngine implementation into our code base. - Copied from finagle-native; originally written by @jpinner et al. - Overall cleanup by @trustin. - Run all SslHandler tests with both default SSLEngine and OpenSslEngine - Add a unified API for creating an SSL context - SslContext allows you to create a new SSLEngine or a new SslHandler with your PKCS#8 key and X.509 certificate chain. - Add JdkSslContext and its subclasses - Add OpenSslServerContext - Add ApplicationProtocolSelector to ensure the future support for NPN (NextProtoNego) and ALPN (Application Layer Protocol Negotiation) on the client-side. - Add SimpleTrustManagerFactory to help a user write a TrustManagerFactory easily, which should be useful for those who need to write an alternative verification mechanism. For example, we can use it to implement an unsafe TrustManagerFactory that accepts self-signed certificates for testing purposes. - Add InsecureTrustManagerFactory and FingerprintTrustManager for quick and dirty testing - Add SelfSignedCertificate class which generates a self-signed X.509 certificate very easily. - Update all our examples to use SslContext.newClient/ServerContext() - SslHandler now logs the chosen cipher suite when handshake is finished. Result: - Cleaner unified API for configuring an SSL client and an SSL server regardless of its internal implementation. - When native libraries are available, OpenSSL-based SSLEngine implementation is selected automatically to take advantage of its performance benefit. - Examples take advantage of this modification and thus are cleaner.
2014-05-17 19:26:01 +02:00
/**
* Tells if <a href="http://netty.io/wiki/forked-tomcat-native.html">{@code netty-tcnative}</a> and its OpenSSL support
* are available.
*/
public final class OpenSsl {
private static final InternalLogger logger = InternalLoggerFactory.getInstance(OpenSsl.class);
private static final Throwable UNAVAILABILITY_CAUSE;
Unify default cipher suites betweek JDK and OpenSSL Motivation: Currently the default cipher suites are set independently between JDK and OpenSSL. We should use a common approach to setting the default ciphers. Also the OpenSsl default ciphers are expressed in terms of the OpenSSL cipher name conventions, which is not correct and may be exposed to the end user. OpenSSL should also use the RFC cipher names like the JDK defaults. Modifications: - Move the default cipher definition to a common location and use it in JDK and OpenSSL initialization - OpenSSL should not expose OpenSSL cipher names externally Result: Common initialization and OpenSSL doesn't expose custom cipher names.
2017-07-12 21:53:39 +02:00
static final List<String> DEFAULT_CIPHERS;
OpenSslEngine.getSupportedCipherSuites() must return java names as well. Motivation: At the moment OpenSslEngine.getSupportedCipherSuites() only return the original openssl cipher names and not the java names. We need also include the java names. Modifications: Correctly return the java names as well. Result: Correct implementation of OpenSslEngine.getSupportedCipherSuites()
2016-06-22 15:46:45 +02:00
static final Set<String> AVAILABLE_CIPHER_SUITES;
private static final Set<String> AVAILABLE_OPENSSL_CIPHER_SUITES;
private static final Set<String> AVAILABLE_JAVA_CIPHER_SUITES;
Add support for KeyManagerFactory when using SslProvider.OpenSsl. Motivation: To be able to use SslProvider.OpenSsl with existing java apps that use the JDK SSL API we need to also provide a way to use it with an existing KeyManagerFactory. Modification: Make use of new tcnative apis and so hook in KeyManagerFactory. Result: SslProvider.OpenSsl can be used with KeyManagerFactory as well.
2016-06-20 14:07:53 +02:00
private static final boolean SUPPORTS_KEYMANAGER_FACTORY;
Allow to explicit disable usage of KeyManagerFactory when using OpenSsl Motivation: Sometimes it may be useful to explicit disable the usage of the KeyManagerFactory when using OpenSsl. Modifications: Add io.netty.handler.ssl.openssl.useKeyManagerFactory which can be used to explicit disable KeyManagerFactory usage. Result: More flexible usage.
2016-08-01 22:17:30 +02:00
private static final boolean USE_KEYMANAGER_FACTORY;
Correctly detect if Ocsp is supported Motivation: We only used the openssl version to detect if Ocsp is supported or not which is not good enough as even the version is correct it may be compiled without support for OCSP (like for example on ubuntu). Modifications: Try to enable OCSP while static init OpenSsl and based on if this works return true or false when calling OpenSsl.isOcspSupported(). Result: Correctly detect if OSCP is supported.
2017-05-09 11:41:04 +02:00
private static final boolean SUPPORTS_OCSP;
Add support for TLSv1.3 (#8293) 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.
2018-10-17 08:35:35 +02:00
private static final boolean TLSV13_SUPPORTED;
Add support for boringssl and TLSv1.3 (#8412) Motivation: 0ddc62cec0b4715ae37cef0e6a9f8c79d42d74e9 added support for TLSv1.3 when using openssl 1.1.1. Now that BoringSSL chromium-stable branch supports it as well we can also support it with netty-tcnative-boringssl-static. During this some unit tests failed with BoringSSL which was caused by not correctly handling flush() while the handshake is still in progress. Modification: - Upgrade netty-tcnative version which also supports TLSv1.3 when using BoringSSL - Correctly handle flush() when done while the handshake is still in progress in all cases. Result: Easier for people to enable TLSv1.3 when using native SSL impl. Ensure flush() while handshake is in progress will always be honored.
2018-10-27 00:29:49 +02:00
private static final boolean IS_BORINGSSL;
Correctly detect which protocols are supported when using OpenSSL Motivation: We failed to properly test if a protocol is supported on an OpenSSL installation and just always returned all protocols. Modifications: - Detect which protocols are supported on a platform. - Skip protocols in tests when not supported. This fixes a build error on some platforms introduced by [#6276]. Result: Correctly return only the supported protocols
2017-01-27 11:54:11 +01:00
static final Set<String> SUPPORTED_PROTOCOLS_SET;
Implement OpenSslEngine.getSupportedCipherSuites() and get/setEnabledCipherSuites() Motivation: To make OpenSslEngine a full drop-in replacement, we need to implement getSupportedCipherSuites() and get/setEnabledCipherSuites(). Modifications: - Retrieve the list of the available cipher suites when initializing OpenSsl. - Improve CipherSuiteConverter to understand SRP - Add more test data to CipherSuiteConverterTest - Add bulk-conversion method to CipherSuiteConverter Result: OpenSslEngine should now be a drop-in replacement for JDK SSLEngineImpl for most cases.
2014-12-30 10:59:30 +01:00
Use SSL.setKeyMaterial(...) to test if the KeyManagerFactory is supported (#8985) Motivation: We use SSL.setKeyMaterial(...) in our implementation when using the KeyManagerFactory so we should also use it to detect if we can support KeyManagerFactory. Modifications: Use SSL.setKeyMaterial(...) as replacement for SSL.setCertificateBio(...) Result: Use the same method call to detect if KeyManagerFactory can be supported as we use in the real implementation.
2019-04-01 12:03:05 +02:00
// Bytes of self-signed certificate for netty.io and the matching private-key
private static byte[] CERT_BYTES = {
48, -126, 1, -93, 48, -126, 1, 12, -96, 3, 2, 1, 2, 2, 8, 31, 127, -24, 79, 67,
-72, -128, 124, 48, 13, 6, 9, 42, -122, 72, -122, -9, 13, 1, 1, 11, 5, 0, 48,
19, 49, 17, 48, 15, 6, 3, 85, 4, 3, 19, 8, 110, 101, 116, 116, 121, 46, 105,
111, 48, 32, 23, 13, 49, 56, 48, 51, 50, 55, 49, 50, 52, 49, 50, 49, 90, 24,
15, 57, 57, 57, 57, 49, 50, 51, 49, 50, 51, 53, 57, 53, 57, 90, 48, 19, 49, 17,
48, 15, 6, 3, 85, 4, 3, 19, 8, 110, 101, 116, 116, 121, 46, 105, 111, 48, -127,
-97, 48, 13, 6, 9, 42, -122, 72, -122, -9, 13, 1, 1, 1, 5, 0, 3, -127, -115, 0,
48, -127, -119, 2, -127, -127, 0, -105, 81, 76, -56, -118, -35, 54, -61, -39,
69, 77, -56, 36, -126, 15, -35, -97, 126, -59, 2, -110, -39, -122, -116, -62,
-83, -43, -102, 98, 46, -33, 6, 33, 74, -68, -121, -64, -9, -3, 45, 102, -121,
50, -86, 93, 125, -82, -110, -2, -22, -114, 18, -93, 51, -86, 63, -63, 46, 96,
-37, 16, 105, -11, 96, -97, -77, 98, -2, 117, -66, -118, 31, -62, -94, 109, -61,
-82, 31, -103, 29, -53, -6, 47, 13, -78, -30, -128, 95, -76, 18, 5, -43, -80,
51, 22, 39, 11, -93, 101, -66, -105, -68, -110, -80, 89, -105, -116, 10, -42,
16, 51, 4, 113, -23, 69, -111, 85, -61, -59, -33, -83, 5, 114, -112, 34, 34,
-107, 79, 2, 3, 1, 0, 1, 48, 13, 6, 9, 42, -122, 72, -122, -9, 13, 1, 1, 11, 5,
0, 3, -127, -127, 0, 8, -18, -42, -73, 54, 95, 39, -58, -98, 62, -26, 50, -3,
71, -125, -128, -19, -87, -46, -85, 72, 17, 46, 75, -104, 125, -51, 27, 123,
84, 34, 100, -112, 122, -28, 29, -33, 127, -20, -54, 30, -77, 109, -81, -3,
-73, -113, 17, 28, 98, 127, 77, 53, -76, -49, -119, 98, 113, 71, -107, -33,
-57, 37, -55, -60, 89, 65, 83, -96, -54, -22, 122, 10, -11, 11, -67, -58, -57,
85, -119, 46, -26, -41, 15, -77, 19, 4, -32, -64, -12, 49, 104, -101, 42, 88,
75, 27, 41, 122, 126, 70, -99, -91, -33, -36, -57, -63, -7, 94, -71, -15, -108,
59, -32, 50, 47, -35, 71, 104, 47, 97, 43, 93, -128, -65, 11, 29, -88
};
private static byte[] KEY_BYTES = {
48, -126, 2, 120, 2, 1, 0, 48, 13, 6, 9, 42, -122, 72, -122, -9, 13, 1, 1, 1, 5,
0, 4, -126, 2, 98, 48, -126, 2, 94, 2, 1, 0, 2, -127, -127, 0, -105, 81, 76, -56,
-118, -35, 54, -61, -39, 69, 77, -56, 36, -126, 15, -35, -97, 126, -59, 2, -110,
-39, -122, -116, -62, -83, -43, -102, 98, 46, -33, 6, 33, 74, -68, -121, -64, -9,
-3, 45, 102, -121, 50, -86, 93, 125, -82, -110, -2, -22, -114, 18, -93, 51, -86,
63, -63, 46, 96, -37, 16, 105, -11, 96, -97, -77, 98, -2, 117, -66, -118, 31, -62,
-94, 109, -61, -82, 31, -103, 29, -53, -6, 47, 13, -78, -30, -128, 95, -76, 18, 5,
-43, -80, 51, 22, 39, 11, -93, 101, -66, -105, -68, -110, -80, 89, -105, -116, 10,
-42, 16, 51, 4, 113, -23, 69, -111, 85, -61, -59, -33, -83, 5, 114, -112, 34, 34,
-107, 79, 2, 3, 1, 0, 1, 2, -127, -128, 68, 52, 93, 11, -73, -85, -26, 87, 120, -61,
-120, 63, -62, 84, -19, -103, -45, -98, 108, 102, -80, -110, 99, -41, 102, -104,
-68, 67, 14, 38, 90, 88, -123, 1, 14, -31, -111, -43, 53, -59, 21, 5, -77, -116,
-98, -1, 91, -124, -34, 106, 19, 7, -53, -112, 42, 24, -6, -106, 81, 9, -20, -24,
21, -75, 119, -49, 70, 70, -106, -6, -56, -6, 28, 104, 33, -104, 27, 65, -75, -12,
-93, 75, 87, 82, -64, -70, -127, 60, 91, -60, -76, 13, -115, 19, -77, -16, -3, 119,
-88, 111, 96, 78, -103, -30, -87, -118, 106, -7, 97, -21, 20, -31, -43, 28, -18,
-2, 117, 63, 111, -71, 84, -77, -42, 78, 20, -28, -54, -63, 2, 65, 0, -23, 7, -72,
-18, -122, 34, 90, 107, -103, 119, 105, 46, -10, -109, -7, 3, 21, 16, 91, 110, -13,
120, 95, 122, -77, -60, 18, -52, 103, -1, -90, 39, -3, 99, -10, 18, -14, 47, -104,
-87, -110, 7, -48, -23, -37, 104, -125, 97, 88, -1, -86, -90, -11, -79, -20, 41,
-128, 15, -35, -104, 60, 25, 121, -41, 2, 65, 0, -90, 59, -92, -31, -117, 35, -79,
16, -76, 57, 90, 15, -6, 84, 47, -113, -42, 19, -56, 121, 123, -121, -91, 91, -37,
-71, 78, -40, 12, 82, -25, -125, -58, 115, -123, 97, 10, -99, -59, 38, -48, -103,
-128, -125, 36, 108, 18, -86, -85, -17, -40, 8, -14, -108, -24, -20, 63, -59, -81,
5, 11, 35, 1, 73, 2, 65, 0, -30, 11, -8, -85, -128, 120, 80, -121, -15, -35, -80,
-83, -70, -55, 125, -109, 44, -38, -86, 39, 45, -116, 69, -22, 75, -7, 86, 86, -20,
71, 68, -111, -92, 46, 84, 100, -70, -125, -53, 46, 42, -106, -28, 100, 5, -49, 19,
42, -38, 95, 95, -42, 7, -99, -23, 61, -76, -103, 47, 86, -34, 109, -60, 15, 2, 65,
0, -126, -72, -22, -101, 87, 0, -75, 80, 110, 121, -97, 98, 107, 55, -30, -61, 24,
-43, 43, -44, -92, -104, -14, 39, 127, 109, -123, 28, 14, -20, -17, 20, -56, 109,
-75, -40, -81, 49, -116, -123, 78, -117, 55, -19, 105, 41, -9, -81, -15, 79, -58,
50, -101, 25, 16, -26, 31, -20, 68, 11, 18, 75, -17, -55, 2, 65, 0, -126, -11, 56,
-83, -60, 1, -125, 109, 74, 74, -1, -17, 54, 111, -111, 100, 125, 21, 77, 34, 119,
-33, 23, -13, 66, 74, -78, 80, -67, 57, -42, 65, 65, 58, 96, 0, 72, -122, 3, -78,
119, 68, -76, 5, 50, 37, 51, 10, -54, 54, -102, 90, -6, 127, -93, 97, 53, 24, 57,
77, 81, 53, -13, -127
};
Add an OpenSslEngine and the universal API for enabling SSL Motivation: Some users already use an SSLEngine implementation in finagle-native. It wraps OpenSSL to get higher SSL performance. However, to take advantage of it, finagle-native must be compiled manually, and it means we cannot pull it in as a dependency and thus we cannot test our SslHandler against the OpenSSL-based SSLEngine. For an instance, we had #2216. Because the construction procedures of JDK SSLEngine and OpenSslEngine are very different from each other, we also need to provide a universal way to enable SSL in a Netty application. Modifications: - Pull netty-tcnative in as an optional dependency. http://netty.io/wiki/forked-tomcat-native.html - Backport NativeLibraryLoader from 4.0 - Move OpenSSL-based SSLEngine implementation into our code base. - Copied from finagle-native; originally written by @jpinner et al. - Overall cleanup by @trustin. - Run all SslHandler tests with both default SSLEngine and OpenSslEngine - Add a unified API for creating an SSL context - SslContext allows you to create a new SSLEngine or a new SslHandler with your PKCS#8 key and X.509 certificate chain. - Add JdkSslContext and its subclasses - Add OpenSslServerContext - Add ApplicationProtocolSelector to ensure the future support for NPN (NextProtoNego) and ALPN (Application Layer Protocol Negotiation) on the client-side. - Add SimpleTrustManagerFactory to help a user write a TrustManagerFactory easily, which should be useful for those who need to write an alternative verification mechanism. For example, we can use it to implement an unsafe TrustManagerFactory that accepts self-signed certificates for testing purposes. - Add InsecureTrustManagerFactory and FingerprintTrustManager for quick and dirty testing - Add SelfSignedCertificate class which generates a self-signed X.509 certificate very easily. - Update all our examples to use SslContext.newClient/ServerContext() - SslHandler now logs the chosen cipher suite when handshake is finished. Result: - Cleaner unified API for configuring an SSL client and an SSL server regardless of its internal implementation. - When native libraries are available, OpenSSL-based SSLEngine implementation is selected automatically to take advantage of its performance benefit. - Examples take advantage of this modification and thus are cleaner.
2014-05-17 19:26:01 +02:00
static {
Throwable cause = null;
Do not log CNFE when tcnative is not in classpath Motivation: When a user deliberatively omitted netty-tcnative from classpath, he or she will see an ugly stack trace of ClassNotFoundException. Modifications: Log more briefly when netty-tcnative is not in classpath. Result: Better-looking log at DEBUG level
2015-01-08 04:23:14 +01:00
Allow to disable native transport and native ssl support via system property. (#7903) Motivation: Sometimes it's useful to disable native transports / native ssl to debug a problem. We should allow to do so with a system property so people not need to adjust code for this. Modifications: Add system properties which allow to disable native transport and native ssl. Result: Easier to disable native code usage without code changes.
2018-05-04 14:44:44 +02:00
if (SystemPropertyUtil.getBoolean("io.netty.handler.ssl.noOpenSsl", false)) {
cause = new UnsupportedOperationException(
"OpenSSL was explicit disabled with -Dio.netty.handler.ssl.noOpenSsl=true");
Do not log CNFE when tcnative is not in classpath Motivation: When a user deliberatively omitted netty-tcnative from classpath, he or she will see an ugly stack trace of ClassNotFoundException. Modifications: Log more briefly when netty-tcnative is not in classpath. Result: Better-looking log at DEBUG level
2015-01-08 04:23:14 +01:00
Allow to disable native transport and native ssl support via system property. (#7903) Motivation: Sometimes it's useful to disable native transports / native ssl to debug a problem. We should allow to do so with a system property so people not need to adjust code for this. Modifications: Add system properties which allow to disable native transport and native ssl. Result: Easier to disable native code usage without code changes.
2018-05-04 14:44:44 +02:00
logger.debug(
"netty-tcnative explicit disabled; " +
OpenSslEngine.class.getSimpleName() + " will be unavailable.", cause);
} else {
// Test if netty-tcnative is in the classpath first.
Do not log CNFE when tcnative is not in classpath Motivation: When a user deliberatively omitted netty-tcnative from classpath, he or she will see an ugly stack trace of ClassNotFoundException. Modifications: Log more briefly when netty-tcnative is not in classpath. Result: Better-looking log at DEBUG level
2015-01-08 04:23:14 +01:00
try {
Allow to disable native transport and native ssl support via system property. (#7903) Motivation: Sometimes it's useful to disable native transports / native ssl to debug a problem. We should allow to do so with a system property so people not need to adjust code for this. Modifications: Add system properties which allow to disable native transport and native ssl. Result: Easier to disable native code usage without code changes.
2018-05-04 14:44:44 +02:00
Class.forName("io.netty.internal.tcnative.SSL", false, OpenSsl.class.getClassLoader());
} catch (ClassNotFoundException t) {
Support preloading of tcnative share lib Motivation: Some applications may use alternative methods of loading the tcnative JNI symbols. We should support this use case. Modifications: Separate the loading and initialzation of the tcnative library so that each can fail independently. Result: Fixes #5043
2016-04-11 18:06:48 +02:00
cause = t;
logger.debug(
Allow to disable native transport and native ssl support via system property. (#7903) Motivation: Sometimes it's useful to disable native transports / native ssl to debug a problem. We should allow to do so with a system property so people not need to adjust code for this. Modifications: Add system properties which allow to disable native transport and native ssl. Result: Easier to disable native code usage without code changes.
2018-05-04 14:44:44 +02:00
"netty-tcnative not in the classpath; " +
OpenSslEngine.class.getSimpleName() + " will be unavailable.");
Support preloading of tcnative share lib Motivation: Some applications may use alternative methods of loading the tcnative JNI symbols. We should support this use case. Modifications: Separate the loading and initialzation of the tcnative library so that each can fail independently. Result: Fixes #5043
2016-04-11 18:06:48 +02:00
}
Adding support for tcnative fedora flavour in uber jar Motivation: We want to allow the use of an uber jar that contains shared dynamic libraries for all platforms (including fedora). Modifications: Modified OpenSsl to try and load the fedora library if the OS is Linux and the platform specified library fails before using the default lib. Result: True uber support.
2016-03-02 20:18:45 +01:00
Allow to disable native transport and native ssl support via system property. (#7903) Motivation: Sometimes it's useful to disable native transports / native ssl to debug a problem. We should allow to do so with a system property so people not need to adjust code for this. Modifications: Add system properties which allow to disable native transport and native ssl. Result: Easier to disable native code usage without code changes.
2018-05-04 14:44:44 +02:00
// If in the classpath, try to load the native library and initialize netty-tcnative.
if (cause == null) {
try {
// The JNI library was not already loaded. Load it now.
loadTcNative();
} catch (Throwable t) {
Support preloading of tcnative share lib Motivation: Some applications may use alternative methods of loading the tcnative JNI symbols. We should support this use case. Modifications: Separate the loading and initialzation of the tcnative library so that each can fail independently. Result: Fixes #5043
2016-04-11 18:06:48 +02:00
cause = t;
Allow to disable native transport and native ssl support via system property. (#7903) Motivation: Sometimes it's useful to disable native transports / native ssl to debug a problem. We should allow to do so with a system property so people not need to adjust code for this. Modifications: Add system properties which allow to disable native transport and native ssl. Result: Easier to disable native code usage without code changes.
2018-05-04 14:44:44 +02:00
logger.debug(
"Failed to load netty-tcnative; " +
OpenSslEngine.class.getSimpleName() + " will be unavailable, unless the " +
"application has already loaded the symbols by some other means. " +
"See http://netty.io/wiki/forked-tomcat-native.html for more information.", t);
}
try {
OpenSSL (and so netty-tcnative) should allow to use custom engine. (#8050) Motivation: OpenSSL allows to use a custom engine for its cryptographic operations. We should allow the user to make use of it if needed. See also: https://www.openssl.org/docs/man1.0.2/crypto/engine.html. Modifications: Add new system property which can be used to specify the engine to use (null is the default and will use the build in default impl). Result: More flexible way of using OpenSSL.
2018-06-28 08:13:52 +02:00
String engine = SystemPropertyUtil.get("io.netty.handler.ssl.openssl.engine", null);
if (engine == null) {
logger.debug("Initialize netty-tcnative using engine: 'default'");
} else {
logger.debug("Initialize netty-tcnative using engine: '{}'", engine);
}
initializeTcNative(engine);
Allow to disable native transport and native ssl support via system property. (#7903) Motivation: Sometimes it's useful to disable native transports / native ssl to debug a problem. We should allow to do so with a system property so people not need to adjust code for this. Modifications: Add system properties which allow to disable native transport and native ssl. Result: Easier to disable native code usage without code changes.
2018-05-04 14:44:44 +02:00
// The library was initialized successfully. If loading the library failed above,
// reset the cause now since it appears that the library was loaded by some other
// means.
cause = null;
} catch (Throwable t) {
if (cause == null) {
cause = t;
}
logger.debug(
"Failed to initialize netty-tcnative; " +
OpenSslEngine.class.getSimpleName() + " will be unavailable. " +
"See http://netty.io/wiki/forked-tomcat-native.html for more information.", t);
Support preloading of tcnative share lib Motivation: Some applications may use alternative methods of loading the tcnative JNI symbols. We should support this use case. Modifications: Separate the loading and initialzation of the tcnative library so that each can fail independently. Result: Fixes #5043
2016-04-11 18:06:48 +02:00
}
Do not log CNFE when tcnative is not in classpath Motivation: When a user deliberatively omitted netty-tcnative from classpath, he or she will see an ugly stack trace of ClassNotFoundException. Modifications: Log more briefly when netty-tcnative is not in classpath. Result: Better-looking log at DEBUG level
2015-01-08 04:23:14 +01:00
}
Add an OpenSslEngine and the universal API for enabling SSL Motivation: Some users already use an SSLEngine implementation in finagle-native. It wraps OpenSSL to get higher SSL performance. However, to take advantage of it, finagle-native must be compiled manually, and it means we cannot pull it in as a dependency and thus we cannot test our SslHandler against the OpenSSL-based SSLEngine. For an instance, we had #2216. Because the construction procedures of JDK SSLEngine and OpenSslEngine are very different from each other, we also need to provide a universal way to enable SSL in a Netty application. Modifications: - Pull netty-tcnative in as an optional dependency. http://netty.io/wiki/forked-tomcat-native.html - Backport NativeLibraryLoader from 4.0 - Move OpenSSL-based SSLEngine implementation into our code base. - Copied from finagle-native; originally written by @jpinner et al. - Overall cleanup by @trustin. - Run all SslHandler tests with both default SSLEngine and OpenSslEngine - Add a unified API for creating an SSL context - SslContext allows you to create a new SSLEngine or a new SslHandler with your PKCS#8 key and X.509 certificate chain. - Add JdkSslContext and its subclasses - Add OpenSslServerContext - Add ApplicationProtocolSelector to ensure the future support for NPN (NextProtoNego) and ALPN (Application Layer Protocol Negotiation) on the client-side. - Add SimpleTrustManagerFactory to help a user write a TrustManagerFactory easily, which should be useful for those who need to write an alternative verification mechanism. For example, we can use it to implement an unsafe TrustManagerFactory that accepts self-signed certificates for testing purposes. - Add InsecureTrustManagerFactory and FingerprintTrustManager for quick and dirty testing - Add SelfSignedCertificate class which generates a self-signed X.509 certificate very easily. - Update all our examples to use SslContext.newClient/ServerContext() - SslHandler now logs the chosen cipher suite when handshake is finished. Result: - Cleaner unified API for configuring an SSL client and an SSL server regardless of its internal implementation. - When native libraries are available, OpenSSL-based SSLEngine implementation is selected automatically to take advantage of its performance benefit. - Examples take advantage of this modification and thus are cleaner.
2014-05-17 19:26:01 +02:00
}
Do not log CNFE when tcnative is not in classpath Motivation: When a user deliberatively omitted netty-tcnative from classpath, he or she will see an ugly stack trace of ClassNotFoundException. Modifications: Log more briefly when netty-tcnative is not in classpath. Result: Better-looking log at DEBUG level
2015-01-08 04:23:14 +01:00
Add an OpenSslEngine and the universal API for enabling SSL Motivation: Some users already use an SSLEngine implementation in finagle-native. It wraps OpenSSL to get higher SSL performance. However, to take advantage of it, finagle-native must be compiled manually, and it means we cannot pull it in as a dependency and thus we cannot test our SslHandler against the OpenSSL-based SSLEngine. For an instance, we had #2216. Because the construction procedures of JDK SSLEngine and OpenSslEngine are very different from each other, we also need to provide a universal way to enable SSL in a Netty application. Modifications: - Pull netty-tcnative in as an optional dependency. http://netty.io/wiki/forked-tomcat-native.html - Backport NativeLibraryLoader from 4.0 - Move OpenSSL-based SSLEngine implementation into our code base. - Copied from finagle-native; originally written by @jpinner et al. - Overall cleanup by @trustin. - Run all SslHandler tests with both default SSLEngine and OpenSslEngine - Add a unified API for creating an SSL context - SslContext allows you to create a new SSLEngine or a new SslHandler with your PKCS#8 key and X.509 certificate chain. - Add JdkSslContext and its subclasses - Add OpenSslServerContext - Add ApplicationProtocolSelector to ensure the future support for NPN (NextProtoNego) and ALPN (Application Layer Protocol Negotiation) on the client-side. - Add SimpleTrustManagerFactory to help a user write a TrustManagerFactory easily, which should be useful for those who need to write an alternative verification mechanism. For example, we can use it to implement an unsafe TrustManagerFactory that accepts self-signed certificates for testing purposes. - Add InsecureTrustManagerFactory and FingerprintTrustManager for quick and dirty testing - Add SelfSignedCertificate class which generates a self-signed X.509 certificate very easily. - Update all our examples to use SslContext.newClient/ServerContext() - SslHandler now logs the chosen cipher suite when handshake is finished. Result: - Cleaner unified API for configuring an SSL client and an SSL server regardless of its internal implementation. - When native libraries are available, OpenSSL-based SSLEngine implementation is selected automatically to take advantage of its performance benefit. - Examples take advantage of this modification and thus are cleaner.
2014-05-17 19:26:01 +02:00
UNAVAILABILITY_CAUSE = cause;
Implement OpenSslEngine.getSupportedCipherSuites() and get/setEnabledCipherSuites() Motivation: To make OpenSslEngine a full drop-in replacement, we need to implement getSupportedCipherSuites() and get/setEnabledCipherSuites(). Modifications: - Retrieve the list of the available cipher suites when initializing OpenSsl. - Improve CipherSuiteConverter to understand SRP - Add more test data to CipherSuiteConverterTest - Add bulk-conversion method to CipherSuiteConverter Result: OpenSslEngine should now be a drop-in replacement for JDK SSLEngineImpl for most cases.
2014-12-30 10:59:30 +01:00
if (cause == null) {
Log used native library by netty-tcnative Motivation: As netty-tcnative can be build against different native libraries and versions we should log the used one. Modifications: Log the used native library after netty-tcnative was loaded. Result: Easier to understand what native SSL library was used.
2017-02-19 13:34:15 +01:00
logger.debug("netty-tcnative using native library: {}", SSL.versionString());
Java 8 migration: Use diamond operator (#8749) Motivation: We can use the diamond operator these days. Modification: Use diamond operator whenever possible. Result: More modern code and less boiler-plate.
2019-01-22 16:07:26 +01:00
final List<String> defaultCiphers = new ArrayList<>();
final Set<String> availableOpenSslCipherSuites = new LinkedHashSet<>(128);
Add support for KeyManagerFactory when using SslProvider.OpenSsl. Motivation: To be able to use SslProvider.OpenSsl with existing java apps that use the JDK SSL API we need to also provide a way to use it with an existing KeyManagerFactory. Modification: Make use of new tcnative apis and so hook in KeyManagerFactory. Result: SslProvider.OpenSsl can be used with KeyManagerFactory as well.
2016-06-20 14:07:53 +02:00
boolean supportsKeyManagerFactory = false;
Allow to explicit disable usage of KeyManagerFactory when using OpenSsl Motivation: Sometimes it may be useful to explicit disable the usage of the KeyManagerFactory when using OpenSsl. Modifications: Add io.netty.handler.ssl.openssl.useKeyManagerFactory which can be used to explicit disable KeyManagerFactory usage. Result: More flexible usage.
2016-08-01 22:17:30 +02:00
boolean useKeyManagerFactory = false;
Add support for TLSv1.3 (#8293) 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.
2018-10-17 08:35:35 +02:00
boolean tlsv13Supported = false;
Add support for boringssl and TLSv1.3 (#8412) Motivation: 0ddc62cec0b4715ae37cef0e6a9f8c79d42d74e9 added support for TLSv1.3 when using openssl 1.1.1. Now that BoringSSL chromium-stable branch supports it as well we can also support it with netty-tcnative-boringssl-static. During this some unit tests failed with BoringSSL which was caused by not correctly handling flush() while the handshake is still in progress. Modification: - Upgrade netty-tcnative version which also supports TLSv1.3 when using BoringSSL - Correctly handle flush() when done while the handshake is still in progress in all cases. Result: Easier for people to enable TLSv1.3 when using native SSL impl. Ensure flush() while handshake is in progress will always be honored.
2018-10-27 00:29:49 +02:00
IS_BORINGSSL = "BoringSSL".equals(versionString());
Implement OpenSslEngine.getSupportedCipherSuites() and get/setEnabledCipherSuites() Motivation: To make OpenSslEngine a full drop-in replacement, we need to implement getSupportedCipherSuites() and get/setEnabledCipherSuites(). Modifications: - Retrieve the list of the available cipher suites when initializing OpenSsl. - Improve CipherSuiteConverter to understand SRP - Add more test data to CipherSuiteConverterTest - Add bulk-conversion method to CipherSuiteConverter Result: OpenSslEngine should now be a drop-in replacement for JDK SSLEngineImpl for most cases.
2014-12-30 10:59:30 +01:00
try {
Switch to netty-tcnative 2.0.0 which uses different package names Motivation: Previous versions of netty-tcnative used the org.apache.tomcat namespace which could lead to problems when a user tried to use tomcat and netty in the same app. Modifications: Use netty-tcnative which now uses a different namespace and adjust code to some API changes. Result: Its now possible to use netty-tcnative even when running together with tomcat.
2016-08-10 08:55:30 +02:00
final long sslCtx = SSLContext.make(SSL.SSL_PROTOCOL_ALL, SSL.SSL_MODE_SERVER);
Add support for KeyManagerFactory when using SslProvider.OpenSsl. Motivation: To be able to use SslProvider.OpenSsl with existing java apps that use the JDK SSL API we need to also provide a way to use it with an existing KeyManagerFactory. Modification: Make use of new tcnative apis and so hook in KeyManagerFactory. Result: SslProvider.OpenSsl can be used with KeyManagerFactory as well.
2016-06-20 14:07:53 +02:00
long certBio = 0;
Use SSL.setKeyMaterial(...) to test if the KeyManagerFactory is supported (#8985) Motivation: We use SSL.setKeyMaterial(...) in our implementation when using the KeyManagerFactory so we should also use it to detect if we can support KeyManagerFactory. Modifications: Use SSL.setKeyMaterial(...) as replacement for SSL.setCertificateBio(...) Result: Use the same method call to detect if KeyManagerFactory can be supported as we use in the real implementation.
2019-04-01 12:03:05 +02:00
long keyBio = 0;
long cert = 0;
long key = 0;
Implement OpenSslEngine.getSupportedCipherSuites() and get/setEnabledCipherSuites() Motivation: To make OpenSslEngine a full drop-in replacement, we need to implement getSupportedCipherSuites() and get/setEnabledCipherSuites(). Modifications: - Retrieve the list of the available cipher suites when initializing OpenSsl. - Improve CipherSuiteConverter to understand SRP - Add more test data to CipherSuiteConverterTest - Add bulk-conversion method to CipherSuiteConverter Result: OpenSslEngine should now be a drop-in replacement for JDK SSLEngineImpl for most cases.
2014-12-30 10:59:30 +01:00
try {
Allow to use TLSv1.3 with netty-tcnative withe java versions prior to 11. (#8394) Motivation: At the moment it's only possible to use TLSv1.3 with netty-tcnative if Java 11 is used. It should be possible to do so even with Java 8, 9 and 10. Modification: Add a workaround to be able to use TLSv1.3 also when using Java version prior to Java 11 and the default X509ExtendedTrustManager is used. Result: Be able to use TLSv1.3 also with past versions of Java.
2018-10-18 13:50:12 +02:00
try {
Correctly convert between openssl / boringssl and java cipher names when using TLSv1.3 (#8485) Motivation: We did not correctly convert between openssl / boringssl and java ciphers when using TLV1.3 which had different effects when either using openssl or boringssl. - When using openssl and TLSv1.3 we always returned SSL_NULL_WITH_NULL_NULL as cipher name - When using boringssl with TLSv1.3 we always returned an incorrect constructed cipher name which does not match what is defined by Java. Modifications: - Add correct mappings in CipherSuiteConverter for both openssl and boringssl - Add unit tests for CipherSuiteConvert - Add unit in SSLEngine which checks that we do not return SSL_NULL_WITH_NULL_NULL ever and that server and client returns the same cipher name. Result: Fixes https://github.com/netty/netty/issues/8477.
2018-11-14 08:49:13 +01:00
StringBuilder tlsv13Ciphers = new StringBuilder();
for (String cipher: TLSV13_CIPHERS) {
String converted = CipherSuiteConverter.toOpenSsl(cipher, IS_BORINGSSL);
if (converted != null) {
tlsv13Ciphers.append(converted).append(':');
}
}
if (tlsv13Ciphers.length() == 0) {
tlsv13Supported = false;
} else {
tlsv13Ciphers.setLength(tlsv13Ciphers.length() - 1);
SSLContext.setCipherSuite(sslCtx, tlsv13Ciphers.toString() , true);
tlsv13Supported = true;
}
Allow to use TLSv1.3 with netty-tcnative withe java versions prior to 11. (#8394) Motivation: At the moment it's only possible to use TLSv1.3 with netty-tcnative if Java 11 is used. It should be possible to do so even with Java 8, 9 and 10. Modification: Add a workaround to be able to use TLSv1.3 also when using Java version prior to Java 11 and the default X509ExtendedTrustManager is used. Result: Be able to use TLSv1.3 also with past versions of Java.
2018-10-18 13:50:12 +02:00
} catch (Exception ignore) {
tlsv13Supported = false;
Add support for TLSv1.3 (#8293) 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.
2018-10-17 08:35:35 +02:00
}
Allow to use TLSv1.3 with netty-tcnative withe java versions prior to 11. (#8394) Motivation: At the moment it's only possible to use TLSv1.3 with netty-tcnative if Java 11 is used. It should be possible to do so even with Java 8, 9 and 10. Modification: Add a workaround to be able to use TLSv1.3 also when using Java version prior to Java 11 and the default X509ExtendedTrustManager is used. Result: Be able to use TLSv1.3 also with past versions of Java.
2018-10-18 13:50:12 +02:00
Add support for TLSv1.3 (#8293) 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.
2018-10-17 08:35:35 +02:00
SSLContext.setCipherSuite(sslCtx, "ALL", false);
Implement OpenSslEngine.getSupportedCipherSuites() and get/setEnabledCipherSuites() Motivation: To make OpenSslEngine a full drop-in replacement, we need to implement getSupportedCipherSuites() and get/setEnabledCipherSuites(). Modifications: - Retrieve the list of the available cipher suites when initializing OpenSsl. - Improve CipherSuiteConverter to understand SRP - Add more test data to CipherSuiteConverterTest - Add bulk-conversion method to CipherSuiteConverter Result: OpenSslEngine should now be a drop-in replacement for JDK SSLEngineImpl for most cases.
2014-12-30 10:59:30 +01:00
final long ssl = SSL.newSSL(sslCtx, true);
try {
for (String c: SSL.getCiphers(ssl)) {
// Filter out bad input.
Add support for TLSv1.3 (#8293) 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.
2018-10-17 08:35:35 +02:00
if (c == null || c.isEmpty() || availableOpenSslCipherSuites.contains(c) ||
// Filter out TLSv1.3 ciphers if not supported.
Add support for boringssl and TLSv1.3 (#8412) Motivation: 0ddc62cec0b4715ae37cef0e6a9f8c79d42d74e9 added support for TLSv1.3 when using openssl 1.1.1. Now that BoringSSL chromium-stable branch supports it as well we can also support it with netty-tcnative-boringssl-static. During this some unit tests failed with BoringSSL which was caused by not correctly handling flush() while the handshake is still in progress. Modification: - Upgrade netty-tcnative version which also supports TLSv1.3 when using BoringSSL - Correctly handle flush() when done while the handshake is still in progress in all cases. Result: Easier for people to enable TLSv1.3 when using native SSL impl. Ensure flush() while handshake is in progress will always be honored.
2018-10-27 00:29:49 +02:00
!tlsv13Supported && isTLSv13Cipher(c)) {
Implement OpenSslEngine.getSupportedCipherSuites() and get/setEnabledCipherSuites() Motivation: To make OpenSslEngine a full drop-in replacement, we need to implement getSupportedCipherSuites() and get/setEnabledCipherSuites(). Modifications: - Retrieve the list of the available cipher suites when initializing OpenSsl. - Improve CipherSuiteConverter to understand SRP - Add more test data to CipherSuiteConverterTest - Add bulk-conversion method to CipherSuiteConverter Result: OpenSslEngine should now be a drop-in replacement for JDK SSLEngineImpl for most cases.
2014-12-30 10:59:30 +01:00
continue;
}
OpenSslEngine.getSupportedCipherSuites() must return java names as well. Motivation: At the moment OpenSslEngine.getSupportedCipherSuites() only return the original openssl cipher names and not the java names. We need also include the java names. Modifications: Correctly return the java names as well. Result: Correct implementation of OpenSslEngine.getSupportedCipherSuites()
2016-06-22 15:46:45 +02:00
availableOpenSslCipherSuites.add(c);
Implement OpenSslEngine.getSupportedCipherSuites() and get/setEnabledCipherSuites() Motivation: To make OpenSslEngine a full drop-in replacement, we need to implement getSupportedCipherSuites() and get/setEnabledCipherSuites(). Modifications: - Retrieve the list of the available cipher suites when initializing OpenSsl. - Improve CipherSuiteConverter to understand SRP - Add more test data to CipherSuiteConverterTest - Add bulk-conversion method to CipherSuiteConverter Result: OpenSslEngine should now be a drop-in replacement for JDK SSLEngineImpl for most cases.
2014-12-30 10:59:30 +01:00
}
Add support for boringssl and TLSv1.3 (#8412) Motivation: 0ddc62cec0b4715ae37cef0e6a9f8c79d42d74e9 added support for TLSv1.3 when using openssl 1.1.1. Now that BoringSSL chromium-stable branch supports it as well we can also support it with netty-tcnative-boringssl-static. During this some unit tests failed with BoringSSL which was caused by not correctly handling flush() while the handshake is still in progress. Modification: - Upgrade netty-tcnative version which also supports TLSv1.3 when using BoringSSL - Correctly handle flush() when done while the handshake is still in progress in all cases. Result: Easier for people to enable TLSv1.3 when using native SSL impl. Ensure flush() while handshake is in progress will always be honored.
2018-10-27 00:29:49 +02:00
if (IS_BORINGSSL) {
// Currently BoringSSL does not include these when calling SSL.getCiphers() even when these
// are supported.
Collections.addAll(availableOpenSslCipherSuites,
"TLS_AES_128_GCM_SHA256",
"TLS_AES_256_GCM_SHA384" ,
Correctly convert between openssl / boringssl and java cipher names when using TLSv1.3 (#8485) Motivation: We did not correctly convert between openssl / boringssl and java ciphers when using TLV1.3 which had different effects when either using openssl or boringssl. - When using openssl and TLSv1.3 we always returned SSL_NULL_WITH_NULL_NULL as cipher name - When using boringssl with TLSv1.3 we always returned an incorrect constructed cipher name which does not match what is defined by Java. Modifications: - Add correct mappings in CipherSuiteConverter for both openssl and boringssl - Add unit tests for CipherSuiteConvert - Add unit in SSLEngine which checks that we do not return SSL_NULL_WITH_NULL_NULL ever and that server and client returns the same cipher name. Result: Fixes https://github.com/netty/netty/issues/8477.
2018-11-14 08:49:13 +01:00
"TLS_CHACHA20_POLY1305_SHA256",
"AEAD-AES128-GCM-SHA256",
"AEAD-AES256-GCM-SHA384",
"AEAD-CHACHA20-POLY1305-SHA256");
Add support for boringssl and TLSv1.3 (#8412) Motivation: 0ddc62cec0b4715ae37cef0e6a9f8c79d42d74e9 added support for TLSv1.3 when using openssl 1.1.1. Now that BoringSSL chromium-stable branch supports it as well we can also support it with netty-tcnative-boringssl-static. During this some unit tests failed with BoringSSL which was caused by not correctly handling flush() while the handshake is still in progress. Modification: - Upgrade netty-tcnative version which also supports TLSv1.3 when using BoringSSL - Correctly handle flush() when done while the handshake is still in progress in all cases. Result: Easier for people to enable TLSv1.3 when using native SSL impl. Ensure flush() while handshake is in progress will always be honored.
2018-10-27 00:29:49 +02:00
}
Use SSL.setKeyMaterial(...) to test if the KeyManagerFactory is supported (#8985) Motivation: We use SSL.setKeyMaterial(...) in our implementation when using the KeyManagerFactory so we should also use it to detect if we can support KeyManagerFactory. Modifications: Use SSL.setKeyMaterial(...) as replacement for SSL.setCertificateBio(...) Result: Use the same method call to detect if KeyManagerFactory can be supported as we use in the real implementation.
2019-04-01 12:03:05 +02:00
PemEncoded privateKey = PemPrivateKey.toPEM(UnpooledByteBufAllocator.DEFAULT, true, KEY_BYTES);
Add support for KeyManagerFactory when using SslProvider.OpenSsl. Motivation: To be able to use SslProvider.OpenSsl with existing java apps that use the JDK SSL API we need to also provide a way to use it with an existing KeyManagerFactory. Modification: Make use of new tcnative apis and so hook in KeyManagerFactory. Result: SslProvider.OpenSsl can be used with KeyManagerFactory as well.
2016-06-20 14:07:53 +02:00
try {
Remove call to SSL.setHostNameValidation(...) as it is done in the TrustManager (#8981) Motivation: We do not need to call SSL.setHostNameValidation(...) as it should be done as part of the TrustManager implementation. This is consistent with the JDK implementation of SSLEngine. Modifications: Remove call to SSL.setHostNameValidation(...) Result: More consistent behaviour between our SSLEngine implementation and the one that comes with the JDK.
2019-04-01 21:02:36 +02:00
X509Certificate certificate = selfSignedCertificate();
Correctly detect if KeyManagerFactory is supported by OpenSSL even when sun.security.x509.* can not be accessed and bouncycastle is not on the classpath. (#8415) Motivation: OpenSsl used SelfSignedCertificate in its static init block to detect if KeyManagerFactory is supported. Unfortunally this only works when either sun.security.x509.* can be accessed or bouncycastle is on the classpath. We should not depend on either of it. This came up in https://github.com/netty/netty-tcnative/issues/404#issuecomment-431551890. Modifications: Just directly use the bytes to generate the X509Certificate and so not depend on sun.security.x509.* / bouncycastle. Result: Correctly be able to detect if KeyManagerFactory can be supported in all cases.
2018-10-23 17:08:23 +02:00
certBio = ReferenceCountedOpenSslContext.toBIO(ByteBufAllocator.DEFAULT, certificate);
Use SSL.setKeyMaterial(...) to test if the KeyManagerFactory is supported (#8985) Motivation: We use SSL.setKeyMaterial(...) in our implementation when using the KeyManagerFactory so we should also use it to detect if we can support KeyManagerFactory. Modifications: Use SSL.setKeyMaterial(...) as replacement for SSL.setCertificateBio(...) Result: Use the same method call to detect if KeyManagerFactory can be supported as we use in the real implementation.
2019-04-01 12:03:05 +02:00
cert = SSL.parseX509Chain(certBio);
keyBio = ReferenceCountedOpenSslContext.toBIO(
UnpooledByteBufAllocator.DEFAULT, privateKey.retain());
key = SSL.parsePrivateKey(keyBio, null);
SSL.setKeyMaterial(ssl, cert, key);
Add support for KeyManagerFactory when using SslProvider.OpenSsl. Motivation: To be able to use SslProvider.OpenSsl with existing java apps that use the JDK SSL API we need to also provide a way to use it with an existing KeyManagerFactory. Modification: Make use of new tcnative apis and so hook in KeyManagerFactory. Result: SslProvider.OpenSsl can be used with KeyManagerFactory as well.
2016-06-20 14:07:53 +02:00
supportsKeyManagerFactory = true;
OpenSsl tests incomplete check for supporting key manager Motivaiton: It is possible that if the OpenSSL library supports the interfaces required to use the KeyManagerFactory, but we fail to get the io.netty.handler.ssl.openssl.useKeyManagerFactory system property (or this property is set to false) that SSLEngineTest based unit tests which use a KeyManagerFactory will fail. Modifications: - We should check if the OpenSSL library supports the KeyManagerFactory interfaces and if the system property allows them to be used in OpenSslEngineTests Result: Unit tests which use OpenSSL and KeyManagerFactory will be skipped instead of failing.
2017-03-06 22:43:47 +01:00
try {
migrate java8: use lambda and method reference (#8781) Motivation: We can use lambdas now as we use Java8. Modification: use lambda function for all package, #8751 only migrate transport package. Result: Code cleanup.
2019-01-29 14:06:05 +01:00
useKeyManagerFactory = AccessController.doPrivileged((PrivilegedAction<Boolean>) () ->
SystemPropertyUtil.getBoolean(
"io.netty.handler.ssl.openssl.useKeyManagerFactory", true));
OpenSsl tests incomplete check for supporting key manager Motivaiton: It is possible that if the OpenSSL library supports the interfaces required to use the KeyManagerFactory, but we fail to get the io.netty.handler.ssl.openssl.useKeyManagerFactory system property (or this property is set to false) that SSLEngineTest based unit tests which use a KeyManagerFactory will fail. Modifications: - We should check if the OpenSSL library supports the KeyManagerFactory interfaces and if the system property allows them to be used in OpenSslEngineTests Result: Unit tests which use OpenSSL and KeyManagerFactory will be skipped instead of failing.
2017-03-06 22:43:47 +01:00
} catch (Throwable ignore) {
logger.debug("Failed to get useKeyManagerFactory system property.");
}
Add support for KeyManagerFactory when using SslProvider.OpenSsl. Motivation: To be able to use SslProvider.OpenSsl with existing java apps that use the JDK SSL API we need to also provide a way to use it with an existing KeyManagerFactory. Modification: Make use of new tcnative apis and so hook in KeyManagerFactory. Result: SslProvider.OpenSsl can be used with KeyManagerFactory as well.
2016-06-20 14:07:53 +02:00
} catch (Throwable ignore) {
logger.debug("KeyManagerFactory not supported.");
Use SSL.setKeyMaterial(...) to test if the KeyManagerFactory is supported (#8985) Motivation: We use SSL.setKeyMaterial(...) in our implementation when using the KeyManagerFactory so we should also use it to detect if we can support KeyManagerFactory. Modifications: Use SSL.setKeyMaterial(...) as replacement for SSL.setCertificateBio(...) Result: Use the same method call to detect if KeyManagerFactory can be supported as we use in the real implementation.
2019-04-01 12:03:05 +02:00
} finally {
privateKey.release();
Add support for KeyManagerFactory when using SslProvider.OpenSsl. Motivation: To be able to use SslProvider.OpenSsl with existing java apps that use the JDK SSL API we need to also provide a way to use it with an existing KeyManagerFactory. Modification: Make use of new tcnative apis and so hook in KeyManagerFactory. Result: SslProvider.OpenSsl can be used with KeyManagerFactory as well.
2016-06-20 14:07:53 +02:00
}
Implement OpenSslEngine.getSupportedCipherSuites() and get/setEnabledCipherSuites() Motivation: To make OpenSslEngine a full drop-in replacement, we need to implement getSupportedCipherSuites() and get/setEnabledCipherSuites(). Modifications: - Retrieve the list of the available cipher suites when initializing OpenSsl. - Improve CipherSuiteConverter to understand SRP - Add more test data to CipherSuiteConverterTest - Add bulk-conversion method to CipherSuiteConverter Result: OpenSslEngine should now be a drop-in replacement for JDK SSLEngineImpl for most cases.
2014-12-30 10:59:30 +01:00
} finally {
SSL.freeSSL(ssl);
Add support for KeyManagerFactory when using SslProvider.OpenSsl. Motivation: To be able to use SslProvider.OpenSsl with existing java apps that use the JDK SSL API we need to also provide a way to use it with an existing KeyManagerFactory. Modification: Make use of new tcnative apis and so hook in KeyManagerFactory. Result: SslProvider.OpenSsl can be used with KeyManagerFactory as well.
2016-06-20 14:07:53 +02:00
if (certBio != 0) {
SSL.freeBIO(certBio);
}
Use SSL.setKeyMaterial(...) to test if the KeyManagerFactory is supported (#8985) Motivation: We use SSL.setKeyMaterial(...) in our implementation when using the KeyManagerFactory so we should also use it to detect if we can support KeyManagerFactory. Modifications: Use SSL.setKeyMaterial(...) as replacement for SSL.setCertificateBio(...) Result: Use the same method call to detect if KeyManagerFactory can be supported as we use in the real implementation.
2019-04-01 12:03:05 +02:00
if (keyBio != 0) {
SSL.freeBIO(keyBio);
}
if (cert != 0) {
SSL.freeX509Chain(cert);
}
if (key != 0) {
SSL.freePrivateKey(key);
}
Implement OpenSslEngine.getSupportedCipherSuites() and get/setEnabledCipherSuites() Motivation: To make OpenSslEngine a full drop-in replacement, we need to implement getSupportedCipherSuites() and get/setEnabledCipherSuites(). Modifications: - Retrieve the list of the available cipher suites when initializing OpenSsl. - Improve CipherSuiteConverter to understand SRP - Add more test data to CipherSuiteConverterTest - Add bulk-conversion method to CipherSuiteConverter Result: OpenSslEngine should now be a drop-in replacement for JDK SSLEngineImpl for most cases.
2014-12-30 10:59:30 +01:00
}
} finally {
SSLContext.free(sslCtx);
}
} catch (Exception e) {
logger.warn("Failed to get the list of available OpenSSL cipher suites.", e);
}
OpenSslEngine.getSupportedCipherSuites() must return java names as well. Motivation: At the moment OpenSslEngine.getSupportedCipherSuites() only return the original openssl cipher names and not the java names. We need also include the java names. Modifications: Correctly return the java names as well. Result: Correct implementation of OpenSslEngine.getSupportedCipherSuites()
2016-06-22 15:46:45 +02:00
AVAILABLE_OPENSSL_CIPHER_SUITES = Collections.unmodifiableSet(availableOpenSslCipherSuites);
Java 8 migration: Use diamond operator (#8749) Motivation: We can use the diamond operator these days. Modification: Use diamond operator whenever possible. Result: More modern code and less boiler-plate.
2019-01-22 16:07:26 +01:00
final Set<String> availableJavaCipherSuites = new LinkedHashSet<>(
OpenSslEngine.getSupportedCipherSuites() must return java names as well. Motivation: At the moment OpenSslEngine.getSupportedCipherSuites() only return the original openssl cipher names and not the java names. We need also include the java names. Modifications: Correctly return the java names as well. Result: Correct implementation of OpenSslEngine.getSupportedCipherSuites()
2016-06-22 15:46:45 +02:00
AVAILABLE_OPENSSL_CIPHER_SUITES.size() * 2);
for (String cipher: AVAILABLE_OPENSSL_CIPHER_SUITES) {
// Included converted but also openssl cipher name
Add support for boringssl and TLSv1.3 (#8412) Motivation: 0ddc62cec0b4715ae37cef0e6a9f8c79d42d74e9 added support for TLSv1.3 when using openssl 1.1.1. Now that BoringSSL chromium-stable branch supports it as well we can also support it with netty-tcnative-boringssl-static. During this some unit tests failed with BoringSSL which was caused by not correctly handling flush() while the handshake is still in progress. Modification: - Upgrade netty-tcnative version which also supports TLSv1.3 when using BoringSSL - Correctly handle flush() when done while the handshake is still in progress in all cases. Result: Easier for people to enable TLSv1.3 when using native SSL impl. Ensure flush() while handshake is in progress will always be honored.
2018-10-27 00:29:49 +02:00
if (!isTLSv13Cipher(cipher)) {
Add support for TLSv1.3 (#8293) 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.
2018-10-17 08:35:35 +02:00
availableJavaCipherSuites.add(CipherSuiteConverter.toJava(cipher, "TLS"));
availableJavaCipherSuites.add(CipherSuiteConverter.toJava(cipher, "SSL"));
} else {
// TLSv1.3 ciphers have the correct format.
availableJavaCipherSuites.add(cipher);
}
OpenSslEngine.getSupportedCipherSuites() must return java names as well. Motivation: At the moment OpenSslEngine.getSupportedCipherSuites() only return the original openssl cipher names and not the java names. We need also include the java names. Modifications: Correctly return the java names as well. Result: Correct implementation of OpenSslEngine.getSupportedCipherSuites()
2016-06-22 15:46:45 +02:00
}
Unify default cipher suites betweek JDK and OpenSSL Motivation: Currently the default cipher suites are set independently between JDK and OpenSSL. We should use a common approach to setting the default ciphers. Also the OpenSsl default ciphers are expressed in terms of the OpenSSL cipher name conventions, which is not correct and may be exposed to the end user. OpenSSL should also use the RFC cipher names like the JDK defaults. Modifications: - Move the default cipher definition to a common location and use it in JDK and OpenSSL initialization - OpenSSL should not expose OpenSSL cipher names externally Result: Common initialization and OpenSSL doesn't expose custom cipher names.
2017-07-12 21:53:39 +02:00
Fixed default OpenSsl cipher suites Motivation: The default enabled cipher suites of the OpenSsl engine are not set to SslUtils#DEFAULT_CIPHER_SUITES. Instead all available cipher suites are enabled. This should happen only as a fallback. Modifications: Moved the line in the static initializer in OpenSsl which adds the SslUtils#DEFAULT_CIPHER_SUITES to the default enabled cipher suites up before the fallback. Result: The default enabled cipher suites of the OpenSsl engine are set to the available ones of the SslUtils#DEFAULT_CIPHER_SUITES. The default enabled cipher suites of the OpenSsl engine are only set to all available cipher suites if no one of the SslUtils#DEFAULT_CIPHER_SUITES is supported.
2017-11-28 12:04:38 +01:00
addIfSupported(availableJavaCipherSuites, defaultCiphers, DEFAULT_CIPHER_SUITES);
Allow to use TLSv1.3 with netty-tcnative withe java versions prior to 11. (#8394) Motivation: At the moment it's only possible to use TLSv1.3 with netty-tcnative if Java 11 is used. It should be possible to do so even with Java 8, 9 and 10. Modification: Add a workaround to be able to use TLSv1.3 also when using Java version prior to Java 11 and the default X509ExtendedTrustManager is used. Result: Be able to use TLSv1.3 also with past versions of Java.
2018-10-18 13:50:12 +02:00
addIfSupported(availableJavaCipherSuites, defaultCiphers, TLSV13_CIPHER_SUITES);
Unify default cipher suites betweek JDK and OpenSSL Motivation: Currently the default cipher suites are set independently between JDK and OpenSSL. We should use a common approach to setting the default ciphers. Also the OpenSsl default ciphers are expressed in terms of the OpenSSL cipher name conventions, which is not correct and may be exposed to the end user. OpenSSL should also use the RFC cipher names like the JDK defaults. Modifications: - Move the default cipher definition to a common location and use it in JDK and OpenSSL initialization - OpenSSL should not expose OpenSSL cipher names externally Result: Common initialization and OpenSSL doesn't expose custom cipher names.
2017-07-12 21:53:39 +02:00
useFallbackCiphersIfDefaultIsEmpty(defaultCiphers, availableJavaCipherSuites);
DEFAULT_CIPHERS = Collections.unmodifiableList(defaultCiphers);
OpenSslEngine.getSupportedCipherSuites() must return java names as well. Motivation: At the moment OpenSslEngine.getSupportedCipherSuites() only return the original openssl cipher names and not the java names. We need also include the java names. Modifications: Correctly return the java names as well. Result: Correct implementation of OpenSslEngine.getSupportedCipherSuites()
2016-06-22 15:46:45 +02:00
AVAILABLE_JAVA_CIPHER_SUITES = Collections.unmodifiableSet(availableJavaCipherSuites);
Java 8 migration: Use diamond operator (#8749) Motivation: We can use the diamond operator these days. Modification: Use diamond operator whenever possible. Result: More modern code and less boiler-plate.
2019-01-22 16:07:26 +01:00
final Set<String> availableCipherSuites = new LinkedHashSet<>(
OpenSslEngine.getSupportedCipherSuites() must return java names as well. Motivation: At the moment OpenSslEngine.getSupportedCipherSuites() only return the original openssl cipher names and not the java names. We need also include the java names. Modifications: Correctly return the java names as well. Result: Correct implementation of OpenSslEngine.getSupportedCipherSuites()
2016-06-22 15:46:45 +02:00
AVAILABLE_OPENSSL_CIPHER_SUITES.size() + AVAILABLE_JAVA_CIPHER_SUITES.size());
Remove some dead-code and cleanup
2017-05-09 12:53:55 +02:00
availableCipherSuites.addAll(AVAILABLE_OPENSSL_CIPHER_SUITES);
availableCipherSuites.addAll(AVAILABLE_JAVA_CIPHER_SUITES);
OpenSslEngine.getSupportedCipherSuites() must return java names as well. Motivation: At the moment OpenSslEngine.getSupportedCipherSuites() only return the original openssl cipher names and not the java names. We need also include the java names. Modifications: Correctly return the java names as well. Result: Correct implementation of OpenSslEngine.getSupportedCipherSuites()
2016-06-22 15:46:45 +02:00
AVAILABLE_CIPHER_SUITES = availableCipherSuites;
Add support for KeyManagerFactory when using SslProvider.OpenSsl. Motivation: To be able to use SslProvider.OpenSsl with existing java apps that use the JDK SSL API we need to also provide a way to use it with an existing KeyManagerFactory. Modification: Make use of new tcnative apis and so hook in KeyManagerFactory. Result: SslProvider.OpenSsl can be used with KeyManagerFactory as well.
2016-06-20 14:07:53 +02:00
SUPPORTS_KEYMANAGER_FACTORY = supportsKeyManagerFactory;
Allow to explicit disable usage of KeyManagerFactory when using OpenSsl Motivation: Sometimes it may be useful to explicit disable the usage of the KeyManagerFactory when using OpenSsl. Modifications: Add io.netty.handler.ssl.openssl.useKeyManagerFactory which can be used to explicit disable KeyManagerFactory usage. Result: More flexible usage.
2016-08-01 22:17:30 +02:00
USE_KEYMANAGER_FACTORY = useKeyManagerFactory;
Correctly detect which protocols are supported when using OpenSSL Motivation: We failed to properly test if a protocol is supported on an OpenSSL installation and just always returned all protocols. Modifications: - Detect which protocols are supported on a platform. - Skip protocols in tests when not supported. This fixes a build error on some platforms introduced by [#6276]. Result: Correctly return only the supported protocols
2017-01-27 11:54:11 +01:00
Java 8 migration: Use diamond operator (#8749) Motivation: We can use the diamond operator these days. Modification: Use diamond operator whenever possible. Result: More modern code and less boiler-plate.
2019-01-22 16:07:26 +01:00
Set<String> protocols = new LinkedHashSet<>(6);
Correctly detect which protocols are supported when using OpenSSL Motivation: We failed to properly test if a protocol is supported on an OpenSSL installation and just always returned all protocols. Modifications: - Detect which protocols are supported on a platform. - Skip protocols in tests when not supported. This fixes a build error on some platforms introduced by [#6276]. Result: Correctly return only the supported protocols
2017-01-27 11:54:11 +01:00
// Seems like there is no way to explicitly disable SSLv2Hello in openssl so it is always enabled
protocols.add(PROTOCOL_SSL_V2_HELLO);
Correctly detect if protocol is enabled when using netty-tcnative (#7940) Motivation: We sometimes did not correctly detect when a protocol is not enabled when using netty-tcnative as we did not take into account when the option flag is 0 (as for example in BoringSSL for SSLv2). Modifications: - Correctly take an option flag with 0 into account. - Add unit tests. Result: Fixes https://github.com/netty/netty/issues/7935.
2018-05-16 07:23:55 +02:00
if (doesSupportProtocol(SSL.SSL_PROTOCOL_SSLV2, SSL.SSL_OP_NO_SSLv2)) {
Switch to netty-tcnative 2.0.0 which uses different package names Motivation: Previous versions of netty-tcnative used the org.apache.tomcat namespace which could lead to problems when a user tried to use tomcat and netty in the same app. Modifications: Use netty-tcnative which now uses a different namespace and adjust code to some API changes. Result: Its now possible to use netty-tcnative even when running together with tomcat.
2016-08-10 08:55:30 +02:00
protocols.add(PROTOCOL_SSL_V2);
}
Correctly detect if protocol is enabled when using netty-tcnative (#7940) Motivation: We sometimes did not correctly detect when a protocol is not enabled when using netty-tcnative as we did not take into account when the option flag is 0 (as for example in BoringSSL for SSLv2). Modifications: - Correctly take an option flag with 0 into account. - Add unit tests. Result: Fixes https://github.com/netty/netty/issues/7935.
2018-05-16 07:23:55 +02:00
if (doesSupportProtocol(SSL.SSL_PROTOCOL_SSLV3, SSL.SSL_OP_NO_SSLv3)) {
Switch to netty-tcnative 2.0.0 which uses different package names Motivation: Previous versions of netty-tcnative used the org.apache.tomcat namespace which could lead to problems when a user tried to use tomcat and netty in the same app. Modifications: Use netty-tcnative which now uses a different namespace and adjust code to some API changes. Result: Its now possible to use netty-tcnative even when running together with tomcat.
2016-08-10 08:55:30 +02:00
protocols.add(PROTOCOL_SSL_V3);
}
Correctly detect if protocol is enabled when using netty-tcnative (#7940) Motivation: We sometimes did not correctly detect when a protocol is not enabled when using netty-tcnative as we did not take into account when the option flag is 0 (as for example in BoringSSL for SSLv2). Modifications: - Correctly take an option flag with 0 into account. - Add unit tests. Result: Fixes https://github.com/netty/netty/issues/7935.
2018-05-16 07:23:55 +02:00
if (doesSupportProtocol(SSL.SSL_PROTOCOL_TLSV1, SSL.SSL_OP_NO_TLSv1)) {
Switch to netty-tcnative 2.0.0 which uses different package names Motivation: Previous versions of netty-tcnative used the org.apache.tomcat namespace which could lead to problems when a user tried to use tomcat and netty in the same app. Modifications: Use netty-tcnative which now uses a different namespace and adjust code to some API changes. Result: Its now possible to use netty-tcnative even when running together with tomcat.
2016-08-10 08:55:30 +02:00
protocols.add(PROTOCOL_TLS_V1);
Correctly detect which protocols are supported when using OpenSSL Motivation: We failed to properly test if a protocol is supported on an OpenSSL installation and just always returned all protocols. Modifications: - Detect which protocols are supported on a platform. - Skip protocols in tests when not supported. This fixes a build error on some platforms introduced by [#6276]. Result: Correctly return only the supported protocols
2017-01-27 11:54:11 +01:00
}
Correctly detect if protocol is enabled when using netty-tcnative (#7940) Motivation: We sometimes did not correctly detect when a protocol is not enabled when using netty-tcnative as we did not take into account when the option flag is 0 (as for example in BoringSSL for SSLv2). Modifications: - Correctly take an option flag with 0 into account. - Add unit tests. Result: Fixes https://github.com/netty/netty/issues/7935.
2018-05-16 07:23:55 +02:00
if (doesSupportProtocol(SSL.SSL_PROTOCOL_TLSV1_1, SSL.SSL_OP_NO_TLSv1_1)) {
Switch to netty-tcnative 2.0.0 which uses different package names Motivation: Previous versions of netty-tcnative used the org.apache.tomcat namespace which could lead to problems when a user tried to use tomcat and netty in the same app. Modifications: Use netty-tcnative which now uses a different namespace and adjust code to some API changes. Result: Its now possible to use netty-tcnative even when running together with tomcat.
2016-08-10 08:55:30 +02:00
protocols.add(PROTOCOL_TLS_V1_1);
}
Correctly detect if protocol is enabled when using netty-tcnative (#7940) Motivation: We sometimes did not correctly detect when a protocol is not enabled when using netty-tcnative as we did not take into account when the option flag is 0 (as for example in BoringSSL for SSLv2). Modifications: - Correctly take an option flag with 0 into account. - Add unit tests. Result: Fixes https://github.com/netty/netty/issues/7935.
2018-05-16 07:23:55 +02:00
if (doesSupportProtocol(SSL.SSL_PROTOCOL_TLSV1_2, SSL.SSL_OP_NO_TLSv1_2)) {
Switch to netty-tcnative 2.0.0 which uses different package names Motivation: Previous versions of netty-tcnative used the org.apache.tomcat namespace which could lead to problems when a user tried to use tomcat and netty in the same app. Modifications: Use netty-tcnative which now uses a different namespace and adjust code to some API changes. Result: Its now possible to use netty-tcnative even when running together with tomcat.
2016-08-10 08:55:30 +02:00
protocols.add(PROTOCOL_TLS_V1_2);
}
Add support for TLSv1.3 (#8293) 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.
2018-10-17 08:35:35 +02:00
// This is only supported by java11 and later.
Allow to use TLSv1.3 with netty-tcnative withe java versions prior to 11. (#8394) Motivation: At the moment it's only possible to use TLSv1.3 with netty-tcnative if Java 11 is used. It should be possible to do so even with Java 8, 9 and 10. Modification: Add a workaround to be able to use TLSv1.3 also when using Java version prior to Java 11 and the default X509ExtendedTrustManager is used. Result: Be able to use TLSv1.3 also with past versions of Java.
2018-10-18 13:50:12 +02:00
if (tlsv13Supported && doesSupportProtocol(SSL.SSL_PROTOCOL_TLSV1_3, SSL.SSL_OP_NO_TLSv1_3)) {
Add support for TLSv1.3 (#8293) 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.
2018-10-17 08:35:35 +02:00
protocols.add(PROTOCOL_TLS_V1_3);
TLSV13_SUPPORTED = true;
} else {
TLSV13_SUPPORTED = false;
}
Correctly detect which protocols are supported when using OpenSSL Motivation: We failed to properly test if a protocol is supported on an OpenSSL installation and just always returned all protocols. Modifications: - Detect which protocols are supported on a platform. - Skip protocols in tests when not supported. This fixes a build error on some platforms introduced by [#6276]. Result: Correctly return only the supported protocols
2017-01-27 11:54:11 +01:00
SUPPORTED_PROTOCOLS_SET = Collections.unmodifiableSet(protocols);
Correctly detect if Ocsp is supported Motivation: We only used the openssl version to detect if Ocsp is supported or not which is not good enough as even the version is correct it may be compiled without support for OCSP (like for example on ubuntu). Modifications: Try to enable OCSP while static init OpenSsl and based on if this works return true or false when calling OpenSsl.isOcspSupported(). Result: Correctly detect if OSCP is supported.
2017-05-09 11:41:04 +02:00
SUPPORTS_OCSP = doesSupportOcsp();
Unify default cipher suites betweek JDK and OpenSSL Motivation: Currently the default cipher suites are set independently between JDK and OpenSSL. We should use a common approach to setting the default ciphers. Also the OpenSsl default ciphers are expressed in terms of the OpenSSL cipher name conventions, which is not correct and may be exposed to the end user. OpenSSL should also use the RFC cipher names like the JDK defaults. Modifications: - Move the default cipher definition to a common location and use it in JDK and OpenSSL initialization - OpenSSL should not expose OpenSSL cipher names externally Result: Common initialization and OpenSSL doesn't expose custom cipher names.
2017-07-12 21:53:39 +02:00
if (logger.isDebugEnabled()) {
Correctly detect if protocol is enabled when using netty-tcnative (#7940) Motivation: We sometimes did not correctly detect when a protocol is not enabled when using netty-tcnative as we did not take into account when the option flag is 0 (as for example in BoringSSL for SSLv2). Modifications: - Correctly take an option flag with 0 into account. - Add unit tests. Result: Fixes https://github.com/netty/netty/issues/7935.
2018-05-16 07:23:55 +02:00
logger.debug("Supported protocols (OpenSSL): {} ", SUPPORTED_PROTOCOLS_SET);
Unify default cipher suites betweek JDK and OpenSSL Motivation: Currently the default cipher suites are set independently between JDK and OpenSSL. We should use a common approach to setting the default ciphers. Also the OpenSsl default ciphers are expressed in terms of the OpenSSL cipher name conventions, which is not correct and may be exposed to the end user. OpenSSL should also use the RFC cipher names like the JDK defaults. Modifications: - Move the default cipher definition to a common location and use it in JDK and OpenSSL initialization - OpenSSL should not expose OpenSSL cipher names externally Result: Common initialization and OpenSSL doesn't expose custom cipher names.
2017-07-12 21:53:39 +02:00
logger.debug("Default cipher suites (OpenSSL): {}", DEFAULT_CIPHERS);
}
Implement OpenSslEngine.getSupportedCipherSuites() and get/setEnabledCipherSuites() Motivation: To make OpenSslEngine a full drop-in replacement, we need to implement getSupportedCipherSuites() and get/setEnabledCipherSuites(). Modifications: - Retrieve the list of the available cipher suites when initializing OpenSsl. - Improve CipherSuiteConverter to understand SRP - Add more test data to CipherSuiteConverterTest - Add bulk-conversion method to CipherSuiteConverter Result: OpenSslEngine should now be a drop-in replacement for JDK SSLEngineImpl for most cases.
2014-12-30 10:59:30 +01:00
} else {
Unify default cipher suites betweek JDK and OpenSSL Motivation: Currently the default cipher suites are set independently between JDK and OpenSSL. We should use a common approach to setting the default ciphers. Also the OpenSsl default ciphers are expressed in terms of the OpenSSL cipher name conventions, which is not correct and may be exposed to the end user. OpenSSL should also use the RFC cipher names like the JDK defaults. Modifications: - Move the default cipher definition to a common location and use it in JDK and OpenSSL initialization - OpenSSL should not expose OpenSSL cipher names externally Result: Common initialization and OpenSSL doesn't expose custom cipher names.
2017-07-12 21:53:39 +02:00
DEFAULT_CIPHERS = Collections.emptyList();
OpenSslEngine.getSupportedCipherSuites() must return java names as well. Motivation: At the moment OpenSslEngine.getSupportedCipherSuites() only return the original openssl cipher names and not the java names. We need also include the java names. Modifications: Correctly return the java names as well. Result: Correct implementation of OpenSslEngine.getSupportedCipherSuites()
2016-06-22 15:46:45 +02:00
AVAILABLE_OPENSSL_CIPHER_SUITES = Collections.emptySet();
AVAILABLE_JAVA_CIPHER_SUITES = Collections.emptySet();
Raise an exception when the specified cipher suite is not available Motivation: SSL_set_cipher_list() in OpenSSL does not fail as long as at least one cipher suite is available. It is different from the semantics of SSLEngine.setEnabledCipherSuites(), which raises an exception when the list contains an unavailable cipher suite. Modifications: - Add OpenSsl.isCipherSuiteAvailable(String) which checks the availability of a cipher suite - Raise an IllegalArgumentException when the specified cipher suite is not available Result: Fixed compatibility
2014-12-30 11:20:43 +01:00
AVAILABLE_CIPHER_SUITES = Collections.emptySet();
Add support for KeyManagerFactory when using SslProvider.OpenSsl. Motivation: To be able to use SslProvider.OpenSsl with existing java apps that use the JDK SSL API we need to also provide a way to use it with an existing KeyManagerFactory. Modification: Make use of new tcnative apis and so hook in KeyManagerFactory. Result: SslProvider.OpenSsl can be used with KeyManagerFactory as well.
2016-06-20 14:07:53 +02:00
SUPPORTS_KEYMANAGER_FACTORY = false;
Allow to explicit disable usage of KeyManagerFactory when using OpenSsl Motivation: Sometimes it may be useful to explicit disable the usage of the KeyManagerFactory when using OpenSsl. Modifications: Add io.netty.handler.ssl.openssl.useKeyManagerFactory which can be used to explicit disable KeyManagerFactory usage. Result: More flexible usage.
2016-08-01 22:17:30 +02:00
USE_KEYMANAGER_FACTORY = false;
Correctly detect which protocols are supported when using OpenSSL Motivation: We failed to properly test if a protocol is supported on an OpenSSL installation and just always returned all protocols. Modifications: - Detect which protocols are supported on a platform. - Skip protocols in tests when not supported. This fixes a build error on some platforms introduced by [#6276]. Result: Correctly return only the supported protocols
2017-01-27 11:54:11 +01:00
SUPPORTED_PROTOCOLS_SET = Collections.emptySet();
Correctly detect if Ocsp is supported Motivation: We only used the openssl version to detect if Ocsp is supported or not which is not good enough as even the version is correct it may be compiled without support for OCSP (like for example on ubuntu). Modifications: Try to enable OCSP while static init OpenSsl and based on if this works return true or false when calling OpenSsl.isOcspSupported(). Result: Correctly detect if OSCP is supported.
2017-05-09 11:41:04 +02:00
SUPPORTS_OCSP = false;
Add support for TLSv1.3 (#8293) 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.
2018-10-17 08:35:35 +02:00
TLSV13_SUPPORTED = false;
Add support for boringssl and TLSv1.3 (#8412) Motivation: 0ddc62cec0b4715ae37cef0e6a9f8c79d42d74e9 added support for TLSv1.3 when using openssl 1.1.1. Now that BoringSSL chromium-stable branch supports it as well we can also support it with netty-tcnative-boringssl-static. During this some unit tests failed with BoringSSL which was caused by not correctly handling flush() while the handshake is still in progress. Modification: - Upgrade netty-tcnative version which also supports TLSv1.3 when using BoringSSL - Correctly handle flush() when done while the handshake is still in progress in all cases. Result: Easier for people to enable TLSv1.3 when using native SSL impl. Ensure flush() while handshake is in progress will always be honored.
2018-10-27 00:29:49 +02:00
IS_BORINGSSL = false;
Correctly detect which protocols are supported when using OpenSSL Motivation: We failed to properly test if a protocol is supported on an OpenSSL installation and just always returned all protocols. Modifications: - Detect which protocols are supported on a platform. - Skip protocols in tests when not supported. This fixes a build error on some platforms introduced by [#6276]. Result: Correctly return only the supported protocols
2017-01-27 11:54:11 +01:00
}
}
Correctly init X509Certificate array when testing if we need to wrap the KeyManager due of TLSv1.3 (#8435) Motivation: 201e984cb3995d59cf8254f851f0ffb9090c2fea added support to use native TLSv1.3 support even with Java versions prior to 11. For this we try to detect if we need to wrap the used KeyManager or not. This testing code did create an X509Certificate[1] but does not correctly also set the certficiate on index 0. While this should be harmless we should better do the right thing and set it. Modifications: Correctly init the array. Result: Cleaner and more correct code.
2018-10-30 08:17:31 +01:00
/**
* Returns a self-signed {@link X509Certificate} for {@code netty.io}.
*/
static X509Certificate selfSignedCertificate() throws CertificateException {
Use SSL.setKeyMaterial(...) to test if the KeyManagerFactory is supported (#8985) Motivation: We use SSL.setKeyMaterial(...) in our implementation when using the KeyManagerFactory so we should also use it to detect if we can support KeyManagerFactory. Modifications: Use SSL.setKeyMaterial(...) as replacement for SSL.setCertificateBio(...) Result: Use the same method call to detect if KeyManagerFactory can be supported as we use in the real implementation.
2019-04-01 12:03:05 +02:00
return (X509Certificate) SslContext.X509_CERT_FACTORY.generateCertificate(new ByteArrayInputStream(CERT_BYTES));
Correctly init X509Certificate array when testing if we need to wrap the KeyManager due of TLSv1.3 (#8435) Motivation: 201e984cb3995d59cf8254f851f0ffb9090c2fea added support to use native TLSv1.3 support even with Java versions prior to 11. For this we try to detect if we need to wrap the used KeyManager or not. This testing code did create an X509Certificate[1] but does not correctly also set the certficiate on index 0. While this should be harmless we should better do the right thing and set it. Modifications: Correctly init the array. Result: Cleaner and more correct code.
2018-10-30 08:17:31 +01:00
}
Correctly detect if Ocsp is supported Motivation: We only used the openssl version to detect if Ocsp is supported or not which is not good enough as even the version is correct it may be compiled without support for OCSP (like for example on ubuntu). Modifications: Try to enable OCSP while static init OpenSsl and based on if this works return true or false when calling OpenSsl.isOcspSupported(). Result: Correctly detect if OSCP is supported.
2017-05-09 11:41:04 +02:00
private static boolean doesSupportOcsp() {
boolean supportsOcsp = false;
if (version() >= 0x10002000L) {
long sslCtx = -1;
try {
sslCtx = SSLContext.make(SSL.SSL_PROTOCOL_TLSV1_2, SSL.SSL_MODE_SERVER);
SSLContext.enableOcsp(sslCtx, false);
supportsOcsp = true;
} catch (Exception ignore) {
// ignore
} finally {
if (sslCtx != -1) {
SSLContext.free(sslCtx);
}
}
}
return supportsOcsp;
}
Correctly detect if protocol is enabled when using netty-tcnative (#7940) Motivation: We sometimes did not correctly detect when a protocol is not enabled when using netty-tcnative as we did not take into account when the option flag is 0 (as for example in BoringSSL for SSLv2). Modifications: - Correctly take an option flag with 0 into account. - Add unit tests. Result: Fixes https://github.com/netty/netty/issues/7935.
2018-05-16 07:23:55 +02:00
private static boolean doesSupportProtocol(int protocol, int opt) {
if (opt == 0) {
// If the opt is 0 the protocol is not supported. This is for example the case with BoringSSL and SSLv2.
return false;
}
Correctly detect which protocols are supported when using OpenSSL Motivation: We failed to properly test if a protocol is supported on an OpenSSL installation and just always returned all protocols. Modifications: - Detect which protocols are supported on a platform. - Skip protocols in tests when not supported. This fixes a build error on some platforms introduced by [#6276]. Result: Correctly return only the supported protocols
2017-01-27 11:54:11 +01:00
long sslCtx = -1;
try {
Switch to netty-tcnative 2.0.0 which uses different package names Motivation: Previous versions of netty-tcnative used the org.apache.tomcat namespace which could lead to problems when a user tried to use tomcat and netty in the same app. Modifications: Use netty-tcnative which now uses a different namespace and adjust code to some API changes. Result: Its now possible to use netty-tcnative even when running together with tomcat.
2016-08-10 08:55:30 +02:00
sslCtx = SSLContext.make(protocol, SSL.SSL_MODE_COMBINED);
Correctly detect which protocols are supported when using OpenSSL Motivation: We failed to properly test if a protocol is supported on an OpenSSL installation and just always returned all protocols. Modifications: - Detect which protocols are supported on a platform. - Skip protocols in tests when not supported. This fixes a build error on some platforms introduced by [#6276]. Result: Correctly return only the supported protocols
2017-01-27 11:54:11 +01:00
return true;
} catch (Exception ignore) {
return false;
} finally {
if (sslCtx != -1) {
SSLContext.free(sslCtx);
}
Implement OpenSslEngine.getSupportedCipherSuites() and get/setEnabledCipherSuites() Motivation: To make OpenSslEngine a full drop-in replacement, we need to implement getSupportedCipherSuites() and get/setEnabledCipherSuites(). Modifications: - Retrieve the list of the available cipher suites when initializing OpenSsl. - Improve CipherSuiteConverter to understand SRP - Add more test data to CipherSuiteConverterTest - Add bulk-conversion method to CipherSuiteConverter Result: OpenSslEngine should now be a drop-in replacement for JDK SSLEngineImpl for most cases.
2014-12-30 10:59:30 +01:00
}
Add an OpenSslEngine and the universal API for enabling SSL Motivation: Some users already use an SSLEngine implementation in finagle-native. It wraps OpenSSL to get higher SSL performance. However, to take advantage of it, finagle-native must be compiled manually, and it means we cannot pull it in as a dependency and thus we cannot test our SslHandler against the OpenSSL-based SSLEngine. For an instance, we had #2216. Because the construction procedures of JDK SSLEngine and OpenSslEngine are very different from each other, we also need to provide a universal way to enable SSL in a Netty application. Modifications: - Pull netty-tcnative in as an optional dependency. http://netty.io/wiki/forked-tomcat-native.html - Backport NativeLibraryLoader from 4.0 - Move OpenSSL-based SSLEngine implementation into our code base. - Copied from finagle-native; originally written by @jpinner et al. - Overall cleanup by @trustin. - Run all SslHandler tests with both default SSLEngine and OpenSslEngine - Add a unified API for creating an SSL context - SslContext allows you to create a new SSLEngine or a new SslHandler with your PKCS#8 key and X.509 certificate chain. - Add JdkSslContext and its subclasses - Add OpenSslServerContext - Add ApplicationProtocolSelector to ensure the future support for NPN (NextProtoNego) and ALPN (Application Layer Protocol Negotiation) on the client-side. - Add SimpleTrustManagerFactory to help a user write a TrustManagerFactory easily, which should be useful for those who need to write an alternative verification mechanism. For example, we can use it to implement an unsafe TrustManagerFactory that accepts self-signed certificates for testing purposes. - Add InsecureTrustManagerFactory and FingerprintTrustManager for quick and dirty testing - Add SelfSignedCertificate class which generates a self-signed X.509 certificate very easily. - Update all our examples to use SslContext.newClient/ServerContext() - SslHandler now logs the chosen cipher suite when handshake is finished. Result: - Cleaner unified API for configuring an SSL client and an SSL server regardless of its internal implementation. - When native libraries are available, OpenSSL-based SSLEngine implementation is selected automatically to take advantage of its performance benefit. - Examples take advantage of this modification and thus are cleaner.
2014-05-17 19:26:01 +02:00
}
/**
* Returns {@code true} if and only if
* <a href="http://netty.io/wiki/forked-tomcat-native.html">{@code netty-tcnative}</a> and its OpenSSL support
* are available.
*/
public static boolean isAvailable() {
return UNAVAILABILITY_CAUSE == null;
}
Add support for ALPN when using openssl + NPN client mode and support for CipherSuiteFilter Motivation: To support HTTP2 we need APLN support. This was not provided before when using OpenSslEngine, so SSLEngine (JDK one) was the only bet. Beside this CipherSuiteFilter was not supported Modifications: - Upgrade netty-tcnative and make use of new features to support ALPN and NPN in server and client mode. - Guard against segfaults after the ssl pointer is freed - support correctly different failure behaviours - add support for CipherSuiteFilter Result: Be able to use OpenSslEngine for ALPN / NPN for server and client.
2015-03-05 14:19:13 +01:00
/**
* Returns {@code true} if the used version of openssl supports
* <a href="https://tools.ietf.org/html/rfc7301">ALPN</a>.
*/
public static boolean isAlpnSupported() {
Allow to get version of available OpenSSL library Motivation: Sometimes it's useful to get informations about the available OpenSSL library that is used for the OpenSslEngine. Modifications: Add two new methods which allows to get the available OpenSSL version as either an int or an String. Result: Easy to access details about OpenSSL version.
2015-04-15 23:05:10 +02:00
return version() >= 0x10002000L;
}
OCSP stapling support for Netty using netty-tcnative. https://github.com/netty/netty-tcnative/pull/215 Motivation OCSP stapling (formally known as TLS Certificate Status Request extension) is alternative approach for checking the revocation status of X.509 Certificates. Servers can preemptively fetch the OCSP response from the CA's responder, cache it for some period of time, and pass it along during (a.k.a. staple) the TLS handshake. The client no longer has to reach out on its own to the CA to check the validity of a cetitficate. Some of the key benefits are: 1) Speed. The client doesn't have to crosscheck the certificate. 2) Efficiency. The Internet is no longer DDoS'ing the CA's OCSP responder servers. 3) Safety. Less operational dependence on the CA. Certificate owners can sustain short CA outages. 4) Privacy. The CA can lo longer track the users of a certificate. https://en.wikipedia.org/wiki/OCSP_stapling https://letsencrypt.org/2016/10/24/squarespace-ocsp-impl.html Modifications https://www.openssl.org/docs/man1.0.2/ssl/SSL_set_tlsext_status_type.html Result High-level API to enable OCSP stapling
2016-12-27 00:04:56 +01:00
/**
* Returns {@code true} if the used version of OpenSSL supports OCSP stapling.
*/
public static boolean isOcspSupported() {
Correctly detect if Ocsp is supported Motivation: We only used the openssl version to detect if Ocsp is supported or not which is not good enough as even the version is correct it may be compiled without support for OCSP (like for example on ubuntu). Modifications: Try to enable OCSP while static init OpenSsl and based on if this works return true or false when calling OpenSsl.isOcspSupported(). Result: Correctly detect if OSCP is supported.
2017-05-09 11:41:04 +02:00
return SUPPORTS_OCSP;
OCSP stapling support for Netty using netty-tcnative. https://github.com/netty/netty-tcnative/pull/215 Motivation OCSP stapling (formally known as TLS Certificate Status Request extension) is alternative approach for checking the revocation status of X.509 Certificates. Servers can preemptively fetch the OCSP response from the CA's responder, cache it for some period of time, and pass it along during (a.k.a. staple) the TLS handshake. The client no longer has to reach out on its own to the CA to check the validity of a cetitficate. Some of the key benefits are: 1) Speed. The client doesn't have to crosscheck the certificate. 2) Efficiency. The Internet is no longer DDoS'ing the CA's OCSP responder servers. 3) Safety. Less operational dependence on the CA. Certificate owners can sustain short CA outages. 4) Privacy. The CA can lo longer track the users of a certificate. https://en.wikipedia.org/wiki/OCSP_stapling https://letsencrypt.org/2016/10/24/squarespace-ocsp-impl.html Modifications https://www.openssl.org/docs/man1.0.2/ssl/SSL_set_tlsext_status_type.html Result High-level API to enable OCSP stapling
2016-12-27 00:04:56 +01:00
}
Allow to get version of available OpenSSL library Motivation: Sometimes it's useful to get informations about the available OpenSSL library that is used for the OpenSslEngine. Modifications: Add two new methods which allows to get the available OpenSSL version as either an int or an String. Result: Easy to access details about OpenSSL version.
2015-04-15 23:05:10 +02:00
/**
* Returns the version of the used available OpenSSL library or {@code -1} if {@link #isAvailable()}
* returns {@code false}.
*/
public static int version() {
Remove some dead-code and cleanup
2017-05-09 12:53:55 +02:00
return isAvailable() ? SSL.version() : -1;
Allow to get version of available OpenSSL library Motivation: Sometimes it's useful to get informations about the available OpenSSL library that is used for the OpenSslEngine. Modifications: Add two new methods which allows to get the available OpenSSL version as either an int or an String. Result: Easy to access details about OpenSSL version.
2015-04-15 23:05:10 +02:00
}
/**
* Returns the version string of the used available OpenSSL library or {@code null} if {@link #isAvailable()}
* returns {@code false}.
*/
public static String versionString() {
Remove some dead-code and cleanup
2017-05-09 12:53:55 +02:00
return isAvailable() ? SSL.versionString() : null;
Add support for ALPN when using openssl + NPN client mode and support for CipherSuiteFilter Motivation: To support HTTP2 we need APLN support. This was not provided before when using OpenSslEngine, so SSLEngine (JDK one) was the only bet. Beside this CipherSuiteFilter was not supported Modifications: - Upgrade netty-tcnative and make use of new features to support ALPN and NPN in server and client mode. - Guard against segfaults after the ssl pointer is freed - support correctly different failure behaviours - add support for CipherSuiteFilter Result: Be able to use OpenSslEngine for ALPN / NPN for server and client.
2015-03-05 14:19:13 +01:00
}
Add an OpenSslEngine and the universal API for enabling SSL Motivation: Some users already use an SSLEngine implementation in finagle-native. It wraps OpenSSL to get higher SSL performance. However, to take advantage of it, finagle-native must be compiled manually, and it means we cannot pull it in as a dependency and thus we cannot test our SslHandler against the OpenSSL-based SSLEngine. For an instance, we had #2216. Because the construction procedures of JDK SSLEngine and OpenSslEngine are very different from each other, we also need to provide a universal way to enable SSL in a Netty application. Modifications: - Pull netty-tcnative in as an optional dependency. http://netty.io/wiki/forked-tomcat-native.html - Backport NativeLibraryLoader from 4.0 - Move OpenSSL-based SSLEngine implementation into our code base. - Copied from finagle-native; originally written by @jpinner et al. - Overall cleanup by @trustin. - Run all SslHandler tests with both default SSLEngine and OpenSslEngine - Add a unified API for creating an SSL context - SslContext allows you to create a new SSLEngine or a new SslHandler with your PKCS#8 key and X.509 certificate chain. - Add JdkSslContext and its subclasses - Add OpenSslServerContext - Add ApplicationProtocolSelector to ensure the future support for NPN (NextProtoNego) and ALPN (Application Layer Protocol Negotiation) on the client-side. - Add SimpleTrustManagerFactory to help a user write a TrustManagerFactory easily, which should be useful for those who need to write an alternative verification mechanism. For example, we can use it to implement an unsafe TrustManagerFactory that accepts self-signed certificates for testing purposes. - Add InsecureTrustManagerFactory and FingerprintTrustManager for quick and dirty testing - Add SelfSignedCertificate class which generates a self-signed X.509 certificate very easily. - Update all our examples to use SslContext.newClient/ServerContext() - SslHandler now logs the chosen cipher suite when handshake is finished. Result: - Cleaner unified API for configuring an SSL client and an SSL server regardless of its internal implementation. - When native libraries are available, OpenSSL-based SSLEngine implementation is selected automatically to take advantage of its performance benefit. - Examples take advantage of this modification and thus are cleaner.
2014-05-17 19:26:01 +02:00
/**
* Ensure that <a href="http://netty.io/wiki/forked-tomcat-native.html">{@code netty-tcnative}</a> and
* its OpenSSL support are available.
*
* @throws UnsatisfiedLinkError if unavailable
*/
public static void ensureAvailability() {
if (UNAVAILABILITY_CAUSE != null) {
throw (Error) new UnsatisfiedLinkError(
"failed to load the required native library").initCause(UNAVAILABILITY_CAUSE);
}
}
/**
* Returns the cause of unavailability of
* <a href="http://netty.io/wiki/forked-tomcat-native.html">{@code netty-tcnative}</a> and its OpenSSL support.
*
* @return the cause if unavailable. {@code null} if available.
*/
public static Throwable unavailabilityCause() {
return UNAVAILABILITY_CAUSE;
}
OpenSslEngine.getSupportedCipherSuites() must return java names as well. Motivation: At the moment OpenSslEngine.getSupportedCipherSuites() only return the original openssl cipher names and not the java names. We need also include the java names. Modifications: Correctly return the java names as well. Result: Correct implementation of OpenSslEngine.getSupportedCipherSuites()
2016-06-22 15:46:45 +02:00
/**
* @deprecated use {@link #availableOpenSslCipherSuites()}
*/
@Deprecated
public static Set<String> availableCipherSuites() {
return availableOpenSslCipherSuites();
}
Implement OpenSslEngine.getSupportedCipherSuites() and get/setEnabledCipherSuites() Motivation: To make OpenSslEngine a full drop-in replacement, we need to implement getSupportedCipherSuites() and get/setEnabledCipherSuites(). Modifications: - Retrieve the list of the available cipher suites when initializing OpenSsl. - Improve CipherSuiteConverter to understand SRP - Add more test data to CipherSuiteConverterTest - Add bulk-conversion method to CipherSuiteConverter Result: OpenSslEngine should now be a drop-in replacement for JDK SSLEngineImpl for most cases.
2014-12-30 10:59:30 +01:00
/**
* Returns all the available OpenSSL cipher suites.
* Please note that the returned array may include the cipher suites that are insecure or non-functional.
*/
OpenSslEngine.getSupportedCipherSuites() must return java names as well. Motivation: At the moment OpenSslEngine.getSupportedCipherSuites() only return the original openssl cipher names and not the java names. We need also include the java names. Modifications: Correctly return the java names as well. Result: Correct implementation of OpenSslEngine.getSupportedCipherSuites()
2016-06-22 15:46:45 +02:00
public static Set<String> availableOpenSslCipherSuites() {
return AVAILABLE_OPENSSL_CIPHER_SUITES;
}
/**
* Returns all the available cipher suites (Java-style).
* Please note that the returned array may include the cipher suites that are insecure or non-functional.
*/
public static Set<String> availableJavaCipherSuites() {
return AVAILABLE_JAVA_CIPHER_SUITES;
Raise an exception when the specified cipher suite is not available Motivation: SSL_set_cipher_list() in OpenSSL does not fail as long as at least one cipher suite is available. It is different from the semantics of SSLEngine.setEnabledCipherSuites(), which raises an exception when the list contains an unavailable cipher suite. Modifications: - Add OpenSsl.isCipherSuiteAvailable(String) which checks the availability of a cipher suite - Raise an IllegalArgumentException when the specified cipher suite is not available Result: Fixed compatibility
2014-12-30 11:20:43 +01:00
}
/**
* Returns {@code true} if and only if the specified cipher suite is available in OpenSSL.
* Both Java-style cipher suite and OpenSSL-style cipher suite are accepted.
*/
public static boolean isCipherSuiteAvailable(String cipherSuite) {
Correctly convert between openssl / boringssl and java cipher names when using TLSv1.3 (#8485) Motivation: We did not correctly convert between openssl / boringssl and java ciphers when using TLV1.3 which had different effects when either using openssl or boringssl. - When using openssl and TLSv1.3 we always returned SSL_NULL_WITH_NULL_NULL as cipher name - When using boringssl with TLSv1.3 we always returned an incorrect constructed cipher name which does not match what is defined by Java. Modifications: - Add correct mappings in CipherSuiteConverter for both openssl and boringssl - Add unit tests for CipherSuiteConvert - Add unit in SSLEngine which checks that we do not return SSL_NULL_WITH_NULL_NULL ever and that server and client returns the same cipher name. Result: Fixes https://github.com/netty/netty/issues/8477.
2018-11-14 08:49:13 +01:00
String converted = CipherSuiteConverter.toOpenSsl(cipherSuite, IS_BORINGSSL);
Raise an exception when the specified cipher suite is not available Motivation: SSL_set_cipher_list() in OpenSSL does not fail as long as at least one cipher suite is available. It is different from the semantics of SSLEngine.setEnabledCipherSuites(), which raises an exception when the list contains an unavailable cipher suite. Modifications: - Add OpenSsl.isCipherSuiteAvailable(String) which checks the availability of a cipher suite - Raise an IllegalArgumentException when the specified cipher suite is not available Result: Fixed compatibility
2014-12-30 11:20:43 +01:00
if (converted != null) {
cipherSuite = converted;
}
OpenSslEngine.getSupportedCipherSuites() must return java names as well. Motivation: At the moment OpenSslEngine.getSupportedCipherSuites() only return the original openssl cipher names and not the java names. We need also include the java names. Modifications: Correctly return the java names as well. Result: Correct implementation of OpenSslEngine.getSupportedCipherSuites()
2016-06-22 15:46:45 +02:00
return AVAILABLE_OPENSSL_CIPHER_SUITES.contains(cipherSuite);
Implement OpenSslEngine.getSupportedCipherSuites() and get/setEnabledCipherSuites() Motivation: To make OpenSslEngine a full drop-in replacement, we need to implement getSupportedCipherSuites() and get/setEnabledCipherSuites(). Modifications: - Retrieve the list of the available cipher suites when initializing OpenSsl. - Improve CipherSuiteConverter to understand SRP - Add more test data to CipherSuiteConverterTest - Add bulk-conversion method to CipherSuiteConverter Result: OpenSslEngine should now be a drop-in replacement for JDK SSLEngineImpl for most cases.
2014-12-30 10:59:30 +01:00
}
Add support for KeyManagerFactory when using SslProvider.OpenSsl. Motivation: To be able to use SslProvider.OpenSsl with existing java apps that use the JDK SSL API we need to also provide a way to use it with an existing KeyManagerFactory. Modification: Make use of new tcnative apis and so hook in KeyManagerFactory. Result: SslProvider.OpenSsl can be used with KeyManagerFactory as well.
2016-06-20 14:07:53 +02:00
/**
* Returns {@code true} if {@link javax.net.ssl.KeyManagerFactory} is supported when using OpenSSL.
*/
public static boolean supportsKeyManagerFactory() {
return SUPPORTS_KEYMANAGER_FACTORY;
}
OpenSslEngine should respect hostname verification Motivation: OpenSSL doesn't automatically verify hostnames and requires extract method calls to enable this feature [1]. We should allow this to be configured. Modifications: - SSLParamaters#getEndpointIdentificationAlgorithm() should be respected and configured via tcnative interfaces. Result: OpenSslEngine respects hostname verification. [1] https://wiki.openssl.org/index.php/Hostname_validation
2017-02-17 05:25:25 +01:00
/**
Remove call to SSL.setHostNameValidation(...) as it is done in the TrustManager (#8981) Motivation: We do not need to call SSL.setHostNameValidation(...) as it should be done as part of the TrustManager implementation. This is consistent with the JDK implementation of SSLEngine. Modifications: Remove call to SSL.setHostNameValidation(...) Result: More consistent behaviour between our SSLEngine implementation and the one that comes with the JDK.
2019-04-01 21:02:36 +02:00
* Always returns {@code true} if {@link #isAvailable()} returns {@code true}.
*
* @deprecated Will be removed because hostname validation is always done by a
* {@link javax.net.ssl.TrustManager} implementation.
OpenSslEngine should respect hostname verification Motivation: OpenSSL doesn't automatically verify hostnames and requires extract method calls to enable this feature [1]. We should allow this to be configured. Modifications: - SSLParamaters#getEndpointIdentificationAlgorithm() should be respected and configured via tcnative interfaces. Result: OpenSslEngine respects hostname verification. [1] https://wiki.openssl.org/index.php/Hostname_validation
2017-02-17 05:25:25 +01:00
*/
Remove call to SSL.setHostNameValidation(...) as it is done in the TrustManager (#8981) Motivation: We do not need to call SSL.setHostNameValidation(...) as it should be done as part of the TrustManager implementation. This is consistent with the JDK implementation of SSLEngine. Modifications: Remove call to SSL.setHostNameValidation(...) Result: More consistent behaviour between our SSLEngine implementation and the one that comes with the JDK.
2019-04-01 21:02:36 +02:00
@Deprecated
OpenSslEngine should respect hostname verification Motivation: OpenSSL doesn't automatically verify hostnames and requires extract method calls to enable this feature [1]. We should allow this to be configured. Modifications: - SSLParamaters#getEndpointIdentificationAlgorithm() should be respected and configured via tcnative interfaces. Result: OpenSslEngine respects hostname verification. [1] https://wiki.openssl.org/index.php/Hostname_validation
2017-02-17 05:25:25 +01:00
public static boolean supportsHostnameValidation() {
Remove call to SSL.setHostNameValidation(...) as it is done in the TrustManager (#8981) Motivation: We do not need to call SSL.setHostNameValidation(...) as it should be done as part of the TrustManager implementation. This is consistent with the JDK implementation of SSLEngine. Modifications: Remove call to SSL.setHostNameValidation(...) Result: More consistent behaviour between our SSLEngine implementation and the one that comes with the JDK.
2019-04-01 21:02:36 +02:00
return isAvailable();
OpenSslEngine should respect hostname verification Motivation: OpenSSL doesn't automatically verify hostnames and requires extract method calls to enable this feature [1]. We should allow this to be configured. Modifications: - SSLParamaters#getEndpointIdentificationAlgorithm() should be respected and configured via tcnative interfaces. Result: OpenSslEngine respects hostname verification. [1] https://wiki.openssl.org/index.php/Hostname_validation
2017-02-17 05:25:25 +01:00
}
Allow to explicit disable usage of KeyManagerFactory when using OpenSsl Motivation: Sometimes it may be useful to explicit disable the usage of the KeyManagerFactory when using OpenSsl. Modifications: Add io.netty.handler.ssl.openssl.useKeyManagerFactory which can be used to explicit disable KeyManagerFactory usage. Result: More flexible usage.
2016-08-01 22:17:30 +02:00
static boolean useKeyManagerFactory() {
return USE_KEYMANAGER_FACTORY;
}
[#4828] OpenSslContext throws UnsupportedOperationException when Unsafe not available Motivation: OpenSslContext constructor fails with a UnsupportedOperationException if Unsafe is not present on the system. Modifications: Make OpenSslContext work also when Unsafe is not present by fallback to using JNI to get the memory address. Result: Using OpenSslContext also works on systems without Unsafe.
2016-02-03 20:50:57 +01:00
static long memoryAddress(ByteBuf buf) {
assert buf.isDirect();
return buf.hasMemoryAddress() ? buf.memoryAddress() : Buffer.address(buf.nioBuffer());
}
Add an OpenSslEngine and the universal API for enabling SSL Motivation: Some users already use an SSLEngine implementation in finagle-native. It wraps OpenSSL to get higher SSL performance. However, to take advantage of it, finagle-native must be compiled manually, and it means we cannot pull it in as a dependency and thus we cannot test our SslHandler against the OpenSSL-based SSLEngine. For an instance, we had #2216. Because the construction procedures of JDK SSLEngine and OpenSslEngine are very different from each other, we also need to provide a universal way to enable SSL in a Netty application. Modifications: - Pull netty-tcnative in as an optional dependency. http://netty.io/wiki/forked-tomcat-native.html - Backport NativeLibraryLoader from 4.0 - Move OpenSSL-based SSLEngine implementation into our code base. - Copied from finagle-native; originally written by @jpinner et al. - Overall cleanup by @trustin. - Run all SslHandler tests with both default SSLEngine and OpenSslEngine - Add a unified API for creating an SSL context - SslContext allows you to create a new SSLEngine or a new SslHandler with your PKCS#8 key and X.509 certificate chain. - Add JdkSslContext and its subclasses - Add OpenSslServerContext - Add ApplicationProtocolSelector to ensure the future support for NPN (NextProtoNego) and ALPN (Application Layer Protocol Negotiation) on the client-side. - Add SimpleTrustManagerFactory to help a user write a TrustManagerFactory easily, which should be useful for those who need to write an alternative verification mechanism. For example, we can use it to implement an unsafe TrustManagerFactory that accepts self-signed certificates for testing purposes. - Add InsecureTrustManagerFactory and FingerprintTrustManager for quick and dirty testing - Add SelfSignedCertificate class which generates a self-signed X.509 certificate very easily. - Update all our examples to use SslContext.newClient/ServerContext() - SslHandler now logs the chosen cipher suite when handshake is finished. Result: - Cleaner unified API for configuring an SSL client and an SSL server regardless of its internal implementation. - When native libraries are available, OpenSSL-based SSLEngine implementation is selected automatically to take advantage of its performance benefit. - Examples take advantage of this modification and thus are cleaner.
2014-05-17 19:26:01 +02:00
private OpenSsl() { }
Adding support for tcnative uber jar Motivation: We want to allow the use of an uber jar that contains the shared libraries for all platforms. Modifications: Modified OpenSsl to first check for a platform-specific lib before using the default lib. Result: uber support.
2016-02-19 18:20:35 +01:00
Support preloading of tcnative share lib Motivation: Some applications may use alternative methods of loading the tcnative JNI symbols. We should support this use case. Modifications: Separate the loading and initialzation of the tcnative library so that each can fail independently. Result: Fixes #5043
2016-04-11 18:06:48 +02:00
private static void loadTcNative() throws Exception {
Only load native transport if running architecture match the compiled library architecture. Motivation: We should only try to load the native artifacts if the architecture we are currently running on is the same as the one the native libraries were compiled for. Modifications: Include architecture in native lib name and append the current arch when trying to load these. This will fail then if its not the same as the arch of the compiled arch. Result: Fixes [#7150].
2017-08-29 14:13:49 +02:00
String os = PlatformDependent.normalizedOs();
String arch = PlatformDependent.normalizedArch();
Support preloading of tcnative share lib Motivation: Some applications may use alternative methods of loading the tcnative JNI symbols. We should support this use case. Modifications: Separate the loading and initialzation of the tcnative library so that each can fail independently. Result: Fixes #5043
2016-04-11 18:06:48 +02:00
Java 8 migration: Use diamond operator (#8749) Motivation: We can use the diamond operator these days. Modification: Use diamond operator whenever possible. Result: More modern code and less boiler-plate.
2019-01-22 16:07:26 +01:00
Set<String> libNames = new LinkedHashSet<>(4);
Take the architecture into account when loading netty-tcnative Motivation: We should ensure we only try to load the netty-tcnative version that was compiled for the architecture we are using. Modifications: Include architecture into native lib name. Result: Only load native lib if the architecture is supported.
2017-10-24 19:52:55 +02:00
String staticLibName = "netty_tcnative";
Support preloading of tcnative share lib Motivation: Some applications may use alternative methods of loading the tcnative JNI symbols. We should support this use case. Modifications: Separate the loading and initialzation of the tcnative library so that each can fail independently. Result: Fixes #5043
2016-04-11 18:06:48 +02:00
// First, try loading the platform-specific library. Platform-specific
// libraries will be available if using a tcnative uber jar.
Take the architecture into account when loading netty-tcnative Motivation: We should ensure we only try to load the netty-tcnative version that was compiled for the architecture we are using. Modifications: Include architecture into native lib name. Result: Only load native lib if the architecture is supported.
2017-10-24 19:52:55 +02:00
libNames.add(staticLibName + "_" + os + '_' + arch);
Only load native transport if running architecture match the compiled library architecture. Motivation: We should only try to load the native artifacts if the architecture we are currently running on is the same as the one the native libraries were compiled for. Modifications: Include architecture in native lib name and append the current arch when trying to load these. This will fail then if its not the same as the arch of the compiled arch. Result: Fixes [#7150].
2017-08-29 14:13:49 +02:00
if ("linux".equalsIgnoreCase(os)) {
Support preloading of tcnative share lib Motivation: Some applications may use alternative methods of loading the tcnative JNI symbols. We should support this use case. Modifications: Separate the loading and initialzation of the tcnative library so that each can fail independently. Result: Fixes #5043
2016-04-11 18:06:48 +02:00
// Fedora SSL lib so naming (libssl.so.10 vs libssl.so.1.0.0)..
Take the architecture into account when loading netty-tcnative Motivation: We should ensure we only try to load the netty-tcnative version that was compiled for the architecture we are using. Modifications: Include architecture into native lib name. Result: Only load native lib if the architecture is supported.
2017-10-24 19:52:55 +02:00
libNames.add(staticLibName + "_" + os + '_' + arch + "_fedora");
Support preloading of tcnative share lib Motivation: Some applications may use alternative methods of loading the tcnative JNI symbols. We should support this use case. Modifications: Separate the loading and initialzation of the tcnative library so that each can fail independently. Result: Fixes #5043
2016-04-11 18:06:48 +02:00
}
Take the architecture into account when loading netty-tcnative Motivation: We should ensure we only try to load the netty-tcnative version that was compiled for the architecture we are using. Modifications: Include architecture into native lib name. Result: Only load native lib if the architecture is supported.
2017-10-24 19:52:55 +02:00
libNames.add(staticLibName + "_" + arch);
libNames.add(staticLibName);
Support preloading of tcnative share lib Motivation: Some applications may use alternative methods of loading the tcnative JNI symbols. We should support this use case. Modifications: Separate the loading and initialzation of the tcnative library so that each can fail independently. Result: Fixes #5043
2016-04-11 18:06:48 +02:00
NativeLibraryLoader.loadFirstAvailable(SSL.class.getClassLoader(),
Replace toArray(new T[size]) with toArray(new T[0]) to eliminate zero-out and allow the VM to optimize. (#8075) Motivation: Using toArray(new T[0]) is usually the faster aproach these days. We should use it. See also https://shipilev.net/blog/2016/arrays-wisdom-ancients/#_conclusion. Modifications: Replace toArray(new T[size]) with toArray(new T[0]). Result: Faster code.
2018-06-29 07:56:04 +02:00
libNames.toArray(new String[0]));
Support preloading of tcnative share lib Motivation: Some applications may use alternative methods of loading the tcnative JNI symbols. We should support this use case. Modifications: Separate the loading and initialzation of the tcnative library so that each can fail independently. Result: Fixes #5043
2016-04-11 18:06:48 +02:00
}
OpenSSL (and so netty-tcnative) should allow to use custom engine. (#8050) Motivation: OpenSSL allows to use a custom engine for its cryptographic operations. We should allow the user to make use of it if needed. See also: https://www.openssl.org/docs/man1.0.2/crypto/engine.html. Modifications: Add new system property which can be used to specify the engine to use (null is the default and will use the build in default impl). Result: More flexible way of using OpenSSL.
2018-06-28 08:13:52 +02:00
private static boolean initializeTcNative(String engine) throws Exception {
return Library.initialize("provided", engine);
Support preloading of tcnative share lib Motivation: Some applications may use alternative methods of loading the tcnative JNI symbols. We should support this use case. Modifications: Separate the loading and initialzation of the tcnative library so that each can fail independently. Result: Fixes #5043
2016-04-11 18:06:48 +02:00
}
Ensure we only call ReferenceCountUtil.safeRelease(...) in finalize() if the refCnt() > 0 Motivation: We need to ensure we only call ReferenceCountUtil.safeRelease(...) in finalize() if the refCnt() > 0 as otherwise we will log a message about IllegalReferenceCountException. Modification: Check for a refCnt() > 0 before try to release Result: No more IllegalReferenceCountException produced when run finalize() on OpenSsl* objects that where explicit released before.
2016-08-09 18:14:22 +02:00
static void releaseIfNeeded(ReferenceCounted counted) {
if (counted.refCnt() > 0) {
ReferenceCountUtil.safeRelease(counted);
}
}
Add support for TLSv1.3 (#8293) 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.
2018-10-17 08:35:35 +02:00
static boolean isTlsv13Supported() {
return TLSV13_SUPPORTED;
}
Add support for boringssl and TLSv1.3 (#8412) Motivation: 0ddc62cec0b4715ae37cef0e6a9f8c79d42d74e9 added support for TLSv1.3 when using openssl 1.1.1. Now that BoringSSL chromium-stable branch supports it as well we can also support it with netty-tcnative-boringssl-static. During this some unit tests failed with BoringSSL which was caused by not correctly handling flush() while the handshake is still in progress. Modification: - Upgrade netty-tcnative version which also supports TLSv1.3 when using BoringSSL - Correctly handle flush() when done while the handshake is still in progress in all cases. Result: Easier for people to enable TLSv1.3 when using native SSL impl. Ensure flush() while handshake is in progress will always be honored.
2018-10-27 00:29:49 +02:00
static boolean isBoringSSL() {
return IS_BORINGSSL;
}
Add an OpenSslEngine and the universal API for enabling SSL Motivation: Some users already use an SSLEngine implementation in finagle-native. It wraps OpenSSL to get higher SSL performance. However, to take advantage of it, finagle-native must be compiled manually, and it means we cannot pull it in as a dependency and thus we cannot test our SslHandler against the OpenSSL-based SSLEngine. For an instance, we had #2216. Because the construction procedures of JDK SSLEngine and OpenSslEngine are very different from each other, we also need to provide a universal way to enable SSL in a Netty application. Modifications: - Pull netty-tcnative in as an optional dependency. http://netty.io/wiki/forked-tomcat-native.html - Backport NativeLibraryLoader from 4.0 - Move OpenSSL-based SSLEngine implementation into our code base. - Copied from finagle-native; originally written by @jpinner et al. - Overall cleanup by @trustin. - Run all SslHandler tests with both default SSLEngine and OpenSslEngine - Add a unified API for creating an SSL context - SslContext allows you to create a new SSLEngine or a new SslHandler with your PKCS#8 key and X.509 certificate chain. - Add JdkSslContext and its subclasses - Add OpenSslServerContext - Add ApplicationProtocolSelector to ensure the future support for NPN (NextProtoNego) and ALPN (Application Layer Protocol Negotiation) on the client-side. - Add SimpleTrustManagerFactory to help a user write a TrustManagerFactory easily, which should be useful for those who need to write an alternative verification mechanism. For example, we can use it to implement an unsafe TrustManagerFactory that accepts self-signed certificates for testing purposes. - Add InsecureTrustManagerFactory and FingerprintTrustManager for quick and dirty testing - Add SelfSignedCertificate class which generates a self-signed X.509 certificate very easily. - Update all our examples to use SslContext.newClient/ServerContext() - SslHandler now logs the chosen cipher suite when handshake is finished. Result: - Cleaner unified API for configuring an SSL client and an SSL server regardless of its internal implementation. - When native libraries are available, OpenSSL-based SSLEngine implementation is selected automatically to take advantage of its performance benefit. - Examples take advantage of this modification and thus are cleaner.
2014-05-17 19:26:01 +02:00
}