Share Solutions: SSl

Showing posts with label SSl. Show all posts

Thursday, 25 January 2018

Cassandra java driver With SSL

I want to present you an java code for cassandra client with SSL and Cluster. I am not sharing keystores but i pressume you can get that info from google. I also want to provide you and reference sites i have gone through:

import java.io.File;
import java.io.InputStream;
import java.security.KeyStore;

import javax.net.ssl.SSLContext;
import javax.net.ssl.TrustManager;
import javax.net.ssl.TrustManagerFactory;

import org.apache.commons.io.FileUtils;
import org.json.JSONArray;
import org.json.JSONObject;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

import com.datastax.driver.core.Cluster;
import com.datastax.driver.core.Cluster.Builder;
import com.datastax.driver.core.Host;
import com.datastax.driver.core.JdkSSLOptions;
import com.datastax.driver.core.Metadata;
import com.datastax.driver.core.Session;

/**
 *  "dbinfo": {
      "port": 9042,
      "truststorepath":"/path/to/truststore.jks",
      "truststoresecret":"password of truststore",
      "nodes": [
         "127.0.0.2",
         "127.0.0.1"
      ],
      "ssl": false
   },
 * 
 * 
 * 
 * This is an implementation of a simple Java Cassandra client.
 *
 */
public class CassandraClient {
 private static final Logger logme = LoggerFactory.getLogger(CassandraClient.class);

 private Cluster cluster;

 private Session session;

 /**
  * For single node instance setup
  * 
  * @param node
  * @param port
  */
 public void connectToServer(final String node, final Integer port) {

  Builder b = Cluster.builder().addContactPoint(node);

  if (port != null) {
   b.withPort(port);
  }
  cluster = b.build();

  Metadata metadata = cluster.getMetadata();
  logme.info("Cassandra: Cluster name: " + metadata.getClusterName());

  for (Host host : metadata.getAllHosts()) {
   logme.info("Cassandra:Datacenter: " + host.getDatacenter() + " Host: " + host.getAddress() + " Rack: "
     + host.getRack());
  }

  session = cluster.connect();
 }

 /**
  * 
  * For multi node instance setup
  * 
  * @param cfg
  */
 public void connectToServer(JSONObject cfg) {

  Builder b = Cluster.builder();

  JSONObject cassandra = cfg.getJSONObject("dbinfo");
  JSONArray nodes = cassandra.getJSONArray("nodes");

  for (Object node : nodes) {
   b.addContactPoint(node.toString());

  }
  boolean ssl = cassandra.optBoolean("ssl", false);
  int port = cassandra.optInt("port", 9042);
  b.withPort(port);

  if (ssl) {

   String trustPath = cassandra.getString("truststorepath");
   String trustSecret = cassandra.getString("truststoresecret");
   if (trustPath == null || trustSecret == null) {
    logme.error(" *********   Please provide truststore details for cassandra ****************");
   }
   JdkSSLOptions sslOptions = getSSLOptionsFromTrustStore(trustPath, trustSecret);
   b.withSSL(sslOptions);
  }

  cluster = b.build();

  Metadata metadata = cluster.getMetadata();
  logme.info("Cassandra: Cluster name: " + metadata.getClusterName());

  for (Host host : metadata.getAllHosts()) {
   logme.info("Cassandra:Datacenter: " + host.getDatacenter() + " Host: " + host.getAddress() + " Rack: "
     + host.getRack());
  }

  session = cluster.connect();
 }

 public Session getSession() {
  return this.session;
 }

 public void close() {
  session.close();
  cluster.close();
 }

 private JdkSSLOptions getSSLOptionsFromTrustStore(String trustStoreLocation, String trustStorePassword) {
  Cluster cluster;
  SSLContext sslcontext = null;

  try {

   InputStream is = FileUtils.openInputStream(new File(trustStoreLocation));
   KeyStore keystore = KeyStore.getInstance("jks");
   char[] pwd = trustStorePassword.toCharArray();
   keystore.load(is, pwd);
   TrustManagerFactory tmf = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());
   tmf.init(keystore);
   TrustManager[] tm = tmf.getTrustManagers();

   sslcontext = SSLContext.getInstance("TLSv1");
   sslcontext.init(null, tm, null);

  } catch (Exception e) {
   logme.error(e.getMessage(), e);
  }

  JdkSSLOptions sslOptions = JdkSSLOptions.builder().withSSLContext(sslcontext).build();

  return sslOptions;
 }

}

Wednesday, 16 July 2014

Browser ssl certificate validation

How SSL works

Please check this link--> How SSL Works

How browser verifies certificate

It has 3 ways to verify the SSL certificate from server:

It verifies with local trust store
Verifies using CRL- (Explained Below)
Verifies using OCSP (Explained Below)
Verifies using SCVP( Not Supported as of today) Spec defined as of now.

When certificate compromise

It is discovered that the certificate authority (CA) had improperly issued a certificate, or if a private-key is thought to have been compromised. Certificates may also be revoked for failure of the identified entity to adhere to policy requirements, such as publication of false documents, mis-representation of software behavior, or violation of any other policy specified by the CA operator or its customer. The most common reason for revocation is the user no longer being in sole possession of the private key (e.g., the token containing the private key has been lost or stolen).

Certificate Revocation List - OCSP-Online Certificate Status Protocol

Today we did an announcement of some work we have been doing with CloudFlare to speed up SSL for all of our customers through some improvements to our revocation infrastructure.

