Git Product home page Git Product logo

conscrypt's Introduction

Conscrypt - A Java Security Provider

Conscrypt is a Java Security Provider (JSP) that implements parts of the Java Cryptography Extension (JCE) and Java Secure Socket Extension (JSSE). It uses BoringSSL to provide cryptographic primitives and Transport Layer Security (TLS) for Java applications on Android and OpenJDK. See the capabilities documentation for detailed information on what is provided.

The core SSL engine has borrowed liberally from the Netty project and their work on netty-tcnative, giving Conscrypt similar performance.

Homepage: conscrypt.org
Mailing List: [email protected]

Download

Conscrypt supports Java 7 or later on OpenJDK and Gingerbread (API Level 9) or later on Android. The build artifacts are available on Maven Central.

Download JARs

You can download the JARs directly from the Maven repositories.

OpenJDK (i.e. non-Android)

Native Classifiers

The OpenJDK artifacts are platform-dependent since each embeds a native library for a particular platform. We publish artifacts to Maven Central for the following platforms:

Classifier OS Architecture
linux-x86_64 Linux x86_64 (64-bit)
osx-x86_64 Mac x86_64 (64-bit)
windows-x86 Windows x86 (32-bit)
windows-x86_64 Windows x86_64 (64-bit)

Maven

Use the os-maven-plugin to add the dependency:

<build>
  <extensions>
    <extension>
      <groupId>kr.motd.maven</groupId>
      <artifactId>os-maven-plugin</artifactId>
      <version>1.4.1.Final</version>
    </extension>
  </extensions>
</build>

<dependency>
  <groupId>org.conscrypt</groupId>
  <artifactId>conscrypt-openjdk</artifactId>
  <version>2.5.2</version>
  <classifier>${os.detected.classifier}</classifier>
</dependency>

Gradle

Use the osdetector-gradle-plugin (which is a wrapper around the os-maven-plugin) to add the dependency:

buildscript {
  repositories {
    mavenCentral()
  }
  dependencies {
    classpath 'com.google.gradle:osdetector-gradle-plugin:1.4.0'
  }
}

// Use the osdetector-gradle-plugin
apply plugin: "com.google.osdetector"

dependencies {
  compile 'org.conscrypt:conscrypt-openjdk:2.5.2:' + osdetector.classifier
}

Uber JAR

For convenience, we also publish an Uber JAR to Maven Central that contains the shared libraries for all of the published platforms. While the overall size of the JAR is larger than depending on a platform-specific artifact, it greatly simplifies the task of dependency management for most platforms.

To depend on the uber jar, simply use the conscrypt-openjdk-uber artifacts.

Maven
<dependency>
  <groupId>org.conscrypt</groupId>
  <artifactId>conscrypt-openjdk-uber</artifactId>
  <version>2.5.2</version>
</dependency>
Gradle
dependencies {
  compile 'org.conscrypt:conscrypt-openjdk-uber:2.5.2'
}

Android

The Android AAR file contains native libraries for x86, x86_64, armeabi-v7a, and arm64-v8a.

Gradle

dependencies {
  implementation 'org.conscrypt:conscrypt-android:2.5.2'
}

How to Build

If you are making changes to Conscrypt, see the building instructions.

conscrypt's People

Contributors

15characterlimi avatar agl avatar bdcgoogle avatar bsidhom avatar captain5050 avatar cco3 avatar chadbrubaker avatar chih-hung avatar colincross avatar d-reidenbach avatar danalbert avatar danw avatar davidben avatar dvorak42 avatar enh-google avatar flooey avatar gcondra avatar justin-morey avatar koush avatar kpayson64 avatar kpet avatar kruton avatar narayank avatar nfuller avatar nmittler avatar paulduffin avatar prbprbprb avatar pszc avatar yqwed avatar yschimke avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

conscrypt's Issues

Investigate failing Netty tests

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

Investigate handshake performance

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

Allow conscrypt to be set as the primary security provider when loaded from a jar

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).

Expand benchmarks

Some ideas:

One inconsistent use of java.util.logging

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());

Support engine-based socket for all factory methods

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.

Copy to direct ByteBuffers during wrap()

Accessing Java arrays from JNI is horrifically slow. To get around this, Netty copies heap ByteBuffers 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.

SSLSocket via another SSLSocket not working

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)

  1. Create an SSLSocket over a normal TCP Socket (via SSLSocketFactory.createSocket())
  2. Over the newly created SSLSocket, create another SSLSocket (via SSLSocketFactory.createSocket())
  3. The second handshake will fail with the exception listed above

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!

SSLException: encrypted packet oversized

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?

Test client certificate request on renegotiation.

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.

Fix conscrypt-constants dependency issue

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.

NPE on Cancel during Connect

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)

Engine socket fails for createSocket()

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)

Remove OpenSSL <-> RFC cipher suite name maps

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.

Add conscrypt-android to Maven repo

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.

Revise session handling

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.

Document how to check for support

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.

Session cache should keep track of TLS version maximum

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.

Add integration tests

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.

Check for errors correctly

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.

Don't require clang

The current build on *nix is supposed to choose whetever is available between gcc and clang. However, it seems to simply require clang.

Add uber jar support

Support deployment of a conscrypt uber jar that has artifacts for windows, os x, and linux.

psk based TLS with openssl

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

Missing ciphers

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?

Consider making NativeConstants public

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

Deploy and use conscrypt

Hi,
I would like to know how to deploy conscypt in a windows based environment. I couldn't find any reference.

Thanks

Remove conscrypt-constants from the Maven repo

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.

Different behaviour with Engine socket

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

OpenSSLServerSocketImplTest.pingPong[ENGINE] encounters SSLException: Unexpected engine result CLOSED

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

conscrypt throws java.lang.IllegalArgumentException: Unknown cipher suite supported by native code: DH-DSS-AES256-GCM-SHA384

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

socket close waits for connect timeout

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);

Lock down public API

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.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.