Conscrypt has made some uncommon implementation choices which it's useful to be aware of.
The supported cipher suites in TLS 1.3 are always enabled. Attempts to disable
them by omitting them from calls to
setEnabledCipherSuites()
are ignored.
Prior to version 2.5.0 Conscrypt's hostname verification (enabled by
setEndpointIdentificationAlgorithm("HTTPS"))
defers entirely to the underlying platform's HttpsURLConnection hostname verifier.
The default HostnameVerifier on OpenJDK rejects all hostnames, and
so a HostnameVerifier or ConscryptHostnameVerifier
must be set in order to use hostname verification on OpenJDK. On Android, the default
HostnameVerifier performs RFC 2818
hostname validation, so it will work out of the box.
As of version 2.5.0, Conscrypt ships with its own default ConscryptHostnameVerifier
and this is used on both Android and OpenJDK. It performs RFC 2818 verification
and is equivalent to the system HostnameVerifier on Android 10 and 11.
Conscrypt's AEAD ciphers do not support incremental processing (i.e. they will
always return null from calls to
update()).
Input is only processed on a call to
doFinal().
This ensures that the caller cannot work with output data before the
authenticator has been processed, but it also means that the input data must be
buffered completely for each operation. This may necessitate splitting larger
inputs into chunks; see the BoringSSL
docs
for a discussion of important factors in doing so safely.
Conscrypt's OAEP ciphers (eg, RSA/ECB/OAEPWithSHA-256AndMGF1Padding) use the
named digest for both the main digest and the MGF1 digest. This differs from
the behavior of some other providers, including the ones bundled with OpenJDK,
which always use SHA-1 for the MGF1 digest. For maximum compatibility, you
should use RSA/ECB/OAEPPadding and initialize it with an
OAEPParameterSpec.