Cryptography and Secure Connection: How It Works
How do we ensure the data we consume and send is safely transmitted? Here is what's happening behind the scenes with cryptography for secure connections.
Join the DZone community and get the full member experience.Join For Free
In today's digital world, everywhere and at all times, two parties exchange information, and day by day, it is growing exponentially. The exchange of data across systems is critical as they are vulnerable to attacks by external entities.
As the world moves everything towards digital, establishing a secure medium and understanding how it works also becomes more critical. In the past years, there was a lot of modernization along with the invention of PDA devices has completely changed the way we deal with our day-to-day life. We moved from retail shopping to online shopping, financial transactions happening over the counter are digitized, digitizing money, sharing pictures and list goes on.
Since most of our activities happen online, how do we ensure that the data we consume and send over the network is safely transmitted? What is happening behind the scenes and how it works is the one we will cover as part of this article.
When two parties are apart and want to exchange information, using a private network is not feasible and for everyone. So using a shared medium like the internet is only a viable option, and since it is shared, anyone can intercept the medium and peek at the exchanged information.
Since this is the case, two parties can adopt a Cryptography strategy, sending the message in a unique format called ciphertext, which can be read-only by the intended recipient. Earlier systems exchanged a shared secret key that the sender will use to encrypt and the receiver to decrypt; since both are using the same key, it is known as an asymmetric key. The receiver decodes using the secret key, which is only possible until both parties keep the key secret. If a man in the middle knows about the secret key, the hidden person can read and alter the message.
To communicate effectively using a public channel, we can utilize public-key cryptography, which uses two keys. One is public, and the other one is private. This technique is called asymmetric cryptography or public-key cryptography.
Public Key Cryptography
In public-key cryptography two keys are used; one is called the public key, and the other is the private key. The key pair is associated with each other, a public key cannot be used with other private keys or vice versa, and they are tied together. These keys are used in a hash function to generate the hash value of the data, and it is encrypted using the public key. The intended recipient of the message uses the corresponding private key to decrypt it, and only the associated private key will decrypt it.
If keys got in the hands of the middle man, he would send his public key to encrypt and use his private key to decrypt to alter the original message. Then he will encrypt with the intended recipient's public key; by this way, the original sender and receiver will not be aware of a man in the middle. They will think what they send and receive is accurate.
Since the public and private keys are vulnerable to getting into the hands of the middle man, there should be a way to authenticate the server, for which the server proves his identity by showing a certificate of his identity. The server obtains the certificate of his identity from a trusted third-party system which is called the Certificate Authority or CA. The CA is like a government office or a trusted agent who adheres to PKI standards and guidelines for issuing the certificate, and it is followed by all the entities who claim it as CA.
After validating the authenticity of the intended user, the CA issues a certificate and signs the certificate using its private key. That signature is known as the digital signature of the certificate. There are different varieties of certificates that are being used, and each has its purpose. In today's world of web exchange between a client and server, an X509 certificate is used, and it follows the ASN.1 (Abstract Syntax Notation One) standard.
The certificates are usually stored in the file system as binary data, which are often converted to Base64 ASCII files known as PEM (Privacy Enhanced Email), which have one of the extensions like .pem, .crt, .cer.
Below is the content of the X509 v3 certificate:
Data: Version: 3 (0x2) Serial Number Signature Algorithm Issuer Validity Not Before Not After Subject Subject Public Key Info Public Key Algorithm Public-Key X509v3 extensions Signature Algorithm Signature Value
A doctor's office wants to have a web page that allows the patients to register their details online and schedule an appointment. The server approaches the CA and proves his identity, and gets a certificate with his domain name (doctor's office) as the subject. The CA validates the doctor's office identity and issues the server an X509 certificate. See below the sample of the x509 certificate content generated using the OpenSSL command.
Secure Connection Using SSL/TLS
The secure connection between two parties is established using the SSL/TLS protocol standards. The SSL was used earlier, but it was deprecated due to security flaws, and now the TLS is primarily used. The SSL/TLS layer resides on top of the TCP/IP and before the Application layer. So the application residing in the application layer is automatically covered by the secure protocol.
Consider the doctor's office example, and before deploying the application to the public, the server does a few steps with the CA.
- The web server which hosts the doctor's office web page requests the CA the certificate.
- The CA validates the doctor's office applications and issues the certificate; it also signs it using its private key, the digital signature.
- The CA-issued certificate is known as the leaf or entity certificate, and it contains the public key used to authenticate the server.
- The server has a corresponding private key, and it resides on the server-side, where the doctor's office application is deployed.
- As mentioned earlier, the certificate will have the owner or subject that matches the doctor's office's domain. For example, www. doctoroffice.com.
- The patients from the browser invoke the doctor's office webpage. The request goes to the server through an insecure channel; the browser sends the SSL version it uses, cipher settings, and any other information the server needs to establish a secure SSL channel.
- The server, in turn, responds with its SSL Version, the cipher settings, and along with it, sends the certificate also known as leaf or entity certificate which it received from the CA.
- The client authenticates the leaf certificate received from the server with its truststore. The browser and today's computers come with most third-party CA's intermediate and root certificates embedded in the trust store.
- The browser searches in its truststore the corresponding intermediate certificate, which has signed the leaf certificate. Then uses the issuer's public key of the intermediate certificate to validate the digital signature (since the public and private key are paired); if it could authenticate the digital signature, the validation goes to the intermediates until it reaches the self-signed root and finally ends at the root. This validation is called certification path validation or certification chain.
- A certificate can have one or more intermediate certificates, and the chain has to be validated.
- Once the server certificate is authenticated, the client sends its certificate to the server on a need basis. In some cases, the client requests a resource and proves its identity by providing its certificate. Mainly in the case of browsers, there is no client authentication using certificates (Applications use other forms of authentication like username/password)
- If the client cannot validate the server certificate from the client's trust store, it will terminate the connection, and the browser will display a warning message.
- Also, the browser checks the domain name entered by the user against the subject name in the domain, displays an error message, and stops the further connection.
- On successful validation, the client generates a pre-master secret for that session using the agreed cipher and encrypts it using the server's public key, which comes as part of the leaf certificate.
- The server decrypts the pre-master secret using the server's private key and then generates the master secret. Then both client and server use the master secret to generate the session keys, symmetric key used to encrypt and decrypt the messages for that session.
How Does the Certificate Chain Look?
Validation of the Certificate Chain Using OpenSSL:
Validation of the certificate only with the intermediate.
Given below shows the validation of the certificate signed by a different intermediate.
Intermediate and root as one file for OpenSSL.
Verification of certificate chain passed with correct intermediate and root.
The OpenSSL was able to validate the leaf certificate after locating the correct intermediate and root certificates.
Understanding cryptography will provide us confidence about the websites we are visiting daily and will give more insight into what the browser is trying to communicate to us in case of any exceptions during handshake with other parties. The power of knowledge about certificate authentication will enable us to do more things safely online.
Opinions expressed by DZone contributors are their own.