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).
Related
I'm trying to setup an ssl based tcp connection to memsql using Go.
The application/services are running as openshift pods and written in Go.
Can I have one-way authentication to memsql from the service?
Do I need to enable any port in memsql to listen for tls based ssl connection?
Apart from updating the DSN in my service to tls=true, what can be the alternative to customise this configuration.
Can someone suggest an efficient way to connect to memsql with ssl enabled?
I've followed the memsql documentation and inserted the certificates to memsql master and aggregator, as well as made the permission check enabled, but still I'm able to get into the memsql without giving the rootCertificate in the login.
Currently the connection is established by following code:
db, err := sql.Open("mysql", DSN) and
DSN=root:#tcp(IPAddress:3306)/riodev?interpolateParams=true&parseTime=true
Can you clarify what your question is? The SSL authentication is one-way, the client verifies the server. The server verifies the client via their login information.
No, MemSQL uses the same port for SSL and non-SSL connections.
You may also need to configure the SSL certificate, as described in https://github.com/go-sql-driver/mysql#tls.
Most client libraries support connecting with SSL.
I've followed the memsql documentation and inserted the certificates to memsql master and aggregator, as well as made the permission check enabled, but still I'm able to get into the memsql without giving the rootCertificate in the login.
Is it possible the connection is already using SSL? It may be using SSL-preferred mode without verifying the certificate.
For my current project i need to implement http over tls at client ,for this i need a local server able to simulate this . is there any online or offline tool. which i can use and and see the handshake in wireshark .
For watching the TLS handshake you might not get far enough with wireshark. For such kind of monitoring you would ensure the security is low enough for wireshark to be able getting the session key from watching the handshake for decoding the later parts. Thus, you need to avoid any forward secrecy.
Otherwise any (https) server that is accessible (and willing to talk) to your client will do.
In case you are in an environment that is supported (e.g. any unix/linux), you might try using openssl. It allows setting up a server that will do handshake. And it will log the handshake such that you will be able looking at what is going on. This will eliminate the need for using wireshark for debugging.
For achieving this you need a Web Server accepting connection over TLS.I have achieved this on Apache Tomcat web Server.
TLS configuration needs to be done in the server.xml file present in config directory of Tomcat webserver. Connector tag needs to be added in the server.xml file that contains information like
TLS version to be used, port, List of supported Cipher Suites, Keystore path and password, Truststore path and password.
Any regular Rest client can be used to make a call like Postman client. But to use that over TLS/SSL certificate is needed to be installed in Chrome browser.
Hope this answers your doubt.
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.
Would like to write SSL Socket client server application on the same machine (both server and clients are running same machine). Should I use SSL certificate file (.pem file ) or not required.
Just I want encrypt the data before sending via socket.
Can we encrypt the data without .pem file?
Please advice me.
-Bala
SSL has two major steps:
check the identity of the peer, e.g. make sure you talk to the right one and not an imposter (e.g. man in the middle). This is done with certificates.
encrypt the connection, so that anybody listening on the wire cannot understand what's going on. Obviously encryption helps nothing if somebody is actively listening on the wire, because you failed in step#1. In this case you have no end-to-end encryption but an end-to-imposter and imposter-to-end encryption :)
Considering these arguments: do you still want to skip checking the certificate?
If you want it is doable, just look for anonymous authentication, e.g. ADH or aNULL with openssl.
I want to force all external connections to be encrypted using SSL, essentially I want to encrypt only one of the network interfaces.
This article comes about as close to my answer as I can get:
http://basitaalishan.com/2012/07/16/encrypting-connections-to-sql-server/
However, it seems to me that either all connections are forced to use encryption or all connections may be able to not use encryption at all. I want all external connections to be encrypted (no choice) and all internal connections (behind the firewall) to not be encrypted.
I need to encrypt both SQL 2005 and 2008R2. Both are running on Windows 2008 Std
Can this be done at all?
You could use a SSL wrapper/proxy like stunnel, then set the firewall to allow external connections only to the port where said SSL wrapper runs.