What's the easiest way to get TCP Client/Server authentication via TLS/Certs/Keys in Go?
That is, I have a TCP server, and when a new client tries to connect to it, it should receive a certificate/key from the Server to allow it to connect again in the future without re-authenticating (or at least until the certificate expires). Both the client and the server should authenticate the other. OpenSSL isn't an option to create keys as the clients will be cross platform (Windows/macOS/Linux). Essentially, the server should only accept connections from known clients, and authorize new clients as needed (the clients can have some sort of known secret when installed).
Here's what I think the general flow is (correct me if I'm wrong)
Server: Get Cert/Key pair --> if they don't exist, create them --> listen on port --> receive connection --> verify Certificate is valid --> if not, reject --> if it is, continue to do what the server is supposed to do
Client: Get cert/key pair --> if they don't exist (i.e just installed), request from the server (Signed by the server) --> continue to connect as normal
This is still in the planning phase and open to all suggestions!
Thanks!
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.
We have an application running in WAS 8.5 server. The application has two external Service invocations, hitting 2 different third-party systems, in which one Service (Service2/Server2) requires Client Authentication.
Please refer the diagram for reference.
Server2 <-- Client --> Server1 Handshake Diagram
For Server1, we have shared a Client Certificate with them and the handshaking is perfect.
For Server2, which doesn't required Client Aunthentication, fails during handshaking. What we could find out that, during handshaking the server tries to authenticate the Client (Assuming that Client Authentication is SUPPORTED at Server2, but not REQUIRED). Since the Client KeyStore has the Client Certificate, it's being used for handshaking process, which is failing because this client certificate is not present at the Server2 Truststore.
My question is, whether is it possible to not send the Client Certificate to the Server2 even if the Server supports Client Authentication.
Hope this question is understandable.
Note1: We don't have any control over Server1 or Server2 and we don't expect any changes from these third-party Services to make this work.
Note2: Service2 works perfectly without Client Certificate in the Client Keystore. Please refer the diagram for Serer2-Client SSL Handshaking, which is perfectly working.
Client --> Server2 Handshake Diagram
Expecting help from someone who is proficient in Websphere SSL configurations.
Thank you,
Sanooj
In short:
You have to create 2 separate dynamic outbound SSL configs (see here for details) assuming your 2 external services have different URLs. The one that needs CertAuth will have cert in the keystore, the other will not have (you need 2 different SSL Configs).
I am developping a FTPS client in a Embedded system with LWIP and mbedTLS stacks.
For now, what I do is :
Get an IP adress with DHCP
Get IP address of the server with DNS
Start a TCP connection to the server ( the control connection)
Telling the FTP server that I want to work with the TLS protocol with the command AUTH TLS
Handshake of the TLS protocol with the server
Validate the x509 certificate that the server sends
Telling the client that I want to work in passive mode and that i want to read a file with the command RETR.
Now, I need to open a data connection to read my file. So what I wanted to know is does the data connection is secured in the same way the control connection is ? That means do I have a certificate to validate ? Is the handshake the same ?
If this isn't clear let me know i'm not an expert at all in this area.
Thank you for your future responses
In explicit FTPS connection after you send AUTH command, the data connection is secured all the way. Depending on Active/Passive connection the data connection is opened through port 20(Active) or some random port negotiated(Passive).
You don't need any extra handshakes as far as I know.
You might or might not be able to configure if you want to reuse the same session ID created in opening the control channel. This is related for server to know that data connection has been established by the same client which opened the control channel. Some server require this, some servers allow this, some servers does not support this.
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.