SSL on Tomcat connection pool - ssl

I have done a lot of searches, but still can't find a solution.
In my projects, I'm using both Tomcat connection pooling and C3P0 connection pooling for postgresql. I rejected to use JDBC connection pooling because it's not suggested by postgresql officially.
Now I need to enable SSL/TLS on these pools. I thought this should be a pretty common need. I found examples on JDBC pooling, but not for tomcat or c3p0. I'm really wondering if tomcat and c3p0 poolings can configure SSL!
Does anyone have any resources on this topic that I can refer to?

SSL transport should be pretty much transparent to c3p0. just set up your postgres RDBMS to use SSL. the postgres JDBC driver supports SSL connections. if you are using a self-signed certificate though (rather than a certificate signed by one of the well-known certificate authorities), you'll have to either configure your JVM to recognize your self-signed certificate or the JDBC driver not to validate certificates.
You'll need to configure several postgres-specific JDBC Connection Properties. The easiest way to do this is by just appending the properties as standard URL-style params to your postgres-jdbc URL:
jdbc:postgresql://myhost.mydomain/mydb?ssl=true
Or (dangerously)
jdbc:postgresql://myhost.mydomain/mydb?ssl=true&sslfactory=org.postgresql.ssl.NonValidatingFactory
Those should work if you are configuring user and password (as usual) via c3p0 configuration parameters. Alternatively, you can configure all of the Connection parameters in a Properties object. Here is how that would work for c3p0:
// obviously, imports should go where there should go
import java.util.Properties;
import com.mchange.v2.c3p0.ComboPooledDataSource;
// this is very close to the postgres docs
Properties props = new Properties();
props.setProperty("user", myUsername);
props.setProperties("password", myPassword);
props.setProperty("ssl","true");
props.setProperty("sslfactory","org.postgresql.ssl.NonValidatingFactory");
// this is c3p0-specific
ComboPooledDataSource cpds = new ComboPooledDataSource();
cpds.setJdbcUrl("jdbc:postgresql://myhost.mydomain/mydb");
cpds.setProperties( props );
// set any other properties you wish to override from values in config and/or defaults
The easiest way, I think, will be to just set jdbcUrl, user, and password in c3p0 config files and append ssl params to the end of your postgres jdbc URL.

Related

Quarkus JDBC connection with SSL

I using quarkus with Panache + Agroal.
I need to setup a DB connection(postgres) with SSL enabled. So I need to somehow configure the server-cert, client-cert and client-key.
I only see this available for the reactive client.
Can this be achieved for non-reactive one? I find it very hard to believe that nobody needed this.
You can specify it via JDBC url. Different database would have its own way to config ssl. For postgres, it would be sslcert and sslkey, ref https://jdbc.postgresql.org/documentation/head/connect.html#ssl

Does snowflake support ssl?

Hi I want to have the ability to connect from jdbc driver to snowflake with ssl. I did it many times with other db, just add ssl=true(sometimes other properties) in connection url.
Unfortunately I didn't find this option in snowflake documentation. I found that snowflake supports something like ssl they call it Using Key Pair Authentication
Does it ssl mode for snowflake?
Does snowflake support ssl?
You can set a jdbc connection property ssl to on or off as seen here
That's what determines if the connection will be made via https or http, going by the implementation here
I tried it and it worked for me.
Note that if ssl is not set, the value is on by default.
I believe Snowflake only allows HTTPS to connect, and so it always uses TLS/SSL.
SSL encryption cannot be switched off when connecting to Snowflake. Full Stop.
There is no option in the JDBC or ODBC driver to disable (or enable) SSL. That is why this parameter is not mentioned on the documentation pages of Snowflake.
Generic
ODBC
Snowflake connections use SSL by default.
And using only HTTPS connections. Regardless whether it is a driver or the GUI.
That is also the reason that you do not need to add https:// to your server connection.
More on this can be found here.
The http-connections you might see Snowflake drivers make are to satisfy OCSP.
If you trying to test whether Snowflake supports un-encrypted connections and you get the information back that Snowflake does support unencrypted connections or does support TLS1.0 or TLS1.1 you have been testing your proxy-server settings and not snowflakecomputing.com or snowflake.com.
BTW : Currently only TLS1.2 is supported by Snowflake for HTTPS connections.

How to specify a local custom SSL truststore for Hornetq client when connecting via JNDI naming server

