TLS/SSL Explained
What Are SSL and TLS Protocols?
Both SSL (Secure Sockets Layer) and TLS(Transport Layer Security) are cryptographic protocols that provide security over a network. They are widely used across different applications. SSL and its latest versions had a number of vulnerabilities, and hence, TLS was introduced as an updated version of SSL in the year 1999. SSL has been deprecated by the Internet Engineering Task Force (IETF) in 2015. Therefore, you should have TLS protocol enabled for your applications. You will still see a lot of SSL terminology being used across many organizations until people get accustomed to TLS.
TLS/SSL enabled servers will have two main additional duties
- Trust: Server application who serves the information to the “clients” needs to obtain trust by the clients. One way to achieve this by attaining TLS certificate from a globally trusted Certificate Authority, whom client has trust in.
- Secure data: data exchange between client and server needs to go through a secured channel by “encrypting” the messages while it is transit.
Now we know the purpose of TLS/SSL, lets try to understand “How” this Trust and Secure data transfer happens between client and server.
Before we jump on to how TLS certificate works, lets understand what is Symmetric and Asymmetric Encryption. This would help understand the TLS completely.
symmetric Encryption: (data encryption and decryption happens with a common “secret_key” ): In this case Client and Server holds the same “secret_key” to encrypt and decrypt the information. This is light weight and fast, since the size of the key is small, we can transfer more data with this approach. AES(Advanced Encryption Standard) is one of the common algorithms used for symmetric key encryption/decryption.
down side of this mechanism is, for the first time client has to send the “secret_key” to server safely, to avoid Man In the Middle(MiM) attacks. which is not easy.
Asymmetric Encryption: (Client Encrypt with Public key and server decrypt with private key): In this case server generates a special private and public key pair, any messages encrypted with public key can only be decrypted with related public key.
public key would be shared to the clients and private key will be put in secret place at server side. Client would use public key to encrypt the information and server uses related private key to decrypt the information. since the size of the public key is more we would not be able to send large messages hence slow. RSA is one of the popular algorithm used to create Asymmetric keys
But this mechanism has a down side that only client can send information to server securely, but server can not send information securely to the client.
There is a technique used to share symmetric key to the server for the first time, by using Asymmetric key approach. once the symmetric key reached the server safely, all the subsequent messages could be transferred using the symmetric key which is light weight and fast.
Steps involved in getting the Certificate signed by CA.
- Server application (assume it is a “bank”) request Intermediate Certificate Authority (ICA) by providing company name, address, email, domain and other details. This whole process may take 24 to 72 hours. Root CA will validate the below details before it provides a certificate to the requester.
Note: Intermediate CA is root CA authorized digital Certificate provider. certificate cost varies in attaining and managing the certificate between root CA and Intermediate CA.
- verifying the legal, physical and operational existence of the entity
- verifying that the identity of the entity matches official records
- verifying that the entity has exclusive right to use the domain specified in the EV SSL Certificate
- and verifying that the entity has properly authorized the issuance of the EV SSL Certificate.
Now server has CA provided certificate document, and it can be shared with the client to acquire confidence and have business with them. But how does server safely ship this certificate to the client browser or application. what if the document is hacked and corrupted by the MiM in transit. after all it is just a document with server details and authenticity.
The solution to this is “Digital signature”
Digital Signature is a private key encrypted value of the Cryptographic hash of the CA provided certificate document.
There are few Mathematical Hash algorithms to generate a Cryptographic Hash value from any kind of data. few of them are
MD5 ( 32 char, 128bits )
SHA1 ( 40 char, 160bits )
SHA256 ( 64 char, 256bit ) --> most popularBelow are the Properties of the Cryptographic Hashing algorithm (lets take SHA256 as an example)
- for Any kind of input value (text, file, mp4, jpg, pdf) it must generate 64 char (256 bit) unique value.
- No Two hash values should be same for any two different inputs
- hash value should be same for the same input, for any number of times we generate.
- No one should NOT be able to recover the original input value from the hash value.
Now server can generate a hash out of the actual certificate file and encrypt the Cryptographic hash value using the private key to generate digital signature( aka cypher text) and send it to client.
On the client side two steps would be performed.
- he can decrypt the digital signature using the public key and store the value to h1.
- Generate the Cryptographic hash using the same certificate and using same algorithm and store the value to h2.
if both h1 and h2 hash values are same then we can certainly tell that the certificate has not been modified in transit and it actually belongs to the server what clients is talking to and client can share the “Pre Master Secret Key” for subsequent data transfer.
Below is the Mathematical representation of sample Cryptographic Hashing
m: message, c: cypher text, n: common constant , pb: public key value
pt: private key value
c = f(m, n, pb)
f’(c, n, pt) === f’(f(m, n, pb), n, pt) === m
Note: fx is a hash function on client side and f’x is a has function on server side, where fx === f’x for all data transfers
Here is the pictorial Representation of SSL handshake between Client and Server using the certificate
2. Important point to remember is, in all the TLS/SSL handshake Public Key playing vital role and it has to be safely placed at client end. so most of the web browsers and operating systems pre-installed with major Root Certificate authority and Intermediate Certificate Authorities certificates with public keys as shown below from chrome.
Sample Certificate details can be viewed using openssl command line (check the highlighted areas):
bash$ openssl x509 -inform der -in ca_certificate_sample.cer -noout -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
08:3b:e0:56:90:42:46:b1:a1:75:6a:c9:59:91:c7:4a
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert Global Root CA
Validity
Not Before: Nov 10 00:00:00 2006 GMT
Not After : Nov 10 00:00:00 2031 GMT
Subject: C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert Global Root CA
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:e2:3b:e1:11:72:de:a8:a4:d3:a3:57:aa:50:a2:
8f:0b:77:90:c9:a2:a5:ee:12:ce:96:5b:01:09:20:
cc:01:93:a7:4e:30:b7:53:f7:43:c4:69:00:57:9d:
e2:8d:22:dd:87:06:40:00:81:09:ce:ce:1b:83:bf:
df:cd:3b:71:46:e2:d6:66:c7:05:b3:76:27:16:8f:
7b:9e:1e:95:7d:ee:b7:48:a3:08:da:d6:af:7a:0c:
39:06:65:7f:4a:5d:1f:bc:17:f8:ab:be:ee:28:d7:
74:7f:7a:78:99:59:85:68:6e:5c:23:32:4b:bf:4e:
c0:e8:5a:6d:e3:70:bf:77:10:bf:fc:01:f6:85:d9:
a8:44:10:58:32:a9:75:18:d5:d1:a2:be:47:e2:27:
6a:f4:9a:33:f8:49:08:60:8b:d4:5f:b4:3a:84:bf:
a1:aa:4a:4c:7d:3e:cf:4f:5f:6c:76:5e:a0:4b:37:
91:9e:dc:22:e6:6d:ce:14:1a:8e:6a:cb:fe:cd:b3:
14:64:17:c7:5b:29:9e:32:bf:f2:ee:fa:d3:0b:42:
d4:ab:b7:41:32:da:0c:d4:ef:f8:81:d5:bb:8d:58:
3f:b5:1b:e8:49:28:a2:70:da:31:04:dd:f7:b2:16:
f2:4c:0a:4e:07:a8:ed:4a:3d:5e:b5:7f:a3:90:c3:
af:27
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Certificate Sign, CRL Sign
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Subject Key Identifier:
03:DE:50:35:56:D1:4C:BB:66:F0:A3:E2:1B:1B:C3:97:B2:3D:D1:55
X509v3 Authority Key Identifier:
keyid:03:DE:50:35:56:D1:4C:BB:66:F0:A3:E2:1B:1B:C3:97:B2:3D:D1:55Signature Algorithm: sha1WithRSAEncryption
cb:9c:37:aa:48:13:12:0a:fa:dd:44:9c:4f:52:b0:f4:df:ae:
04:f5:79:79:08:a3:24:18:fc:4b:2b:84:c0:2d:b9:d5:c7:fe:
f4:c1:1f:58:cb:b8:6d:9c:7a:74:e7:98:29:ab:11:b5:e3:70:
a0:a1:cd:4c:88:99:93:8c:91:70:e2:ab:0f:1c:be:93:a9:ff:
63:d5:e4:07:60:d3:a3:bf:9d:5b:09:f1:d5:8e:e3:53:f4:8e:
63:fa:3f:a7:db:b4:66:df:62:66:d6:d1:6e:41:8d:f2:2d:b5:
ea:77:4a:9f:9d:58:e2:2b:59:c0:40:23:ed:2d:28:82:45:3e:
79:54:92:26:98:e0:80:48:a8:37:ef:f0:d6:79:60:16:de:ac:
e8:0e:cd:6e:ac:44:17:38:2f:49:da:e1:45:3e:2a:b9:36:53:
cf:3a:50:06:f7:2e:e8:c4:57:49:6c:61:21:18:d5:04:ad:78:
3c:2c:3a:80:6b:a7:eb:af:15:14:e9:d8:89:c1:b9:38:6c:e2:
91:6c:8a:ff:64:b9:77:25:57:30:c0:1b:24:a3:e1:dc:e9:df:
47:7c:b5:b4:24:08:05:30:ec:2d:bd:0b:bf:45:bf:50:b9:a9:
f3:eb:98:01:12:ad:c8:88:c6:98:34:5f:8d:0a:3c:c6:e9:d5:
95:95:6d:de
If we access any https website or url whose certificate is not found in operating system or browser CA certificates, it would show below message.
Google and most of the popular search engine and browser providers recommend the service provider to enable TLS/SSL certificate from known CA’s. if they would not get it, then they would de-prioritized in showing there information to the users.
below is the message you might see if the url is not https
What are Different Certificate Types and How to access them from programming language.
The format of the certificate we get from root CA file is base64 encoded X.509, we can use third party tools like openssh to covert X.509 to different formats. There are 2 type of encoded formats PEM encoded, DER encoded.
PEM encoding will have “ — BEGIN — and — END — ” for each of section like public key, private key and chain of certificates.
on the other hand DER is binary or base64 representation of PEM and mostly the extension of this would be .cer or .ctr
In general, on windows applications we might see DER encoded cer/ctr certificates used. in most of the other places PEM encoded certificate files would be used.
here is a very good explanation of different types of certificates and their usage.
On the application side we will have keystore (dont get confused with java keystore/truststore) to manage (add/remove/update) both public/private key pair and digital certificates.
There are 2 main keystores are in use
- if we are using java application then we would be dealing with JKS keystore
- if we are using java or other applications we would be dealing with PKCS#12(PFX). unlike JKS, we would be able to extract private keys from PKCS#12
There are two ways TLS/SSL handshake can happens.
- one way handshake
In this approach server application presents a certificate contains public key with CA or self signature.
Client would check whether the server’s certificate issued is from the known trusted CA to believe that the server application is trust worthy to access and start share information.
2. Two way handshake
In this approach server and client authenticity would be checked
server presents a certificate contains public key with CA or self signature.
Client would also send a self signed or CA issues certificate in return for client’s authenticity to server.
Java way to store and access certificate information
when we are developing client or server application using java, we might come across 2 more terms keystore and truststore for managing certificates in JKS file.
keystore usually used on the server and will have private and public key used for certificate creation and identifies the organization, and related only public key would be embedded in the certificate which would be shared with the clients.
truststore usually used on client application and holds all the known CA information.
when Server presents certificate contains CA and public key information, client would look for the CA in truststore file on his end and start the conversation if it finds an entry.
we can use “Keystore Explorer” tool or JDK provided “keytool” to view the content in the JKS.
sample of new JKS with just certificate + public key using “Keystore Explorer”
The point is if we are using java for client and server side development, we would be need import certificate files to JKS (keystore +truststore) file and set the password. for other languages we would use PKCS#12 keystore for managing the information.
below is sample code to load truststore jks file on client side to check the authenticity of the server.
import javax.net.ssl.SSLContext;
import org.apache.http.ssl.SSLContextBuilder;sslContext = SSLContextBuilder.create()
.loadTrustMaterial(ResourceUtils.getFile(properties.getTrustStore()), properties.getTrustStorePassword())
.loadKeyMaterial(null, null)
.setProtocol(properties.getProtocol())
.build();
Conclusion …
In This blog we understood, what is TLS and SSL. and How the data transferred between client and server.
we understood in detail about Certificate Authority, Self signed certificates and its mechanism.
we also understood different format of certificates used in different programming languages.
