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).
Embedded devices often need security for transmitted data. Think of your wifi router. You would like to have SSL to protect your password when you connect to the router manage it. But device manufacturers cannot expect users to install certificates (too much hassle).
So we have a problem, how to use SSL with embedded devices, but without the hassle of installing a unique cert in each device. Self-signed certs can work, but the browser warnings scare the common user.
SSL provides 2 things:
1. Verify the identity of the server
2. Encrypt communications
For embedded devices, we can do without the first, but we often really want the second. So what we want is to either use SSL without a cert, or to be able to use a self-signed cert without the warnings. The self-signed cert warnings in browsers scare the common user. So what to do?
It seems there is no good solution for embedded devices to use SSL?
Ideas?
SSL provides 2 things: 1. Verify the identity of the server 2. Encrypt communications
For embedded devices, we can do without the first, but we often really want the second. So what we want is to either use SSL without a cert, or to be able to use a self-signed cert without the warnings. The self-signed cert warnings in browsers scare the common user.
Your question suggests that you don't really understand the role of identification in SSL.
Encryption without identification of the peer allows an attacker to mount a man-in-the-middle attack. In this attack the client will have an encrypted connection to the attacker and the attacker has another encrypted connection to the server. The attacker will get the encrypted data from the client, decrypt it and forward it encrypted again to the server. The same is done for data from the server to the client. This way the attacker can listen and even modify the data. Neither server nor client can detect the attack because of missing identification of the peer.
If the client wants to have a trusted connection to the device it needs to establish trust first. With self-signed certificate this will be done by accepting the certificate once within the browser (but only if there is definitely no man-in-the-middle). From then on any man-in-the-middle attacks will be detected because the certificate has changed.
Is it possible to spoof or impersonate a server's IP?
So that clients wanting to connect to that Server's IP, would actually connect to the attacker's machine?
But the attacker would still be able to contact the actual server.
This is all TCP/IP based, no name resolution, and all machines are on the same network or the internet (No NAT-ing).
I am working on a networking application, and I would like to build in some authentication.
What I need to do is to authenticate the server by IP. In other words, I want to make sure that when I open a HTTPS URL to an IP Address, it will go to the machine that has that IP.
Other notes:
All communication would be over TLS, but certificates would be blindly accepted.
What I need to do is to authenticate the server by IP. In other words, I want to make sure that when I open a HTTPS URL to an IP Address, it will go to the machine that has that IP.
This is one of the features of HTTPS (SSL/TLS) - it can prevent a MITM attack and prevent the destination server from being impersonated.
Other notes: All communication would be over TLS, but certificates would be blindly accepted.
This is great, however you will need to stop certificates from being blindly accepted. You should check that the common name or subject of the certificate matches the server that you are expecting to make contact with. You should also check that the root certificate is one that you choose to trust (you could make your own root certificate that is trusted). This will prevent the server certificate being spoofed by an attacker as they will not be able to sign the certificate with the root certificate.
An alternative is certificate pinning. This will enable your application to only communicate with a pre-set list of trusted certificates that are either hard coded into your application, or that are otherwise inaccessible to outsiders on your application server.
Yes, if you can perform man-in-the-middle attack. Evil transparent proxy in your LAN can do it.
I have created my SSL certificate using Selssl7.exe on server1 but used Cn as Server2 and hosted the certificate on server2. I started to get a certificate error when browsing from linux firefox saying:
This certificate is invalid, the certificate is not trusted and is self signed, the certificate is only valid for server1
But when I browse the URL from Windows IE I just get the regular error saying that it's not trusted and I can easily add it to exceptions.
Can we use self-signed certificates generated on server1 on a different servers?
You can and you may but you are pretty much undermining each and every aspect of authenticity by doing so.
A self-signed certificate is generally a problem because other users will not know this certificate in advance. So their browser dutifully issues a warning. That's why you have to pay for TLS certificates that will be recognized - they are issued by CAs whose certificates are contained in the default trust store of your browser. CAs had to pay to "be part of the club", but otherwise, anyone can create certificates. It's just the matter of being recognized by default settings.
But you open another hole by reusing a certificate that was issued for a dedicated server on a different server. TLS certificates' subject distinguished names must match the host name of the server they are deployed on. This is mandated by the TLS spec because this is the only effective measure to prevent man-in-the-middle attacks when using TLS. After you open a TLS connection to a server, your code will check whether the host name that you are connected to matches the subject DN of the server's certificate that was sent. Only if it does you can be sure to be talking to the right server.
So, in conclusion, if you reuse a server certificate on a different host, then you are severely impacting the security of TLS. It's still possible, sure, but if you cripple security to this extent, then you are probably better off using plain HTTP in the first place.
Whenever I see it being talked about, it sounds like one simply 'turns on' SSL and then all requests/responses to/from an online server are magically secure.
Is that right? Is SSL just about code - can I write two apps and make them communicate via SSL, or do you have to somehow register/certificate them externally?
Secure web pages are requested on port 443 instead of the normal port 80. The SSL protocol (plenty complicated in and of itself) is responsible for securing communication, and using the certificate information on both the SERVER and the BROWSER to authenticate the server as being who they say they are.
Generating an SSL certificate is easy. Generating one that is based on the information embedded in 99% of web browsers costs money. But the technical aspects are not different.
You see, there are organizations (Verisign, Globalsign, etc...) that have had their certificate authority information INCLUDED with browsers for many years. That way, when you visit a site that has a certificate that they produced (signed), your browser says:
"well, if Verisign trusts XYZ.com, and I trust Verisign, then I trust XYZ.com"
The process is easy:
Go to a competent SSL vendor, such as GlobalSign. Create a KEY and Certificate Request on the webserver. Use them (and your credit card) to buy a certificate. Install it on the server. Point the web-browser to HTTPS (port 443). The rest is done for you.
SSL is a protocol for encrypted communications over a TCP connection (or some other reliable scheme). The encryption uses public key encryption using X.509 certificates. SSL handles both privacy and trust. These are related: if you don't trust the server, you don't believe that the server hasn't handed out its private key to everyone in North America.
Thus, the client has to trust the server's certificate. For public sites, this is arranged via a hierarchy of certificate authorities, with the root authorities trusted, automatically, by browsers and things like the JRE's socket implementation.
Anyone can generate a self-signed certificate for a server, but then the client has to be manually configured to trust it.
SSL is not, in itself, a magic bullet that makes everything secure. Security has no such things.
SSL is, however, an already-designed, ready-to-use system for solving a common problem: secure stream communication over a network connection.
There are two things you need to do to secure your application with SSL:
Modify the application's code to use SSL.
Determine the certificate trust model (and deploy and configure the application respectively).
Other answers and documentation provide better answers to how to do each of these things than I could provide.
I'll throw caution to the wind and attempt to condense an enormous subject.
SSL attempts to solve two problems:
1) Authentication and hence trust i.e can the client trust the server and vice versa
2) Communication without eavesdropping
1) Is handled by means of an intermediary i.e a trusted 3rd party - these are called 'Root Certificate Authorities' ( or Root CAs ) examples include Verisign, RSA etc
If a company wants to authenticate users and more importantly if a user wants to authenticate the company's website it's connecting to i.e your bank then the Root CA issues the company a certificate which effectively says 'I the trusted Root CA verify that I trust that Company X are who they say they are and am issuing a certificate accordingly'. So you get a chain of trust i.e I trust the certificate from ACME Co because Root CA Verisign created and issued it.
2) Once the two parties have authenticated then the certificate ( typically X590 ) is used to form a secure connection using public/private key encryption.
Hopelessly simple and incomplete but hope that gives a rough idea
Yes and no. You should self-sign a certificate and test the site with SSL internally before deploying it with SSL, first of all. To make the public site secure under SSL, you will need to purchase a certificate from one of any number of certificate providers. Then you will have a certificate signed by a trusted third party, tied to your domain name, so that users' browsers won't complain that the certificate is invalid, etc. Turning SSL on is pretty much just flipping a switch, otherwise.
For the most part you need to buy and register a certificate externally.
You need to have your server certificate signed by a Certificate Authority (CA), for which they will charge you. The client needs to trust that CA and have a copy of the relevant CA public key. The client can then check that you are who you claim to be (including domain name (from DNS) and display name for https).
This is a good tutorial on how to create self signed certificates for Apache.
If you want to know how SSL works on either the Server or the Client, then I suggest Googling it. As you suspected, it is a ridiculesly complex procedure, with lots of communication between the client and server, a lot of very peculiar math, and tons of processing. There is also a lot of theory involved, several protocols and many different algorithms and encryption standards. It's quite incredible how changing http:// to https:// is so simple to the user, but results in so much work for both sides, and is so secure. To really understand it you need to take a security course (multiple courses to fully understand it), as the entire history of encryption goes into making your login to Gmail secure.
Turning on TLS (colloquially "SSL") does not make your site magically secure. You may still be vulnerable to application-level vulnerabilities like stack overflows, SQL injection, XSS, and CSRF.
As other answers have explained, TLS only protects against a man in the middle. Traffic between a client and a properly-configured TLS server cannot be intercepted or modified, and the client can reliably confirm the identity of the server by validating the X.509 certificate. This prevents an attacker from impersonating your TLS server.
SSL actually does two things:
Encrypts the communication so that an observer seeing the data stream will not be able to read the conversation.
Guarantees that you are talking to who you think you are talking to.
It is only for #2 that you need to get official certificates. If you only care to encrypt the communication without setting up a trust relationship, you can use self-signed certificates or you can use an algorithm that does not require certificates (i.e. Diffie-Hellman).