One of the things that come up when talking about this is how each of the browsers handles revocation checking, I thought it might be useful to put together a quick post that talks about this to clear up some confusion.

The first thing that’s important to understand is that all major browsers do some form of revocation checking, that includes Opera, Safari, Chrome, Firefox and Internet Explorer.

Let’s talk about what that means, the IETF standards for X.509 certificates define three ways for revocation checking to be done, the first is Certificate Revocation Lists (CRLs), next there is the Online Certificate Status Protocol (OCSP) and finally there is something called Simple Certificate Validation Protocol (SCVP).

In the context of browsers we can ignore SCVP as no browser implements them; this leaves us with CRLs and OCSP as the standards compliant ways of doing revocation checking.

All of the above browsers support these mechanisms, in addition to these standard mechanisms Google has defined a proprietary certificate revocation checking scheme called CRLsets.

If we look at StatCounter for browser market share that means today at least 64.84% (its likely more) of the browsers out there are doing revocation checking based on either OCSP or CRLs by default.

This means that when a user visits a website protected with SSL it has to do at least one DNS look-up, one TCP socket and one HTTP transaction to validate the certificate the web server presents and more likely several of these.

This is important because of the way revocation checking needs to be done, you need to know if the server you are talking to really is who they say they are before you start to trust them – that’s why when browsers do OCSP and CRLs they do this validation before they download the content from the web page.

This means that your content won’t be displayed to the user until this check happens and this can take quite a while.

For example in the case of IE and Chrome (when it does standards based revocation checking on Windows) it uses CryptoAPI which will time-out after 15 seconds of attempting to check the status of a certificate.

The scary part is that calls to this API do actually time out and when they do this delay is experienced by the users of your website!

So what can you do about it? It’s simple really you have to be mindful of the operational capacity and performance of the certificate authority you get your certificate from.

Check out this monitoring portal I maintain for OCSP and this one I maintain for CRLs, you will see GlobalSign consistently outperforms every other CA for the performance of their revocation infrastructure in most cases it’s nearly 6x as fast and in others is much more than that.

The other thing to understand is that today the default behavior of these browsers when checking the status of a certificate via OCSP or CRLs is to do what is often referred to as a “soft-revocation failure”.

This basically means that if they fail for any reason to check the status of a certificate (usually due to performance or reliability issues) they will treat the certificate as good anyways. This is an artifact of CAs not operating sufficiently performant and reliable infrastructure to allow the browsers to treat network related failures critically.

Each of these browsers all have options you can use to enable “hard” or “strict” revocation checking but until the top CAs operate infrastructure that meets the performance and reliability requirements of the modern web no browser will make these the default.

Finally its also important to understand that even with this “soft-failure” your website experiences the performance cost of doing these checks.

Conclusion:

Now we have two online checking protocols for Certificate from browsers:

OCSP - Online Certificate Status Protocol- Most browsers supported
SCVP- Simple Certificate Validation Protocol- Most of the Browsers not yet Implemented.

References:

http://news.netcraft.com/archives/2013/05/13/how-certificate-revocation-doesnt-work-in-practice.html

http://blog.spiderlabs.com/2011/04/certificate-revocation-behavior-in-modern-browsers.html

Monday, 16 June 2014

SSL Certificate

Today we will learn about " How SSL Works ?" , which is a common question to most of the techies who work with the socket and SSL.

I assume reader knows about the browser and web server .

Why Use SSL?

Inshort, SSL stands for Secure Socket Layer. It adds more security to the communication. It is used with HTTP or TCP or FTP. To avoid data tampering in the communication we will choose SSL.

Transferring sensitive information over a network can be risky due to the following three issues:

You cannot always be sure that the entity with whom you are communicating is really who you think it is.

Network data can be intercepted, so it is possible that it can be read by an unauthorized third party, sometimes known as an attacker.

If an attacker can intercept the data, the attacker may be able to modify the data before sending it on to the receiver.

SSL addresses each of these issues. It addresses the first issue by optionally allowing each of two communicating parties to ensure the identity of the other party in a process called authentication. Once the parties are authenticated, SSL provides an encrypted connection between the two parties for secure message transmission. Encrypting the communication between the two parties provides privacy and therefore addresses the second issue. The encryption algorithms used with SSL include a secure hash function, which is similar to a checksum. This ensures that data is not modified in transit. The secure hash function addresses the third issue of data integrity.
Note, both authentication and encryption are optional, and depend on the the negotiated cipher suites between the two entities.
The most obvious example of when you would use SSL is in an e-commerce transaction. In an e-commerce transaction, it would be foolish to assume that you can guarantee the identity of the server with whom you are communicating. It would be easy enough for someone to create a phony Web site promising great services if only you enter your credit card number. SSL allows you, the client, to authenticate the identity of the server. It also allows the server to authenticate the identity of the client, although in Internet transactions, this is seldom done.
Once the client and the server are comfortable with each other's identity, SSL provides privacy and data integrity through the encryption algorithms it uses. This allows sensitive information, such as credit card numbers, to be transmitted securely over the Internet.
While SSL provides authentication, privacy, and data integrity, it does not provide non-repudiation services. Non-repudiation means that an entity that sends a message cannot later deny that they sent it. When the digital equivalent of a signature is associated with a message, the communication can later be proved. SSL alone does not provide non-repudiation.

How SSL Works?

Share Solutions