Support of Cipher Suite TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256

[beatrausch]

Is your feature request related to a problem?

Grpc-java does not support Cipher Suite TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256. So far grpc-java is maintaining its own optimized version of okhttp, thus it is not possible to switch to a new okhttp version that supports newer cipher suites.

Describe the solution you'd like

Add Cipher Suite TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 to the grpc-java forked version of okhttp or introduce a newer version of okhttp.

Describe alternatives you've considered

So for I don’t see any alternative.

Additional context

TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 is a hard requirement in my project. If this cipher suite is not supported I have to switch from grpc to a REST API which I really don’t like.

[dapengzhang0]

Introducing a newer version of okhttp is not something we will do in the short term.

Adding Cipher Suite TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 to the grpc-java forked version may only work on platforms with Android API level or JDK version high enough. @beatrausch would you like to send a PR?

[ejona86]

Yes, it should be added to our internal CipherSuite fork. And we should probably also enable it in our default connection spec.

[beatrausch]

Hi,

the PR should simply add TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256("TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256", 0xcca9, 7905, 9, 24) to the list of cipher suites as well as to
the list of approved cipher suites in the connection spec. I' am bit struggling about the sinceJavaVersion. According to the oracle doc it should be available with Java 9 JSSE.

Do you know a better source of cipher suite availability in certain java versions?

Regards,
Daniel

[ejona86]

CipherSuite doesn't actually use sinceJavaVersion; it just throws it away. All we need are the names. Feel free to add another CipherSuite constructor that only has the one javaName argument and use it instead.

I think we would just care about the ciphers listed for HTTP/2 in Netty are included, as we'd like them to be in sync for our default:

grpc-java/okhttp/src/main/java/io/grpc/okhttp/OkHttpChannelBuilder.java

Lines 104 to 118 in d2b9151

	static final ConnectionSpec INTERNAL_DEFAULT_CONNECTION_SPEC =
	new ConnectionSpec.Builder(ConnectionSpec.MODERN_TLS)
	.cipherSuites(
	// The following items should be sync with Netty's Http2SecurityUtil.CIPHERS.
	CipherSuite.TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
	CipherSuite.TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
	CipherSuite.TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
	CipherSuite.TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
	CipherSuite.TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
	CipherSuite.TLS_DHE_DSS_WITH_AES_128_GCM_SHA256,
	CipherSuite.TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,
	CipherSuite.TLS_DHE_DSS_WITH_AES_256_GCM_SHA384)
	.tlsVersions(TlsVersion.TLS_1_2)
	.supportsTlsExtensions(true)
	.build();

So I'd imagine it'd be as simple as adding TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 and TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256, and potentially the TLS 1.3 ciphers as well: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256. That should be pretty easy.

[beatrausch]

Hi,
I started with the implementation and introduced TLS 1.3 in the default connection spec. When running the tests, I get the following exception during the Http2OkhttpTest interop test.

Caused by: javax.net.ssl.SSLHandshakeException: Unknown authType: GENERIC
	at org.conscrypt.SSLUtils.toSSLHandshakeException(SSLUtils.java:361)
	at org.conscrypt.ConscryptEngine.convertException(ConscryptEngine.java:1136)
	at org.conscrypt.ConscryptEngine.readPlaintextData(ConscryptEngine.java:1091)
	at org.conscrypt.ConscryptEngine.unwrap(ConscryptEngine.java:878)
	at org.conscrypt.ConscryptEngine.unwrap(ConscryptEngine.java:749)
	at org.conscrypt.ConscryptEngine.unwrap(ConscryptEngine.java:714)
	at org.conscrypt.ConscryptEngineSocket$SSLInputStream.processDataFromSocket(ConscryptEngineSocket.java:833)
	at org.conscrypt.ConscryptEngineSocket$SSLInputStream.access$100(ConscryptEngineSocket.java:706)
	at org.conscrypt.ConscryptEngineSocket.doHandshake(ConscryptEngineSocket.java:230)
	at org.conscrypt.ConscryptEngineSocket.startHandshake(ConscryptEngineSocket.java:209)
	at io.grpc.okhttp.OkHttpProtocolNegotiator.negotiate(OkHttpProtocolNegotiator.java:100)
	at io.grpc.okhttp.OkHttpTlsUpgrader.upgrade(OkHttpTlsUpgrader.java:63)
	at io.grpc.okhttp.OkHttpClientTransport$4.run(OkHttpClientTransport.java:574)
	... 4 more

It seems that is related to the that issue: #7765. I' am running the tests with 1.8.0_292
Should I remove TLS1.3 from the default connection spec for now?

[ejona86]

Should I remove TLS1.3 from the default connection spec for now?

Yeah, don't add the TLS 1.3 ciphers to the default connection spec. Doing that was just for if it was easy. But you can add a link to that issue as a comment in the code, and add a comment to that issue that it prevented us from adding the ciphers to okhttp's default connection spec.

(Feel free to add the ciphers to the default connection spec, but commented out. But that's all just "nice to have" and nothing TLS 1.3 will be expected/required from your change.)

[beatrausch]

Hi,

right now I am testing the changes I made for TLS1.2 and TLS1.3 on Android.
When I am testing with TLS1.3 TLS_CHACHA20_POLY1305_SHA256 I got the following error:

java.lang.RuntimeException: TLS ALPN negotiation failed with protocols: null

I just thought it might be an server issue. But when I run a simple curl on linux the ALPN negotiation seems to work:

curl -vvv --http2 --tlsv1.3 --tls-max 1.3 --tls13-ciphers TLS_CHACHA20_POLY1305_SHA256   ...
*   Trying ...
* TCP_NODELAY set
* Connected to port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* TLS 1.3 cipher selection: TLS_CHACHA20_POLY1305_SHA256
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_CHACHA20_POLY1305_SHA256
* ALPN, server accepted to use h2
* ...
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x55f74b7ede10)
> GET / HTTP/2
> user-agent: curl/7.68.0
> accept: */*
...

Any ideas?

[beatrausch]

Yeah, don't add the TLS 1.3 ciphers to the default connection spec. Doing that was just for if it was easy. But you can add a link to that issue as a comment in the code, and add a comment to that issue that it prevented us from adding the ciphers to okhttp's default connection spec.

I will add the missing enums, but don't add them to the default connection spec in the OkhttpChannelBuilder

(Feel free to add the ciphers to the default connection spec, but commented out. But that's all just "nice to have" and nothing TLS 1.3 will be expected/required from your change.)

Yeah I will do so.

[ejona86]

Choosing the API to use when configuring ALPN is... complicated. If you didn't see that error before, but are now, that makes me question if something else changed in Conscrypt for TLS 1.3.

This is the place to look:
https://github.com/grpc/grpc-java/blob/master/okhttp/third_party/okhttp/main/java/io/grpc/okhttp/internal/Platform.java

findPlatform(), configureTlsExtensions(), and getSelectedProtocol() are all involved. It'll probably need stepping through the code or using printlns to figure out what is different now. So you're probably better off finding which of your changes causes this difference in behavior (probably TLS 1.3) and revert that change for the moment so that you can get the ciphers you want short-term.

[ejona86]

Fixed by #8650