google / conscrypt Goto Github PK
View Code? Open in Web Editor NEWConscrypt is a Java Security Provider that implements parts of the Java Cryptography Extension and Java Secure Socket Extension.
License: Apache License 2.0
Conscrypt is a Java Security Provider that implements parts of the Java Cryptography Extension and Java Secure Socket Extension.
License: Apache License 2.0
It looks like b6aab0c has broken the benchmarks which still rely on the old certificates for the Netty server.
Some ideas:
libconscrypt_openjdk_jni-linux-x86_64.so is 8 MB. The equivalent for OS X and Windows is 2 MB. Running strip
on the .so produces a 2 MB result. This may be caused by -g
being used in the build on Linux.
It would be useful with uber jars or single platform jars to have a canonical way to check that Conscrypt is supported for your platform. e.g. native libraries are loaded.
We seem to be trailing Netty tcnative in handshake performance. Profiling shows that the we're spending a lot of time in sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509Certificate[], String, SSLEngine)
. I suspect that Netty may be handling server verification differently.
Benchmark (a_cipher) (b_buffer) (c_engine) Mode Cnt Score Error Units
JmhEngineHandshakeBenchmark.hs TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 HEAP JDK thrpt 10 162.348 ± 10.382 ops/s
JmhEngineHandshakeBenchmark.hs TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 HEAP CONSCRYPT_UNPOOLED thrpt 10 716.748 ± 102.178 ops/s
JmhEngineHandshakeBenchmark.hs TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 HEAP CONSCRYPT_POOLED thrpt 10 742.854 ± 150.313 ops/s
JmhEngineHandshakeBenchmark.hs TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 HEAP NETTY thrpt 10 1236.226 ± 9.631 ops/s
JmhEngineHandshakeBenchmark.hs TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 HEAP NETTY_REF_CNT thrpt 10 1199.334 ± 97.748 ops/s
JmhEngineHandshakeBenchmark.hs TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 DIRECT JDK thrpt 10 163.654 ± 9.940 ops/s
JmhEngineHandshakeBenchmark.hs TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 DIRECT CONSCRYPT_UNPOOLED thrpt 10 755.786 ± 142.212 ops/s
JmhEngineHandshakeBenchmark.hs TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 DIRECT CONSCRYPT_POOLED thrpt 10 755.845 ± 135.823 ops/s
JmhEngineHandshakeBenchmark.hs TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 DIRECT NETTY thrpt 10 1247.186 ± 9.735 ops/s
JmhEngineHandshakeBenchmark.hs TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 DIRECT NETTY_REF_CNT thrpt 10 1217.178 ± 79.153 ops/s
NativeConstants
contains a lot of useful properties. Applications, such as Netty, could make use of these constants for performance optimizations as well as selecting appropriate buffer sizes when wrapping/unwrapping encrypted packets.
I propose that we make NativeConstants
public but marked Internal
to indicate the possible instability of the API.
@kruton WDYT?
FYI @Scottmitch
conscrypt-constants
is more of a build intermediate step and shouldn't be in a separate library since it's tied tightly to the native component of the library (i.e., each BoringSSL commit-ish may generate a different NativeConstants.java
file).
This should be bundled into the same .jar
or .aar
that contains the JNI libraries.
Currently it seems that conscrypt-android
doesn't deploy its .aar
files to the Maven repository. This is what is needed for Android deployments, so it should be on there.
It looks like a missing hook in the package/deploy steps.
Currently all of our tests run against the openjdk module. We should investigate running them all for Android as well (using emulators).
Some helpful links:
Getting Started with Testing
Testing Your App
Building Instrumented Unit Tests
Samples
Hi,
I'm trying to use a conscrypt based client to establish a TLS tunnel using psk.
I was able to access pskKeyManager via reflection (as you guys did in your unit test).
The TLS tunnel fails, here is the error message I have at openssl level :
SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac:s3_pkt.c:487
I'm suspecting this area of the code ,
`protected SecretKey getKey( String identityHint, String identity, Socket socket) {
return new SecretKeySpec("afakekey".getBytes(), "RAW");
}`
I don't know what to use as algorithm in the second argument.
here is my openssl test server configuration
openssl s_server \ -psk 1A1A1A1A1A1A1A1A1A1A1A1A1A1A1A1A \ -psk_hint Client_identity\ -cipher PSK-AES256-CBC-SHA \ -debug -state -nocert -accept 10443 -tls1 -www
Any hint ??
Thanks in advance
conscrypt fails while building AOSP under NixOS.
OS: NixOS
AOSP version: Copperhead 7.1.1r6 aosp_marlin
OpenJDK versions tried: 112b15, 122b3
Installed OpenSSL versions tried: OpenSSL 1.0.2j, OpenSSL 1.1.0, LibreSSL 2.5.0
make showcommands -j4
[ 25% 10601/42050] target Package: BasicDreams (out/targe...ct/marlin/obj/APPS/BasicDreams_intermediates/package.apk)
FAILED: /bin/bash -c "(touch out/target/product/marlin/obj/APPS/BasicDreams_intermediates/zipdummy ) && ((cd out/target/product/marlin/obj/APPS/BasicDreams_intermediates/ && jar cf package.apk zipdummy) ) && (zip -qd out/target/product/marlin/obj/APPS/BasicDreams_intermediates/package.apk zipdummy ) && (rm out/target/product/marlin/obj/APPS/BasicDreams_intermediates/zipdummy ) && (out/host/linux-x86/bin/aapt package -u -z --pseudo-localize -c en_US,en_US,cs_CZ,da_DK,de_AT,de_CH,de_DE,de_LI,el_GR,en_AU,en_CA,en_GB,en_NZ,en_SG,eo_EU,es_ES,fr_CA,fr_CH,fr_BE,fr_FR,it_CH,it_IT,ja_JP,ko_KR,nb_NO,nl_BE,nl_NL,pl_PL,pt_PT,ru_RU,sv_SE,tr_TR,zh_CN,zh_HK,zh_TW,am_ET,hi_IN,en_US,en_AU,en_IN,fr_FR,it_IT,es_ES,et_EE,de_DE,nl_NL,cs_CZ,pl_PL,ja_JP,zh_TW,zh_CN,zh_HK,ru_RU,ko_KR,nb_NO,es_US,da_DK,el_GR,tr_TR,pt_PT,pt_BR,sv_SE,bg_BG,ca_ES,en_GB,fi_FI,hi_IN,hr_HR,hu_HU,in_ID,iw_IL,lt_LT,lv_LV,ro_RO,sk_SK,sl_SI,sr_RS,uk_UA,vi_VN,tl_PH,ar_EG,fa_IR,th_TH,sw_TZ,ms_MY,af_ZA,zu_ZA,am_ET,en_XA,ar_XB,fr_CA,km_KH,lo_LA,ne_NP,si_LK,mn_MN,hy_AM,az_AZ,ka_GE,my_MM,mr_IN,ml_IN,is_IS,mk_MK,ky_KG,eu_ES,gl_ES,bn_BD,ta_IN,kn_IN,te_IN,uz_UZ,ur_PK,kk_KZ,sq_AL,gu_IN,pa_IN,be_BY,bs_BA,normal,xlarge,large --preferred-density 560dpi -M packages/screensavers/Basic/AndroidManifest.xml -S packages/screensavers/Basic/res -I out/target/common/obj/APPS/framework-res_intermediates/package-export.apk --min-sdk-version 25 --target-sdk-version 25 --product nosdcard --version-code 25 --version-name 7.1.1 --skip-symbols-without-default-localization -F out/target/product/marlin/obj/APPS/BasicDreams_intermediates/package.apk ) && (find out/target/common/obj/APPS/BasicDreams_intermediates/ -maxdepth 1 -name \"classes*.dex\" | sort | xargs zip -qjX out/target/product/marlin/obj/APPS/BasicDreams_intermediates/package.apk ) && (if [ -d out/target/common/obj/APPS/BasicDreams_intermediates/jack-rsc ] ; then find out/target/common/obj/APPS/BasicDreams_intermediates/jack-rsc -type f | sort | sed -e \"s?^out/target/common/obj/APPS/BasicDreams_intermediates/jack-rsc/? -C \\\"out/target/common/obj/APPS/BasicDreams_intermediates/jack-rsc\\\" \\\"?\" -e\"s/\$/\\\"/\" > out/target/product/marlin/obj/APPS/BasicDreams_intermediates/jack_res_jar_flags; if [ -s out/target/product/marlin/obj/APPS/BasicDreams_intermediates/jack_res_jar_flags ] ; then jar uf out/target/product/marlin/obj/APPS/BasicDreams_intermediates/package.apk @out/target/product/marlin/obj/APPS/BasicDreams_intermediates/jack_res_jar_flags; fi; fi ) && (mv out/target/product/marlin/obj/APPS/BasicDreams_intermediates/package.apk out/target/product/marlin/obj/APPS/BasicDreams_intermediates/package.apk.unsigned ) && (java -Djava.library.path=out/host/linux-x86/lib64 -jar out/host/linux-x86/framework/signapk.jar --min-sdk-version \$((out/host/linux-x86/bin/aapt dump badging out/target/product/marlin/obj/APPS/BasicDreams_intermediates/package.apk.unsigned 2>&1 | grep '^sdkVersion' || echo \"sdkVersion:'0'\") | cut -d\"'\" -f2 | sed -e s/^.*[^0-9].*\$/25/) build/target/product/security/testkey.x509.pem build/target/product/security/testkey.pk8 out/target/product/marlin/obj/APPS/BasicDreams_intermediates/package.apk.unsigned out/target/product/marlin/obj/APPS/BasicDreams_intermediates/package.apk.signed ) && (mv out/target/product/marlin/obj/APPS/BasicDreams_intermediates/package.apk.signed out/target/product/marlin/obj/APPS/BasicDreams_intermediates/package.apk )"
Exception in thread "main" java.lang.ExceptionInInitializerError
at org.conscrypt.OpenSSLBIOInputStream.<init>(OpenSSLBIOInputStream.java:34)
at org.conscrypt.OpenSSLX509Certificate.fromX509PemInputStream(OpenSSLX509Certificate.java:119)
at org.conscrypt.OpenSSLX509CertificateFactory$1.fromX509PemInputStream(OpenSSLX509CertificateFactory.java:220)
at org.conscrypt.OpenSSLX509CertificateFactory$1.fromX509PemInputStream(OpenSSLX509CertificateFactory.java:216)
at org.conscrypt.OpenSSLX509CertificateFactory$Parser.generateItem(OpenSSLX509CertificateFactory.java:94)
at org.conscrypt.OpenSSLX509CertificateFactory.engineGenerateCertificate(OpenSSLX509CertificateFactory.java:272)
at java.security.cert.CertificateFactory.generateCertificate(CertificateFactory.java:339)
at com.android.signapk.SignApk.readPublicKey(SignApk.java:182)
at com.android.signapk.SignApk.main(SignApk.java:1087)
Caused by: java.lang.IllegalArgumentException: Unknown cipher suite supported by native code: DH-DSS-AES256-GCM-SHA384
at org.conscrypt.NativeCrypto.<clinit>(NativeCrypto.java:750)
... 9 more
We probably want to wait a week or two for the change to trickle into Android and the internal tree first, but filing so we remember:
As of google/boringssl@6fff386, BoringSSL supports RFC names for cipher suites (TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, etc.) on equal footing to the OpenSSL names. You can use SSL_CIPHER_standard_name
to get the standard name of a cipher and the cipher suite config strings accept the standard names in place of the OpenSSL ones. I'm hoping this'll mean Conscrypt no longer needs to maintain those maps and can just pass the strings through.
Netty PR (netty/netty#6271) introduces support for Conscrypt. However some of the integration tests are failing and we should investigate before 1.0.0 to understand if it's a missing feature or a bug.
Potential bugs:
ConscryptJdkSslEngineInteropTest.testClientHostnameValidationFail
Missing features:
JdkConscryptSslEngineInteropTest.testMutualAuthValidClientCertChainTooLongFailOptionalClientAuth
JdkConscryptSslEngineInteropTest.testMutualAuthValidClientCertChainTooLongFailRequireClientAuth
I work on the Android team. While running conscrypt (*) tests on Android, we've run into an issue with conscrypt's experimental new SSL Socket implementation ("ENGINE") that leads to test failures, specifically in org.conscrypt.OpenSSLServerSocketImplTest.pingPong. The regular implementation ("DEFAULT") seems to work fine - we've only observed this issue for the experimental new "ENGINE" implementation.
(*) Our copy of conscrypt is repackaged under "com.android.org.conscrypt" and based I believe on conscrypt commit 9e569de , which is 23 days behind HEAD:
Further, we've only observed this issue on some specific devices (Nexus Player, which is x86 based, and Pixel C, which is ARM based) but not on others. I personally have been unable to reproduce this issue on a Nexus Player but others have, so there may be some additional factor that I'm unaware of.
What appears to happen during the test is that an SSLException("Unexpected engine result CLOSED") is occurs on the server thread in the background. TestServer$EchoProcessor.processMessage wraps that in a RuntimeException, which is not caught and therefore causes our test environment to shut down the entire test run (which is being executed on the main, test runner, thread). The root cause of this "Unexpected engine result CLOSED" is unclear.
Internally, we're tracking the impact of this issue on Android as bug 37271061.
I don't have good reproduction steps since I haven't personally been able to reproduce this issue yet. However, here's an log excerpt of run of Android's compatibility test suite (CTS) that encountered the issue:
04-12 03:58:47.956 28134 28150 I TestRunner: started: pingPong[DEFAULT](com.android.org.conscrypt.OpenSSLServerSocketImplTest)
04-12 03:58:47.956 28134 28134 I MonitoringInstr: Activities that are still in CREATED to STOPPED: 0
04-12 03:58:47.957 28134 28150 D CtsTestRunListener: Total memory : 42608719
04-12 03:58:47.957 28134 28150 D CtsTestRunListener: Used memory : 39804232
04-12 03:58:47.957 28134 28150 D CtsTestRunListener: Free memory : 2804487
04-12 03:58:47.957 28134 28150 D CtsTestRunListener: java.io.tmpdir is:/data/user/0/android.libcore.cts/cache
04-12 03:58:47.957 28134 28150 D CtsTestRunListener: About to .exec df
04-12 03:58:47.958 28134 28150 D CtsTestRunListener: .exec returned
04-12 03:58:47.958 28134 28150 D CtsTestRunListener: Stream reader created
04-12 03:58:47.964 29656 29656 W df : type=1400 audit(0.0:3075): avc: denied { getattr } for path="/dev/block" dev="tmpfs" ino=9112 scontext=u:r:untrusted_app:s0:c512,c768 tcontext=u:object_r:block_device:s0 tclass=dir permissive=0
04-12 03:58:47.965 29656 29656 W df : type=1400 audit(0.0:3076): avc: denied { getattr } for path="/dev/block" dev="tmpfs" ino=9112 scontext=u:r:untrusted_app:s0:c512,c768 tcontext=u:object_r:block_device:s0 tclass=dir permissive=0
04-12 03:58:47.966 28134 28150 D CtsTestRunListener: Filesystem 1K-blocks Used Available Use% Mounted on
04-12 03:58:47.966 28134 28150 D CtsTestRunListener: /dev/block/dm-2 25396556 2151812 23228360 9% /data
04-12 03:58:47.966 28134 28150 D CtsTestRunListener: In finally
04-12 03:58:47.966 28134 28150 D CtsTestRunListener: Now executing : com.android.org.conscrypt.OpenSSLServerSocketImplTest
04-12 03:58:47.977 28134 28150 I TestRunner: finished: pingPong[DEFAULT](com.android.org.conscrypt.OpenSSLServerSocketImplTest)
04-12 03:58:47.978 28134 28134 I MonitoringInstr: Activities that are still in CREATED to STOPPED: 0
04-12 03:58:47.978 28134 28150 I TestRunner: started: pingPong[ENGINE](com.android.org.conscrypt.OpenSSLServerSocketImplTest)
04-12 03:58:47.979 28134 28134 I MonitoringInstr: Activities that are still in CREATED to STOPPED: 0
04-12 03:58:47.991 28134 29658 W System.err: javax.net.ssl.SSLException: Unexpected engine result CLOSED
04-12 03:58:47.991 28134 29658 W System.err: at com.android.org.conscrypt.OpenSSLEngineSocketImpl$OutputStreamWrapper.write(OpenSSLEngineSocketImpl.java:369)
04-12 03:58:47.991 28134 29658 W System.err: at com.android.org.conscrypt.OpenSSLEngineSocketImpl$OutputStreamWrapper.write(OpenSSLEngineSocketImpl.java:352)
04-12 03:58:47.991 28134 29658 W System.err: at com.android.org.conscrypt.testing.TestServer$EchoProcessor.processMessage(TestServer.java:45)
04-12 03:58:47.991 28134 29658 W System.err: at com.android.org.conscrypt.testing.TestServer$ProcessTask.run(TestServer.java:131)
04-12 03:58:47.991 28134 29658 W System.err: at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1162)
04-12 03:58:47.991 28134 29658 W System.err: at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:636)
04-12 03:58:47.991 28134 29658 W System.err: at java.lang.Thread.run(Thread.java:764)
04-12 03:58:47.991 28134 28150 I TestRunner: finished: pingPong[ENGINE](com.android.org.conscrypt.OpenSSLServerSocketImplTest)
--------- beginning of crash
04-12 03:58:47.991 28134 29658 E AndroidRuntime: FATAL EXCEPTION: pool-1399-thread-1
04-12 03:58:47.991 28134 29658 E AndroidRuntime: Process: android.libcore.cts, PID: 28134
04-12 03:58:47.991 28134 29658 E AndroidRuntime: java.lang.RuntimeException: java.lang.RuntimeException: javax.net.ssl.SSLException: Unexpected engine result CLOSED
04-12 03:58:47.991 28134 29658 E AndroidRuntime: at com.android.org.conscrypt.testing.TestServer$ProcessTask.run(TestServer.java:135)
04-12 03:58:47.991 28134 29658 E AndroidRuntime: at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1162)
04-12 03:58:47.991 28134 29658 E AndroidRuntime: at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:636)
04-12 03:58:47.991 28134 29658 E AndroidRuntime: at java.lang.Thread.run(Thread.java:764)
04-12 03:58:47.991 28134 29658 E AndroidRuntime: Caused by: java.lang.RuntimeException: javax.net.ssl.SSLException: Unexpected engine result CLOSED
04-12 03:58:47.991 28134 29658 E AndroidRuntime: at com.android.org.conscrypt.testing.TestServer$EchoProcessor.processMessage(TestServer.java:48)
04-12 03:58:47.991 28134 29658 E AndroidRuntime: at com.android.org.conscrypt.testing.TestServer$ProcessTask.run(TestServer.java:131)
04-12 03:58:47.991 28134 29658 E AndroidRuntime: ... 3 more
04-12 03:58:47.991 28134 29658 E AndroidRuntime: Caused by: javax.net.ssl.SSLException: Unexpected engine result CLOSED
04-12 03:58:47.991 28134 29658 E AndroidRuntime: at com.android.org.conscrypt.OpenSSLEngineSocketImpl$OutputStreamWrapper.write(OpenSSLEngineSocketImpl.java:369)
04-12 03:58:47.991 28134 29658 E AndroidRuntime: at com.android.org.conscrypt.OpenSSLEngineSocketImpl$OutputStreamWrapper.write(OpenSSLEngineSocketImpl.java:352)
04-12 03:58:47.991 28134 29658 E AndroidRuntime: at com.android.org.conscrypt.testing.TestServer$EchoProcessor.processMessage(TestServer.java:45)
04-12 03:58:47.991 28134 29658 E AndroidRuntime: ... 4 more
04-12 03:58:47.992 28134 28134 I MonitoringInstr: Activities that are still in CREATED to STOPPED: 0
04-12 03:58:47.993 28134 28150 I TestRunner: started: test_handshakeWithSCTFromOCSPResponse(com.android.org.conscrypt.OpenSSLSocketImplTest)
04-12 03:58:47.994 28134 28134 I MonitoringInstr: Activities that are still in CREATED to STOPPED: 0
04-12 03:58:47.994 28134 28150 D CtsTestRunListener: Total memory : 42608719
04-12 03:58:47.994 28134 28150 D CtsTestRunListener: Used memory : 40675344
04-12 03:58:47.994 28134 28150 D CtsTestRunListener: Free memory : 1933375
04-12 03:58:47.994 28134 28150 D CtsTestRunListener: java.io.tmpdir is:/data/user/0/android.libcore.cts/cache
04-12 03:58:47.994 28134 28150 D CtsTestRunListener: About to .exec df
04-12 03:58:47.996 28134 28150 D CtsTestRunListener: .exec returned
04-12 03:58:47.996 28134 28150 D CtsTestRunListener: Stream reader created
04-12 03:58:48.001 9981 9993 W ActivityManager: Force-killing crashed app android.libcore.cts at watcher's request
04-12 03:58:48.002 28134 29658 I Process : Sending signal. PID: 28134 SIG: 9
04-12 03:58:48.002 9981 9995 E memtrack: Couldn't load memtrack module
04-12 03:58:48.003 9981 9995 W android.os.Debug: failed to get memory consumption info: -1
04-12 03:58:48.006 29660 29660 W df : type=1400 audit(0.0:3077): avc: denied { getattr } for path="/dev/block" dev="tmpfs" ino=9112 scontext=u:r:untrusted_app:s0:c512,c768 tcontext=u:object_r:block_device:s0 tclass=dir permissive=0
04-12 03:58:48.006 29660 29660 W df : type=1400 audit(0.0:3078): avc: denied { getattr } for path="/dev/block" dev="tmpfs" ino=9112 scontext=u:r:untrusted_app:s0:c512,c768 tcontext=u:object_r:block_device:s0 tclass=dir permissive=0
04-12 03:58:48.036 9981 9993 I ActivityManager: Process android.libcore.cts (pid 28134) has died
04-12 03:58:48.036 9981 9993 W ActivityManager: Crash of app android.libcore.cts running instrumentation ComponentInfo{android.libcore.cts/android.support.test.runner.AndroidJUnitRunner}
04-12 03:58:48.038 9981 9993 I ActivityManager: Force stopping android.libcore.cts appid=10227 user=0: finished inst
04-12 03:58:48.039 9981 29662 W Binder : Outgoing transactions from this process must be FLAG_ONEWAY
04-12 03:58:48.039 9981 29662 W Binder : java.lang.Throwable
04-12 03:58:48.039 9981 29662 W Binder : at android.os.BinderProxy.transact(Binder.java:712)
04-12 03:58:48.039 9981 29662 W Binder : at android.app.IInstrumentationWatcher$Stub$Proxy.instrumentationFinished(IInstrumentationWatcher.java:160)
04-12 03:58:48.039 9981 29662 W Binder : at com.android.server.am.InstrumentationReporter$MyThread.run(InstrumentationReporter.java:86)
04-12 03:58:48.039 28124 28124 D AndroidRuntime: Shutting down VM
what about NDK ? not mentioned here
and also maybe word about to change build tools version in build.gradle to the installed one
and for boring to instal ninja-build and golang clang++?
@nmittler discovered that there is a use for knowing when a handshake completed while implementing Conscrypt support in Netty (netty/netty#6271). That netty change could be simplified by adding something similar to SSLSocket
's HandshakeCompletedListener
to OpenSSLEngineImpl
.
Conscrypt's session management is not compatible with TLS 1.3 and has bugs around how handshake properties are extracted. (SSL_get_session
+ session->tlsext_hostname
should not be used for extracting the SNI. SSL_get_session
also should not be used for adding sessions to the session cache.)
The correct way to do this is to query handshake properties off the SSL
(SSL_get_servername
) and use a callback (SSL_CTX_sess_set_new_cb
) for storing sessions in the session cache. Conscrypt's problems seem to stem from the javax.net.ssl API exposing both SSLSocket.getSession
and SSLSocket.getHandshakeSession
without actually exposing an external session cache (i.e. it appears that session lookup for client and server is handled internally rather than the caller picking an SSLSession
for an SSLSocket
).
With an internal session cache, a Java SSLSession
should not be backed by SSL_SESSION
. It should be a pointer back to the SSLSocket
and extract properties off the SSL
directly. SSL_SESSION
management should be entirely internal and done in the standard way with the callback.
Currently, the conscrypt native libraries cannot be loaded from the .so embedded in the jar when conscrypt is primary security provider.
Here's a minimal code sample that exhibits the issue (when the conscrypt jar is added to the classpath):
import java.security.Security;
import javax.net.ssl.SSLContext;
import org.conscrypt.OpenSSLProvider;
public class ConscryptMain {
public static void main(String[] args) throws Exception {
Security.insertProviderAt(new OpenSSLProvider(), 1);
System.out.println(SSLContext.getDefault().getProvider());
}
}
It turns out that this is due to a cyclic dependency on the SecurityProvider itself within the OpenJDK JNI loader. org.conscrypt.NativeLibraryLoader.load()
calls java.io.File.createTempFile()
, which has an indirect dependency on java.security.SecureRandom
, which in turn depends on the security provider itself.
The problem goes away if the native library is loaded via java.library.path
or if the OpenSSLProvider
is placed in any position after 1 (since the default provider will usually include a SecureRandom PRNG).
From an in development PR of okhttp
square/okhttp#3262
CallTest.cancelDuringHttpsConnect:1849->cancelDuringConnect:1868 » NullPointer
java.lang.NullPointerException: fd == null
at org.conscrypt.NativeCrypto.SSL_shutdown(Native Method)
at org.conscrypt.OpenSSLSocketImpl.shutdownAndFreeSslNative(OpenSSLSocketImpl.java:1178)
at org.conscrypt.OpenSSLSocketImpl.startHandshake(OpenSSLSocketImpl.java:439)
at okhttp3.internal.connection.RealConnection.connectTls(RealConnection.java:268)
at okhttp3.internal.connection.RealConnection.establishProtocol(RealConnection.java:238)
at okhttp3.internal.connection.RealConnection.connect(RealConnection.java:149)
at okhttp3.internal.connection.StreamAllocation.findConnection(StreamAllocation.java:192)
at okhttp3.internal.connection.StreamAllocation.findHealthyConnection(StreamAllocation.java:121)
at okhttp3.internal.connection.StreamAllocation.newStream(StreamAllocation.java:100)
at okhttp3.internal.connection.ConnectInterceptor.intercept(ConnectInterceptor.java:42)
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:92)
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:67)
at okhttp3.internal.cache.CacheInterceptor.intercept(CacheInterceptor.java:93)
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:92)
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:67)
at okhttp3.internal.http.BridgeInterceptor.intercept(BridgeInterceptor.java:93)
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:92)
at okhttp3.internal.http.RetryAndFollowUpInterceptor.intercept(RetryAndFollowUpInterceptor.java:120)
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:92)
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:67)
at okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.java:179)
at okhttp3.RealCall.execute(RealCall.java:63)
at okhttp3.CallTest.cancelDuringConnect(CallTest.java:1868)
at okhttp3.CallTest.cancelDuringHttpsConnect(CallTest.java:1849)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at okhttp3.internal.io.InMemoryFileSystem$1.evaluate(InMemoryFileSystem.java:45)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:298)
at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:292)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.lang.Thread.run(Thread.java:745)
I am currently unable to run the tests on my ubuntu workstation due to missing standard ciphers. I get this error when attempting to run the tests:
java.lang.NoClassDefFoundError: Could not initialize class org.conscrypt.NativeCrypto
at org.conscrypt.NativeCryptoTest.tearDown(NativeCryptoTest.java:111)
This is thrown in NativeCrypto because Conscrypt's hard-coded list seems to have diverged from BoringSSL. The following values seem to be missing from Conscrypt:
AEAD-AES128-GCM-SHA256
AEAD-AES256-GCM-SHA384
AEAD-CHACHA20-POLY1305-SHA256
Which were added in October by this commit in order to update negotiation to the latest draft of TLS 1.3.
The thing that confuses me is why the build is working for @kruton as well as Travis. Perhaps both are using a version of BoringSSL that predates this change?
@kruton thoughts? Are you ok with just updating Conscrypt?
We need a separate integration tests that will be run against platform (i.e. bundled) Conscrypt.
Why:
We're currently using our unit tests for testing the native platform, but even though the packages are the same for the platform and tests (i.e. org.conscrypt) they are considered separate packages due to the fact that they came from separate class loaders (platform is loaded by the boot classloader). In order to allow us to lockdown the API (#142) by making internal classes package-private, we'll need to ensure that the tests run on Android do not attempt to access those classes. One option would be to always use java reflection in our unit tests, but this seems like overkill. Instead, we're going to cherry-pick a few tests to a new integration-test
module and have those be the tests that we run on Android.
Filing this so we have something to reference. NativeCryptoTest.test_SSL_do_handshake_clientCertificateRequested_throws_after_renegotiate worked in the OpenSSL days, but BoringSSL does not support renegotiation on the server. But support is sadly still needed on some clients.
BoringSSL itself tests that the renegotiation works using a custom implementation in Go, so Conscrypt can probably rely on that for most things, but we would still like to test that the Conscrypt-level callbacks work. Integrating Go into Conscrypt is likely more trouble than is worth it, so I propose we write the dumbest possible renegotiating test server.
It can be as lazy or inefficient as we need it to be (use g in ECDH so the secret is just the peer public key, don't parse ClientHello and use hardcoded negotiated parameters, etc.), since its only purpose in life is to drive BoringSSL into the right state. It should not be too much effort with enough simplifications.
Accessing Java arrays from JNI is horrifically slow. To get around this, Netty copies heap ByteBuffer
s to direct before calling to out to JNI. Because Conscrypt isn't copying, we currently trail Netty significantly in heap buffer benchmarks:
JmhEngineBenchmark.wrap HEAP TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 64 JDK thrpt 10 473014.066 ± 34550.739 ops/s
JmhEngineBenchmark.wrap HEAP TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 64 CONSCRYPT thrpt 10 622767.116 ± 12457.253 ops/s
JmhEngineBenchmark.wrap HEAP TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 64 NETTY thrpt 10 1029278.716 ± 56408.042 ops/s
JmhEngineBenchmark.wrap HEAP TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 512 JDK thrpt 10 106871.236 ± 6671.117 ops/s
JmhEngineBenchmark.wrap HEAP TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 512 CONSCRYPT thrpt 10 547494.836 ± 13512.987 ops/s
JmhEngineBenchmark.wrap HEAP TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 512 NETTY thrpt 10 996360.117 ± 32138.772 ops/s
JmhEngineBenchmark.wrap HEAP TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 4096 JDK thrpt 10 14862.208 ± 804.524 ops/s
JmhEngineBenchmark.wrap HEAP TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 4096 CONSCRYPT thrpt 10 290102.740 ± 28594.728 ops/s
JmhEngineBenchmark.wrap HEAP TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 4096 NETTY thrpt 10 381560.641 ± 23151.071 ops/s
Direct buffer allocation is expensive, however, and Netty gets around this by pooling buffers. We should consider adding some sort of BufferAllocator
interface that would allow an application to provide its own buffer allocation mechanism to conscrypt. If provided with an allocator, conscrypt could leverage this mechanism to allocate and dispose of direct buffers as needed.
OpenSSLSocketImplTest
has a couple of methods that are currently ignored. We should fix or remove them.
Filing this here so someone remembers to deal with it:
Conscrypt needs to make the equivalent change in error-handling to this CL:
https://android.googlesource.com/platform/libcore/+/ef742f1823504e4166f678d2651cccf16e711b1e
throwExceptionIfNecessary isn't the right pattern for these APIs. It's very easy to leave stuff in the error queue and, if there is anything left there, Conscrypt will incorrectly think a function failed. We've seen Conscrypt crashes in Chrome when we call to the X.509 code due to this.
From an in development PR of okhttp
square/okhttp#3262
I'm still debugging this, but raising in case there are known issues with Client Auth. Both of these could be bugs in OkHttpClient, OkHttp Mock Webserver or in Conscrypt. Or possibly just valid differences between providers.
runnable with mvn -Pconscrypt test
conscrypt-android-stubs
is a build intermediate step. It shouldn't be compiled into any shipped library and probably shouldn't be in the Maven repo at all.
Since we're bundling boringssl with our jni library, we should explicitly call out the commit of boringssl that we're bundling.
We can copy this solution from @carl-mastrangelo
The current build on *nix is supposed to choose whetever is available between gcc and clang. However, it seems to simply require clang.
select has a restriction of 64 sockets by default on windows. We should instead migrate to IO Completion Ports, which do not have this restriction.
Clean builds from master appear to be (sometimes) failing for me.
For example, running this on a freshly-checked out repo
./gradlew clean :conscrypt-openjdk:build
Results in this error message:
Could not determine the dependencies of task ':conscrypt-constants:javadoc'.
> Task with path 'runGen' not found in project ':conscrypt-constants'.
For some reason, this doesn't seem to be happening every time. I'm not sure what's causing it.
I ran into this error using the Ion library in the last few months, seems like it was introduced by 61a5351. For the last year we have used these URLs and it worked fine. I filed an issue in ion too.
When trying to fetch an image from an HTTPS url from Amazon S3 like https://s3-ap-southeast-1.amazonaws.com/radius-files/users/58883f0e88b1b1000a2ab5c5.jpg?1485324119111 I get this error:
javax.net.ssl.SSLException: encrypted packet oversized
at com.google.android.gms.org.conscrypt.OpenSSLEngineImpl.unwrap(:com.google.android.gms:496)
at com.google.android.gms.org.conscrypt.OpenSSLEngineImpl.unwrap(:com.google.android.gms:458)
at com.google.android.gms.org.conscrypt.OpenSSLEngineImpl.unwrap(:com.google.android.gms:423)
at com.koushikdutta.async.AsyncSSLSocketWrapper$5.onDataAvailable(AsyncSSLSocketWrapper.java:194)
at com.koushikdutta.async.Util.emitAllData(Util.java:23)
at com.koushikdutta.async.AsyncNetworkSocket.onReadable(AsyncNetworkSocket.java:152)
at com.koushikdutta.async.AsyncServer.runLoop(AsyncServer.java:789)
at com.koushikdutta.async.AsyncServer.run(AsyncServer.java:627)
at com.koushikdutta.async.AsyncServer.access$700(AsyncServer.java:41)
at com.koushikdutta.async.AsyncServer$13.run(AsyncServer.java:569)
Also if I make a request using a simple HttpUrlConnection it works fine. Fetching it using the browser works fine too. Any idea why it is running into that error?
There are a lot of classes/methods that are public that probably don't need to be. We should lock down as much of the API as we can before the 1.0.0. release.
There have been a few fixes/improvements lately in netty-tcnative. We should port those over to our engine.
A few that immediately stick out:
netty/netty-tcnative#205
(and related netty/netty#6123)
netty/netty-tcnative#207
netty/netty-tcnative#210
netty/netty-tcnative#216
(and related netty/netty#6201)
netty/netty#6118
netty/netty#6113
netty/netty#6090
netty/netty#6089
netty/netty#6439
SSLEngine benchmarks:
netty/netty#6360
This works without setUseEngineSocketByDefault(true)
import java.io.IOException;
import java.net.Socket;
import java.security.KeyManagementException;
import java.security.NoSuchAlgorithmException;
import javax.net.ssl.SSLContext;
import org.conscrypt.Conscrypt;
import org.conscrypt.OpenSSLProvider;
public class MainXX {
public static void main(String[] args)
throws NoSuchAlgorithmException, IOException, KeyManagementException {
Conscrypt.SocketFactories.setUseEngineSocketByDefault(true);
SSLContext sslContext = SSLContext.getInstance("TLS", new OpenSSLProvider());
sslContext.init(null, null, null);
Socket socket = sslContext.getSocketFactory().createSocket();
}
}
Exception in thread "main" java.net.SocketException: Socket is not connected.
at org.conscrypt.OpenSSLSocketImplWrapper.<init>(OpenSSLSocketImplWrapper.java:37)
at org.conscrypt.OpenSSLEngineSocketImpl.<init>(OpenSSLEngineSocketImpl.java:80)
at org.conscrypt.OpenSSLEngineSocketImpl.<init>(OpenSSLEngineSocketImpl.java:54)
at org.conscrypt.OpenSSLSocketFactoryImpl.createSocket(OpenSSLSocketFactoryImpl.java:84)
at okhttp3.MainXX.main(MainXX.java:19)
Support deployment of a conscrypt uber jar that has artifacts for windows, os x, and linux.
Just flagging, low priority, but seems peculiar.
07:15 $ git grep getLogger
platform/src/main/java/org/conscrypt/CertBlacklist.java: private static final Logger logger = Logger.getLogger(CertBlacklist.class.getName());
OpenSSLSocketFactoryImpl
currently only creates an engine-based socket when provided an underlying Socket
instance. In order to fully replace OpenSslSocketImpl
, we need to support the engine-socket creation in all cases.
I'm not sure if this is an accurate repro, but it shows the 10 second pause in #167
These are the defaults for OkHttp
connectTimeout = 10_000;
readTimeout = 10_000;
writeTimeout = 10_000;
diff --git a/openjdk/src/test/java/org/conscrypt/OpenSSLSocketImplTest.java b/openjdk/src/test/java/org/conscrypt/OpenSSLSocketImplTest.java
index 929629a3..93c55d15 100644
--- a/openjdk/src/test/java/org/conscrypt/OpenSSLSocketImplTest.java
+++ b/openjdk/src/test/java/org/conscrypt/OpenSSLSocketImplTest.java
@@ -370,8 +370,20 @@ public class OpenSSLSocketImplTest {
throw new IllegalArgumentException("Unexpected socketType " + socketType);
}
- simpl.setSoTimeout(1000);
- simpl.close();
+ simpl.setSoTimeout(10000);
+
+ new Thread(() -> {
+ try {
+ Thread.sleep(300l);
+ underlying.close();
+ } catch (IOException e) {
+ e.printStackTrace();
+ } catch (InterruptedException e) {
+ e.printStackTrace();
+ }
+ }).start();
+
+ simpl.startHandshake();
Field f = Socket.class.getDeclaredField("created");
f.setAccessible(true);
In order to do this, we need to verify correctness and performance of the new socket.
@kruton I'll assign this to both of us since I suspect this will require some work.
In the BoringSSL documents on session caching, it states:
Note that offering or accepting a session short-circuits most parameter negotiation. Resuming sessions across different configurations may result in surprising behavior. So, for instance, a client implementing a version fallback should shard its session cache by maximum protocol version.
Conscrypt should be changed to track maximum protocol version in its SSL session cache to avoid these gotchas.
Hi,
I would like to know how to deploy conscypt in a windows based environment. I couldn't find any reference.
Thanks
I'm still debugging this but raising in case you have some insight, or pending related changes. A OkHttp test passing with the normal socket, is failing differently with the engine socket impl.
java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
at java.net.SocketInputStream.read(SocketInputStream.java:171)
at java.net.SocketInputStream.read(SocketInputStream.java:141)
at org.conscrypt.OpenSSLEngineSocketImpl$InputStreamWrapper.readFromSocket(OpenSSLEngineSocketImpl.java:572)
at org.conscrypt.OpenSSLEngineSocketImpl$InputStreamWrapper.read(OpenSSLEngineSocketImpl.java:536)
at org.conscrypt.OpenSSLEngineSocketImpl$InputStreamWrapper.read(OpenSSLEngineSocketImpl.java:469)
at org.conscrypt.OpenSSLEngineSocketImpl.startHandshake(OpenSSLEngineSocketImpl.java:95)
at okhttp3.internal.connection.RealConnection.connectTls(RealConnection.java:270)
at okhttp3.internal.connection.RealConnection.establishProtocol(RealConnection.java:239)
at okhttp3.internal.connection.RealConnection.connect(RealConnection.java:150)
at okhttp3.internal.connection.StreamAllocation.findConnection(StreamAllocation.java:192)
at okhttp3.internal.connection.StreamAllocation.findHealthyConnection(StreamAllocation.java:121)
at okhttp3.internal.connection.StreamAllocation.newStream(StreamAllocation.java:100)
at okhttp3.internal.connection.ConnectInterceptor.intercept(ConnectInterceptor.java:42)
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:92)
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:67)
at okhttp3.internal.cache.CacheInterceptor.intercept(CacheInterceptor.java:93)
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:92)
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:67)
at okhttp3.internal.http.BridgeInterceptor.intercept(BridgeInterceptor.java:93)
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:92)
at okhttp3.internal.http.RetryAndFollowUpInterceptor.intercept(RetryAndFollowUpInterceptor.java:120)
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:92)
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:67)
at okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.java:179)
at okhttp3.RealCall.execute(RealCall.java:63)
at okhttp3.CallTest.recoverFromTlsHandshakeFailure_tlsFallbackScsvEnabled(CallTest.java:1085)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at okhttp3.internal.io.InMemoryFileSystem$1.evaluate(InMemoryFileSystem.java:45)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:298)
at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:292)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.lang.Thread.run(Thread.java:748)
Suppressed: javax.net.ssl.SSLHandshakeException: error:100003f2:SSL routines:OPENSSL_internal:SSLV3_ALERT_UNEXPECTED_MESSAGE
at org.conscrypt.OpenSSLEngineImpl.shutdownWithError(OpenSSLEngineImpl.java:1107)
at org.conscrypt.OpenSSLEngineImpl.sslReadErrorResult(OpenSSLEngineImpl.java:1098)
at org.conscrypt.OpenSSLEngineImpl.unwrap(OpenSSLEngineImpl.java:798)
at org.conscrypt.OpenSSLEngineImpl.unwrap(OpenSSLEngineImpl.java:636)
at org.conscrypt.OpenSSLEngineImpl.unwrap(OpenSSLEngineImpl.java:602)
at org.conscrypt.OpenSSLEngineSocketImpl$InputStreamWrapper.read(OpenSSLEngineSocketImpl.java:493)
... 39 more
cc @nmittler
It seems like creating an SSLSocket on top of another SSLSocket does not work using the Conscrypt SSL Provider.
When creating an SSLSocket over an existing SSLSocket via SSLSocketFactory.createSocket()
, the call to SSLSocket.startHandshake()
never returns.
The handshake for the underlying SSLSocket
and the SSLSocket
on top is done like shown in the following snippet. While it works fine for the first SSLSocket
(where a normal tcp Socket is passed as socket parameter), it doesn’t return for the second SSLSocket
(where the first SSLSocket
is passed as socket parameter). Neither the line printing "Handshake finished" nor the catch block are reached.
The very same code works fine with the JRE default SSL Provider.
private Socket doSSLHandshake(Socket socket, String host, int port) throws IOException {
// For easier debugging purpose, trust all certificates
TrustManager[] trustAllCerts = new TrustManager[]{
new X509TrustManager(){
public X509Certificate[] getAcceptedIssuers(){ return null; }
public void checkClientTrusted(X509Certificate[] certs, String authType) {}
public void checkServerTrusted(X509Certificate[] certs, String authType) {}
}
};
System.out.println("Doing SSL handshake with " + host + ":" + port);
try {
Provider provider = new OpenSSLProvider();
SSLContext sslContext = SSLContext.getInstance("TLS", provider);
sslContext.init(null, trustAllCerts, new SecureRandom());
SSLSocket sslSocket = (SSLSocket) sslContext.getSocketFactory().createSocket(socket, host, port, true);
sslSocket.startHandshake();
System.out.println("Handshake finished");
return sslSocket;
} catch (KeyManagementException | NoSuchAlgorithmException e) {
throw new IOException("Could not do SSL handshake: " + e);
}
}
Configuration:
Steps to reproduce the problem:
(Using a SocketFactory obtained from the Conscrypt Provider)
SSLSocketFactory.createSocket()
)SSLSocketFactory.createSocket()
)I have created a sample project that tries to connect to an HTTPS server via a Secure Web Proxy: https://github.com/FD-/SSLviaSSL/tree/conscrypt.
The issue might be related to Android issue #234291 (I actually came across the Conscrypt project by investigating this issue).
While the conscrypt branch in my repository contains details about the Conscrypt issue, the master branch describes the Android issue.
Expected result:
I'd expect creating an SSLSocket over an existing SSLSocket to work. The second handshake should return successfully.
Please let me know if you need further details on the issue!
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.