Understanding SSL communication
What is SSL?
SSL stands for Secure Sockets Layer. It is a technology using which the data exchange between two systems are encrypted so that no one except the systems involved can interpret the data.
As you can see in the picture above, SSL communication involves a client and a server. Client is most probably a browser from a user’s PC, even though it can be a server application communicating with another server application. The server is most probably a Web Server, even though it can be any ssl enabled server application such as a Database Server or a Message queueing Server.
When you access a website using your browser, if the site is SSL enabled, you can see the security information in the browser. For example, see image below.
Note that SSL is a protocol, meaning various software products and frameworks implement SSL a little differently. However they must all adhere to the SSL specification. From Administration and Support perspective, what this means is you will have to do a bit of a reading to support SSL with various products. For example, while it is true that you need to add the CA certificate of the remote system you are trying to connect to your trust store, the steps you must follow for a WebLogic Application server will be different from a Jboss Application Server. I will explain all about CA certs in a sec
TLS, which stands for Transport Layer Security is the new generation SSL (After SSL version 3.0, it is TLS). As you can guess, TLS is the preferred protocol as it is newer (TLS 1.2 is the latest as of June 2015).
In the OSI Network model, SSL/TLS will fit in somewhere between Transport and Application layer.
SSL provides for two key security aspects in a client-server communication.
Authentication: You are guaranteed to communicate with the system that you are trying to communicate with (unless you are victim of Man in the Middle attack)
Encryption: The data being exchanged is guaranteed to be decrypted ONLY by you and the system you are communicating with (unless someone gets access to your private key)
How does SSL work?
SSL is based on Public Key Cryptography. Let us take a simple case to illustrate how it works.
A Web Server that wants to use SSL for its communication with the clients will first obtain a Private Key and a corresponding Public key (this is called Key Pair as they are mathematically related). When a client accesses the Web Server (for example, using the URL https://yourserver.com), the server sends the public key to the client. The client encrypts the data using the public key (or a derivative of the public key) which can be decrypted ONLY by someone who has the private key; in this case it is your server.
Public keys come in various strengths, depending on their size. A strong key size is 2048 bits. A 2048 bits RSA Public key looks like below:
30 82
Public keys come in various strengths, depending on their size. A strong key size is 2048 bits. A 2048 bits RSA Public key looks like below:
30 82 01 0a 02 82 01 01 00 b9 4b 64 43 5c 68 dc 87 6b 29 6f 5d 2b 2d 50 80 e1 38 1e 07 f4 e2 34 b1 cf 73 37 8a 30 9c c8 63 da 8a 50 64 1f 71 80 93 c1 f5 9e d8 4d 71 05 ea ff 8b 43 97 21 47 1a fb f0 6b dc 74 ca da a9 0d a1 cf e7 b8 59 09 27 77 a3 d7 b0 3d 2a fd 44 62 1b
Note: Larger keys come with some performance hit but it is more difficult to crack. You must use at least 2048 bits.
Where do SSL certificates come into play?
A SSL certificate is nothing but a file containing Signed Public Key. It is a secure mechanism to send the Public key. More importantly, since the public key is signed, it proves the validity of the certificate (Authentication).
Here is how it works:
When a Server wants to enable SSL, it generates a key pair (the method of creating the key pair depends on the technology/product it is using. But typically java based applications can use the application ‘keytool’ that comes with Java). It then applies for a singed public key. It does so by creating a CSR (Certificate signing request) and sending it to a CA (Certificate authority). Upon reviewing the application, CA generates a Certificate chain which includes the Server certificate (signed public key) and a certificate (or certificates) of the CA itself. This certificate chain will need to be installed in the Server application (again, installing the server certificate depends on the product/technology the server is using).
To summarize:
1. Server generates a private key and a public key
2. Server generates and submits a CSR (Certificate signing request) to a CA (Certificate authority such as Symantec)
3. CA generates a Certificate chain containing the Server certificate (signed public key) and a certificate (or certificates) of the CA itself.
4. This certificate chain will need to be installed in the Server application
Taking a deeper look at a SSL certificate
Will keep update this ....
