Google Cloud SQL (MySQL) supports SSL Client Certificates for securing connections. I have gotten these working with the mysql CLI client and with MySQL-python without any drama, but Java's JDBC driver model seems to be significantly less flexible. I was able to get it working by importing the necessary keys and certificates into my keystore, but it does not appear that I can easily provide a specific certificate to use for a particular connection at runtime.
For my use storing all the certificates in a single keystore per JVM won't work, we have a multi-tenant environment with dozens of isolated client certificates. The PostgreSQL JDBC documentation offhandedly mentions it should be possible by implementing your own SSLSocketFactory (source):
Information on how to actually implement such a class is beyond the scope of this documentation. Places to look for help are the JSSE Reference Guide and the source to the NonValidatingFactory provided by the JDBC driver.
The Java SSL API is not very well known to the JDBC driver developers and we would be interested in any interesting and generally useful extensions that you have implemented using this mechanism. Specifically it would be nice to be able to provide client certificates to be validated by the server.
The only implementation I have seen is GoogleCloudPlatform/cloud-sql-mysql-socket-factory which on-the-fly queries the Google Cloud APIs to retreive emphemeral ssl client certificates. This is what I'm starting with, but I'm disheartened by the fact some basic socket properties (notably connectTimeout and socketTimeout) are not currently implemented.
Are there other SSLSocketFactory implementations I should be aware of? It seems like a generic implementation would be useful for multiple JDBC drivers (MySQL connector/J, PostgreSQL pgJDBC and Oracle offer some client cert support). That way JDBC connection strings could support client certificates as standardize parameters (base64 encoded?) just as usernames and passwords are currently included.
Related
I want to use a Amazon Aurora Serverless with my spring boot applications. I need to encrypt the jdbc connection between my application and Aurora, unfortunately I didn’t find any documentation according this topic.
Have anybody any experience with this topic?
How can i encrypt jdbc connection?
Your Serverless cluster should already have the cert installed on it. You shouldn't need anything specific to talk TLS with the endpoint.
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless.html#aurora-serverless.tls
You can use additional client side settings and enforce the mode of SSL verification as well. (Details in the doc link above)
I know ESRI do not longer distribute the Java-files needed so that Geotools can be used as before. But are there any workaround to use GeoTools or similar library using Direct-connect for versions after 10.3?
Its a bit hard to understand the documentation that only describes that the ArcSDE Connection supports version 10. There is no comment on changes in support from ESRI libraries.
The documentation indicates that you can get the required jars by requesting them from ESRI.
As for version 10.0, ArcSDE is part of the ESRI ArcGIS Server stack, and you may need to request a separate media DVD to ESRI for the ArcSDE Java SDK as it seems it doesn’t come with the standard DVD set but you can get it by just asking for it.
There is also a section on using Direct Connection
ESRI Direct Connect allows clients to directly connect to an SDE GEODB 9.2+ without a need of an SDE server instance, and is recommended for high availability environments, as it removes the ArcSDE gateway server as a single point of failure. ESRI DC needs additional platform dependent binary drivers and a working Oracle Client ENVIRONMENT (if connecting to an ORACLE DB). See Properties of a direct connection to an ArcSDE geodatabase in the ESRI ArcSDE documentation for more information on Direct Connect, and Setting up clients for a direct connection for information about connecting to the different databases supported by ArcSDE.
The GeoTools ArcSDE configuration parameters are the same as in the Configuration Parameters section above, with a couple differences in how to format the parameters:
server: In ESRI Direct Connect Mode a value must be given or the Direct Connect Driver will throw an error, so just put a ‘none’ there - any String will work!
port: In ESRI Direct Connect Mode the port has a String representation: sde:oracle10g, sde:oracle11g:/:test, etc. For further information check ArcSDE connection syntax at the official ArcSDE documentation from ESRI.
instance: In ESRI Direct Connect Mode a value must be given or the Direct Connect Driver will throw an error, so just put a ‘none’ there - any String will work!
user: The username to authenticate with the geo database.
password: The password associated with the above username for authentication with the geo database.
If you have tried these two approaches and still have an issue please ask a further question or clarify this one.
I see the documentation is quite unclear when it comes to what versions that are really supported.
We can connect to ArcSDE version 10.2 and earlier using ESRI libraries.
My question relates to ArcSDE versions post 10.3. Connections seems not possible on later versions.
Has anyone succeded Connecting to ArcSDE on versions post 10.3?
I'm setting up an application on Heroku that uses a MySQL database.
The client would like to use a MySQL database that has an explicit whitelist that allows it to connect. However, due to the dynamic IP nature of Heroku, this proves to be quite complex; we have to use an add-on such as QuotaGuard to provide us a static IP in which we can access the database.
This proxy routing is causing issues for us in other places as other services that use dynamic IPs are attempting to access the database and are failing.
My question is the degree of security a whitelist really provides rather than a complex username/password with SSL.
Has anyone had experience with the two and can speak to the advantages disadvantages?
Thanks
Allow me to rephrase your question:
What is the advantage of setting up a complex dynamic IP tracker system vs. simply securing the link?
An IP can be spoofed, by the way, so this solution is not that secure (right, such an attack requires some non-trivial black magic, but is quite feasible in fact).
Configuring MySQL for SSL support is really not that complicated and very well documented.
And if you can't recompile or reconfigure MySQL, you can still establish a simple VPN between your client application and your MySQL server (and only allow connections from this VPN).
Unfortunately, I don't know if your provider allows this level of configuration on your instances.
So if all of the above in not possible, you can still create a random 10000-character long password. Not secure enough for a purist, but I wish the hackers good luck :)
I have a C application using the MySQL library for database access.
Is there a standard way to implement database connection pooling for such an application?
The C connector doesn't appear to support it.
The Zild Database Library, "a thread-safe high level multi-database connection pool library", looks very promising.
Previously I suggested that
SQL Relay could be used to do this, amongst many other useful things, such as
client-side caching
load-balancing across database instances
translating between different database access APIs
If the MySQL library is dynamically linked this can be done without recompiling the application.
When I last looked in 2009, the mailing list suggested SQL Relay might not be fully ready for production use, but that appears to have changed.
I am taking on a legacy project in which database management was handled over the internet using an ODBC connection. The legacy program has recently been rewritten in C#. We are currently discussing how to improve the program and I am a bit uncomfortable with using ODBC to connect to the database. I have written routines to connect to a server using sockets and POST, PUT, and GET commands combined with cgi or php scripts and have read extensively about the AJAX paradigm which I see as the way forward. My colleague insists on using ODBC. What are the pros and cons of using an ODBC connection vs. a more modern approach?
Database-to-application protocols were never designed to be used over the internet. They are too chatty and difficult to secure. If you have the opportunity to do so, then you should consider encapsulating the database behind a properly-secured web service.
those who don't know networking are doomed to reinvent it on port 80
there's nothing 'modern' about HTTP over ODBC. just be sure to wrap it in SSL and/or a VPN and use sensible access controls.
it will be a lot more efficient than HTTP, which wasn't designed for this. at the very least, HTTP commands add a lot of overhead for each operation. ODBC will get you far better latency (which is critical in client-driven DB designs)
How about using ODBC with a modern approach, web services. There are many advantages to this approach. For example:
Multiple client programs can use a single instance of the web service to
access data. There is no need to
write database related code in each
individual application.
Users need to install ODBC drivers and configure ODBC data
sources only on the server machine
that hosts the web service. Client
programs can be running on other
machines over the network.
Client programs are not limited to .NET or Windows platform. All they
have to do to access database is call
a web service.
Database connections can be shared among different client
programs.
Access to databases can be controlled and monitored from a
central location (the web service).
Of course, there are some security issues and limitations to the complexity of your queries.
I had something similar in my office. They had lots of machines with VB.NET apps hitting the local database (regularly got it stuck with too many unused connections) and some web services that contacted an external database through an SSH/SSL tunnel.
We didn't really have a lot of problems with the external database unless the tunnel went down which was rare. You can probably also set up a VPN.
If you are interested in using AJAX/JSON/REST technologies to communicate with a database, you can use an abstraction layer like DBSlayer.
Using a TypeIV "direct" database driver like the System.Data.SqlClient namespace for C# ,or a JDBC driver for Java, is 2-3 times more efficient (better performance) than going through the ODBC layer.
I would avoid ODBC because its slower and I think its not any easier.