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.
Related
Is is possible to configure HAProxy to only allow single connection per client certificate (based on CN or other attribute)?
Each client should be able to connect even if it has already open connections, though, after successful authentication any previous connection for that certificate should be dropped immediately.
I do not think ACL's would work for this purpose.
Thanks in advance
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.
We are setting up replication between RavenDB instances running in server mode. The instances are in different availability zones so we need a secure connection between the servers. According this this post SSL is not supported in server mode but
should be easy to add
Is there an extensibility point in the API where SSL support can be plugged in?
The API doesn't have any place for this currently, but I'm sure it would be a welcome contribution if you were so inclined to write this and submit a pull request. The underlying server is just a System.Net.HttpListener, which can be wired for ssl.
Your entry point would be at Raven.Database.Server.HttpServer.StartListening()
You would want the SSL certificate to be as easy to configure as the hostname or port. The cert itself should probably be pulled in from the Windows certificate store.
I have an application which can access a LDAP server with non-SSL connection. Now, the LDAP server has been configured to support only SSL.
So, now what are the new components or changes in the existing components which I have to do.
If your application really doesn't support SSL (btw it would've made things easier if you'd told us what program you're trying to use), you can try an SSL wrapper, such as stunnel that can be configured to connect to the SSL-protected LDAP service whenever your program connects to the "entrance" of the tunnel. This way, your program doesn't have to support SSL, but your connection to the LDAP server is still secured by SSL (if the SSL wrapper runs on the same host as your program).
You should only have to change ldap: to ldaps: in the client.
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).