prbprbprb
commented
3 years ago Looks like you're not the only person to encounter this e.g. Cloud Dataproc recommend disabling Conscrypt when talking to SQL Server, which seems..... suboptimal. This is the first time a bug has made it back to us though, sorry.
Two possibilities spring to mind:
-
Client and server can't find a TLS 1.2 cipher suite in common, which seems unlikely though. You could see what suites it does support with something like the script here. NB that script won't work unmodified, you'll need to change the openssl args to something like
-host $HOST -port $PORTand pass in the port as well as the host. You could also try switching to TLS 1.1 (not recommended as a final solution) or TLS 1.3 (fewer cipher suites to worry about ;) -
There's something funky going on with this
TDSChannel$ProxyInputStream. NormallyConscryptEngineSocketexpects to be reading / writing to a plainSocket. It looks likeTDSChannelmight be sniffing or modifying some of the TLS handshake data in a way that breaks things (just guessing from the symbol names, I haven't had a chance to decompile it). -
Conscrypt is dropping the connection because it can't verify the server's certificate. However that should manifest itself as a
CertPathValidatorExceptionthrown by Conscrypt'sTrustManagerImpl.
I'm leaning slightly toward (1) because it looks like the server is dropping the connection, then that's detected in TDSChannel$SSLHandshakeInputStream.readInternal(). If TDS was messing with the handshake data in a way which confused Conscrypt then it would be more likely to throw in ConscryptEngineSocket$SSLInputStream.processDataFromSocket.
I don't have an easy way to reproduce this. If you have time, could you try writing a small program which installs Conscrypt then makes a simple SSLSocket connection to your SQL server and dumps any data received, please? If it throws any kind of certificate[1] or handshake exception then it's definitely a Conscrypt issue. If it connects (then presumably gets dropped by the server) then it's the interaction between Conscrypt and TDSChannel$ProxyInputStream.
[1] Actually you might get a CertPathValidatorException as Conscrypt doesn't ship with a root CA store, you can either install an accept-all trust manager, e.g. https://gist.github.com/matthewromano/4178946 (NEVER DO THIS IN PRODUCTION CODE!) or use the platform's trust manager, e.g.
Provider conscrypt = Conscrypt.newProviderBuilder().provideTrustManager(false).build();
mandrachek
Kelbas-99
JBJ75S
www-viveksharma
cjac
dharam-cldcvr
Attempting to use Conscrypt (for OkHttpClient, using the uber jar, in a web application on Tomcat, under JDK 8, running on mac/windows/linux). Conscrypt is installed in a ServletContextListner.
The problem comes when attempting to create a database connection using the MS SQL Server JDBC Driver - specifically ('com.microsoft.sqlserver:mssql-jdbc:8.4.1.jre8'). I'm passing ";sslProtocol=TLSv1.2", per the mssql-jdbc documentation to ensure that TLSv1.2 is used.
Without inserting Conscrypt, the database connection works fine. Once conscrypt is inserted however database connections fail (Stacktrace follows). Not sure if this is a conscrypt issue or a mssql-jdbc issue.