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
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 a website with SSL configured. 2 days back SSL certificate was expired so I purchased a new instead of renewing. I have configured the new one. Now some of users are still getting SSL certificate expired issue although the new one is configured.
I want to force the browser to recheck the new SSL certificate using some server side configuration since we can not go and update each user browser certificate manually. It have to be done using some server side configuration. We are using Nginx.
This is really critical to us.
Please help in this regard.
Thanks!
The certificate is validated by the client only when the server sends one. The server sends one with each full TLS handshake. The browser does not somehow cache an old certificate and ignore the one sent by the server when validating.
It is more likely that you've not fully rolled out the new certificate on the server side. For example if you have multiple servers make sure that all have the new certificate. If your server provides access for IPv4 and IPv6 make sure that in both cases the proper certificate is served. If you provide service on multiple ports make sure that they all use the new certificate.
It's also possible your affected users are behind a proxy that caches certificates. For example if they're behind a Smoothwall proxy that generates its own certificates after inspecting HTTPS traffic and caches them.
Either way, if you've updated the certificates on your server and restarted the necessary services, it's probably nothing you have control over and will most likely resolve itself in time.
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.
When renewing a certificate with a new private key, what happens with browsers that connected previously? Will the old certificate be cached and requests encrypted incorrectly? Is it possible at all to run multiple servers load balanced at layer 4 with some of them having new and others old certificates without causing connections to fail assuming no sticky sessions are used?
Clients usually do not cache SSL/TLS certificates. Only if you use the "Public Key Pinning Extension for HTTP (HPKP)" client do cache and check the provided certificate (or to be exact certain properties of that certificate). For changing the certificate HPKP can "allow" multiple certificates (e.g. one old and one new).
Regarding the load balancer: If they work on osi layer 4 I assume they work on TCP level. Therefore each server behind the balancer establishes it's own SSL/TLS session. If the sessions are not shared among the servers there should not be a problem event if not all servers use the same certificate - as long as all certificates are valid.
Clients can provide an SSL/TLS session id when starting the SSL/TLS connection, but the server decides if the session is known or not. Therefore if the client references a session from a different server nothing bad happens, client and server just establish a new session.
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.