I played around with nginx and mutual TLS authentication.
For that i configured the nginx server to actually use client authentication with the config parameter:
ssl_verify_client on;
It works, but i have a question regarding the termination process.
If i do a get request to e.g. https://localhost and ssl_verify_client on; is set, i get an http response even if i don't deliver a valid client certificate:
400 Bad Request No required SSL certificate was sent
For me it would make sense that the TLS connection is terminated at the TLS handshake. Why do i get a http response, when the connection is not mutual authenticated?
I also read RFC 5246 and it basically says that it can be done this way (designers choice):
The TLS standard, however, does not specify how protocols add security
with TLS; the decisions on how to initiate TLS handshaking and how to
interpret the authentication certificates exchanged are left to the
judgment of the designers and implementors of protocols that run on
top of TLS.
Are there good arguments to do it on the application layer instead of the transport layer?
Is there a possibility to terminate the TLS connection earlier without using a proxy (e.g. HAProxy)?
Related
I am using pyhthon3 requests library and want to request some resources from the server using HTTPS. So I use two way SSL authentication, and I have configured the server in a way which do not REQUEST for client certificate in response of 'client Hello' request.
As You can see IP xxx.xx.xxx.100 is the client and IP xxx.xx.xxx.207 is the server. So when the client sends 'Client Hello' to the sever, in response the server does not REQUEST for the client certificate, even though its two way SSL authentication.
So as per my requirements, how can I stop the process of handshaking and data sharing immediately in such case? Or how to force the server to REQUEST for client certificate?
... even though its two way SSL authentication.
It's not. Just because the client has the certificate to do mutual authentication, does not mean that this certificate is actually used. It is only mutual authentication if the server actually requests it using a CertificateRequest (which is clearly not done) and the client then providing the requested certificate.
... how can I stop the process of handshaking and data sharing immediately in such case?
You can't. There is no API for this.
And I'm not sure what kind of sense such a requirement would make. The client has successfully authenticated the server which should be all needed by the client to exchange data with the server. The server instead might want to know who the client is before sending specific data. So authenticating the client before providing such data makes sense from a server perspective, but not from a client one. This would be like you refusing to drive a car if nobody is checking your drivers license.
Or how to force the server to REQUEST for client certificate?
This fully depends on the kind of server. Different servers need different configuration. For example with nginx see ssl_verify_client.
In the case where its beeing used a websocket protocol between a client (webpage) and a server.
Is it possible for third parties to spoof the connection in the handshake or even after the connection has been established?
Websockets do not directly provide authentication. If you build it over TLS (i.e. WSS), then you will use the TLS session to authenticate the parties using server and client certificates, exactly like HTTPS vs HTTP.
If you build your websocket over HTTP, then yes, it is completely possible for a third party to spoof the connection (and also to eavesdrop). If your HTTPS/WSS system does not properly validate certificates, then that also can be spoofed.
I am trying to set the client to nodes SSL encryption for one of our client.
I have confusion regarding the functionality of setting require_client_auth in client_encryption_options in cassandra.yaml and what configuration needs to set from client and cassandra node in case I set require_client_auth to true.
Password authentication is already set,now investigating if there might be any additional advantage to having both ("authenticator: PasswordAuthenticator" and "require_client_auth: true") turned on
As Jim stated, require_client_auth doesn't have anything to do with Cassandra's auth system. It is an additional level of security configuration for client-to-node SSL.
When you implement client-to-node SSL and enable require_client_auth you are enabling what is known as Two Way SSL. Instead of the Cassandra client simply verifying the identity of the server, the server also verifies the certificate used by the client. This doc One Way and Two Way SSL and TLS (Peeples K. 2015) has a good description of this process:
Two-way SSL authentication is also referred to as client or mutual authentication because the application acting as an SSL client presents its certificate to the SSL server after the SSL server authenticates itself to the SSL client.
Establishing the encrypted channel using certificate-based 2-Way SSL involves:
A client requests access to a protected resource.
The server presents its certificate to the client.
The client verifies the server’s certificate.
If successful, the client sends its certificate to the server.
The server verifies the client’s credentials.
If successful, the server grants access to the protected resource requested by the client.
On the other hand, with One Way SSL the client only verifies the server's certificate (from the same doc).
The advantage of Two Way SSL would be in knowing that the Cassandra nodes will not allow a connection from an unknown client certificate.
IMO, one Way SSL still offers a decent degree of security. The dev team will need to present a cert which validates up through the same CA (certificate authority) as the cert from the Cassandra nodes. Two Way SSL might be useful in a large org, helping to keep out connections from applications that have not first talked with your team.
I believe the require_client_auth is for SSL (certificate) communication between the client and server, and that the client must identify itself (you can have it so that the server is the only one that identifies itself).
I have a Node.JS service running, which I am trying to connect from a different system. Currently using POSTMAN to test the service. Postman gives an error - There was an error connecting to https://lddbbtx.wdf......./index.xsjs.
Now, I retried the request by disabling 'SSL certification verification' option in Postman and it seems to work. I can receive the response from the service.
But in production, we will be using Recast.AI to connect to this service. In Recast, they provide a means to set Headers for the GET/POST requests . SO , I wanted to know, is there a way to disable the SSL verification in the header of the request ?
... is there a way to disable the SSL verification in the header of the request ?
Validation of the server certificate is done at the client side. It is done during the TLS handshake and thus before any HTTP request is send. Disabling validation cannot be triggered by the server since otherwise a man in the middle attacker could simply instruct the victim to not check the certificate.
In general - disabling validation or even part of the validation (like checking that hostname in URL matches certificate) is a very bad idea. With disabled certificate validation the transport is still encrypted but the client does not check that it actually communicates with the expected server. This way an attacker could do a simple man in the middle attack to impersonate the server and thus sniff and also modify all traffic.
I want to use secure websockets with socketio and nodejs so that more of my mobile traffic/corporate networks can utilise websockets.
What level of SSL certificate is required for most browsers to accept the certificate/server as trustworthy. Browsers don't have an interface for reviewing/allowing SSL connections for websockets as far as I know, so how do they handle a cert they don't trust? Do they just refuse the connection?
What minimum level is required from an example list: https://www.123-reg.co.uk/ssl-certificates/ and has anyone done any research into how browsers handle various levels of SSL in websocket connections?
Securing a websocket is no different to securing an HTTP connection. A TLS handshake process will happen first to establish a secure connection and then an HTTP connection will be established over this secure link. For a websocket the additional step of upgrading the HTTP session to a socket will be taken. What this means is that whatever works for HTTPS will work for WSS. This link has a useful diagram.
I'm not sure what the difference is between the "123 SSL" and "Domain SSL" levels in your link, if the lower cert is issued against your domain it may be fine. Generally you want "Domain Level Validation" or above - it is enough to secure traffic between clients and your server. As long as the root certificate is trusted (generally the company you are buying the certificate from), browsers will accept this with no message or warning. For WSS, APIs and communicating with mobile apps this will be fine. The top level certificate (Extended Validation or EV) has the added advantage of additional security indicators in the browser (usually the green address bar or lock), great for browser sites but not of much use for pure WSS or API clients.