We have a java client (mule app) which is using hornetq client (v2.3.25.SP20) for connecting to the HornetQ remote server via the JNDI naming server (port 1099).
The connection is secured with SSL. The driver is requiring the javax.net.ssl.trustStore property to be set explicitly. Otherwise, it does not find the trust store.
We would like to specify a custom truststore for the session.
But setting a global property javax.net.ssl.trustStore may affect other applications. So, we are looking for the alternative.
I've coded a custom trust manager (X509TrustManager) which points to the custom truststore. But the issue is that it's used only for establishing connectivity with the JNDI server. Then, the actual connection object is taking the trust store location from the remote server (in case, of course, if javax.net.ssl.trustStore is not set).
The error HQ212007 is produced:
connector.create or connectorFactory.createConnector should never
throw an exception, implementation is badly behaved, but we will deal
with it anyway.
Unable to create NettyConnector for myserver:4447
Failed to find a store at remote server keystore location
Googling the error code, I've found very similar issue described with not solution provided here.
So, is there another way of specifying a path to a truststore for hornetq client when connectivng via JNDI, so, that it would not affect other applications running on the same VM system? Or, may be there is a way to disable the SSL certificate validation on the client side completely - this would work for us as well?
There are HornetQ-specific system properties to set SSL configuration parameters. Check out the documentation for HornetQ 2.4.0.
These properties were added after 2.3.0.Final but backported to the 2.3.x branch which is why they're available in 2.3.25.SP20 but aren't documented in the 2.3.0.Final docs.
In short, you can use these system properties instead of the global ones:
org.hornetq.ssl.keyStore
org.hornetq.ssl.keyStorePassword
org.hornetq.ssl.trustStore
org.hornetq.ssl.trustStorePassword

Is there any way to open a new connection using ssl without another handshake?

I'm working on designing a server, in which the protocol allows for the client to open additional physical connections to the server which operate in the context of a single logical connection.
One thought I had was that, if we're using ssl, we'll need to do another ssl handshake for the new connection. It seems to me that it should be possible to send some secret to the client over the original, secure connection that would allow the new connection to be securely established without a handshake (similarly to what I've read about ssl session reuse).
Is this actually possible?
SSL already does this. Provided both ends support it, there is a feature called 'session resumption' which allows a new connection via an existing SSL session, via a much abbreviated handshake, without the certificate exchange and negotiation of shared secrets.
Yes, by reusing SSL Session. You can do this by using PEM_write_bio_SSL_SESSION and PEM_read_bio_SSL_SESSION and then adding it to SSL Context.
Keep in mind you only need to do this in client mode, server mode does this automatically for you.

JDBC over SSL to a Cache database

I'm pretty far out of my depth here, so bear with me. We're using JDBC via com.intersys.jdbc.cachedriver to run stored procedures in Intersystems Cache and get the results in Java. However, there are other clients that connect directly to the Cache using a terminal over telnet. We have to lock down Cache's telnet port so that only telnet over SSL is possible. However, the Cache experts here say that locking down one port in Cache locks them all down, so the Java to Cache connection will also have to use SSL. I understand vaguely that some JDBC drivers support SSL, but I don't see that the Cache one does. What I need to know is:
What's needed to configure SSL for the JDBC connections? (We're using JBoss 4.2.3)
What about certificates? I assume those have to go somewhere.
Is it actually true that locking down the telnet connections is also going lock down JDBC in the same way?
Configuring Java Clients to Use SSL/TLS with Caché
Using SSL/TLS with Caché
Telnet vs ssh is a question about what the OS allows and only relates to Cache peripherally. It doesn't mean anything regarding items 1 or 2. So in answer to the direct question you are asking, "No".
1. What's needed to configure SSL for the JDBC connections? (We're using JBoss 4.2.3)
See http://docs.intersystems.com/cache20102/csp/docbook/DocBook.UI.Page.cls?KEY=GCAS_ssltls#GCAS_ssltls_javacli for details. This section doesn't explicitly mention JDBC, but it's true for JDBC (and the reference has been added for the documentation 2011.1 [next release] .)
2. What about certificates? I assume those have to go somewhere.
To quote the documentation: "If the client has a private key and certificate, these are stored in the client’s keystore; the keystore can also hold the client’s root CA certificate and any intermediate CA certificates. To authenticate the server, the client may need to have the root CA certificate for the server and any intermediate CA certificates, these can be stored either in the client’s truststore or along with client certificate information in the keystore. For more information on keystores and truststores, see the section “Keystores and Truststores” in the Java Secure Socket Extension (JSSE) Reference Guide."
3. Is it actually true that locking down the telnet connections is also going lock down JDBC in the same way?
Yes -- if telnet connections are to require TLS, then the superserver TLS setting needs to be Required, which means that you have to use TLS for anything that goes through the superserver (including JDBC). If you just want to allow the use of TLS for telnet connections, set the TLS value to Enabled, which allows non-TLS connections by other means (such as JDBC).