Hi everyone, welcome back to SrishCodes where I teach you interesting tech concepts that you should know about as a current or aspiring software developer. Today I will be sharing with you about the difference between HTTPS and HTTP, as well as some basic concepts that you should know about in this domain.

HTTP vs HTTPS

The S in "HTTPS" stands for "secure." HTTPS is just HTTP with SSL/TLS. A website with an HTTPS address has a legitimate SSL certificate issued by a certificate authority, and traffic to and from that website is authenticated and encrypted with the SSL/TLS protocol. We will go into detail about SSL/TLS in this article.

In practice, a secure web application will leverage below three services:

• Encryption: A mechanism to obfuscate what is sent from one host to another.
• Authentication: A mechanism to verify the validity of provided identification material.
• Integrity: A mechanism to detect message tampering and forgery.

Google advocates that SSL should be used everywhere on the web and the search engine rewards secured websites with improved web rankings, another great reason for any site to install SSL. Thus, not only is HTTPS essential for keeping users safe and user data secure, it has also become essential for building trust with users.

What is SSL?

Secure Sockets Layer (SSL) refers to a protocol for encrypting and securing communications that take place on the Internet. SSL is replaced by an updated protocol called Transport Layer Security (TLS).

SSL was originally developed by Netscape Communications Corporation in 1994 to secure ecommerce transactions on the web. SSL 1.0 was never publicly released, whilst SSL 2.0 was quickly replaced by SSL 3.0 on which TLS is based.

What is TLS?

TLS is a cryptographic protocol that provides end-to-end security of data sent between applications over the Internet. It avoids possible eavesdropping and/or alteration of the content.

Uses of SSL/TLS

1. Securing communications between client and server
2. Secure email, VoIP, other communications over unsecured networks

It does so by:

• Encrypt – This makes the content unreadable so that to anyone viewing the message it is just gibberish.
• Sign – This allows the recipient to be confident that it was you who sent the message, and that the message hasn’t been changed.

How does SSL/TLS work?

1. TLS handshake - two communicating parties open a secure connection and exchange the public key
2. During the TLS handshake, the two parties generate session keys and the session keys excrypt and decrypt all communications after the TLS handshake
3. A new session key is created in each new session
4. TLS ensures that the party on the server side, or the website the user is interacting with, is actually who they claim to be
5. TLS also ensures that data has not been altererd using a message authentication code (MAC) that is included with transmissions

With TLS, both HTTP data that users send to a website and the HTTP data that websites send to users is encrypted. Encrypted data has to be decrypted by the recipient using a key.

Symmetric vs asymmetric encryption

A TLS handshake uses something called asymmetric encryption, meaning that two different keys are used on the two ends of the conversation. This is possible because of a technique called public key cryptography.

Source

In symmetric encryption the two parties in a conversation use the same key. After the TLS handshake, both sides use the same session keys for encryption. Once session keys are in use, the public and private keys are not used anymore.

Session keys are temporary keys that are not used again once the session is terminated. A new, random set of session keys will be created for the next session.

Source

As you would have realised, TLS uses a combination of symmetric and asymmetric cryptography, as this provides a good compromise between performance and security when transmitting data securely.

Public key cryptography

In public key cryptography, two keys are used: a public key and a private key. Public and private keys are two different keys that are mathematically related and belong as a key pair. Given sufficient key length, it is computationally impractical to derive the private key from the public key. Data encrypted with the public key can only be decrypted with the private key, and vice versa.

During the TLS handshake, the client and server use the public and private keys to exchange randomly generated data, and this random data is used to create new keys for encryption, called the session keys.

Digital certificates

How do you know that a particular public key belongs to the person/entity that it claims to be? The answer is to use a digital certificate. A digital certificate provides a link between a public key and an entity (business,domain name etc) that has been verified (signed) by a trusted third party ( a certificate authority).

SSL certificates are small data files installed on a website's origin server that cryptographically establish an encrypted link between a web server and a browser. This link ensures that all data passed between the web server and browser remain private.

Technically, any website owner can create their own SSL certificate, and such certificates are called self-signed certificates. However, browsers do not consider self-signed certificates to be as trustworthy as SSL certificates issued by a certificate authority (CA).

Website owners need to obtain an SSL certificate from a certificate authority, and then install it on their web server (often a web host can handle this process). A certificate authority is an outside party who can confirm that the website owner is who they say they are. They keep a copy of the certificates they issue.

Authentication levels of certs

Authentication levels refer to the trustworthiness of a hosted URL. CA issue certificates to an organization on validating their identities. It mainly categorizes them in the three shown below:

• Domain Validation (DV): This is the lowest level of validation done by the CA to issue a certificate to an organization. Here, CA only verifies whether an organization controls the domain or not. This process can be done via email.
• Organization Validation (OV): This is the medium level of validation done by the CA to issue a certificate to an organization. Here, CA validates the name, state, and country of an organization. This process can be done by physically verifying the organization’s location.
• Extended Validation (EV): This is the highest level of validation done by the CA to issue a certificate to an organization. Here, CA validates ownership, physical location, state, and country of organization. This process can be done by physically verifying the organization’s location and checks the legal existence.

Message authentication code

Message authentication code (MAC) is a digital signature confirming that the communication originated from the actual website. This authenticates the server, preventing on-path attacks and domain spoofing. It also ensures that the data has not been altered in transit.

Cipher suite

A cipher suite is a set of encryption algorithms, or a set of mathematical operations, for use in establishing a secure communications connection. There are a number of cipher suites in wide use, and an essential part of the TLS handshake is agreeing upon which cipher suite will be used for that handshake.

TLS handshake

TLS handshakes are a series of datagrams, or messages, exchanged by a client and a server. The exact steps within a TLS handshake can vary but the RSA key exchange algorithm shown below is used most often.

1. The 'client hello' message: The client initiates the handshake by sending a "hello" message to the server. The message will include which TLS version the client supports, the cipher suites supported, and a string of random bytes known as the "client random."
2. The 'server hello' message: In reply to the client hello message, the server sends a message containing the server's SSL certificate, the server's chosen cipher suite, and the "server random," another random string of bytes that's generated by the server.
3. Authentication: The client verifies the server's SSL certificate with the certificate authority that issued it. This confirms that the server is who it says it is, and that the client is interacting with the actual owner of the domain.

Source

1. The premaster secret: The client sends one more random string of bytes, the "premaster secret." The premaster secret is encrypted with the public key and can only be decrypted with the private key by the server. (The client gets the public key from the server's SSL certificate.)
2. Private key used: The server decrypts the premaster secret.
3. Session keys created: Both client and server generate session keys from the client random, the server random, and the premaster secret. They should arrive at the same results.
4. Client is ready: The client sends a "finished" message that is encrypted with a session key.
5. Server is ready: The server sends a "finished" message encrypted with a session key.
6. Secure symmetric encryption achieved: The handshake is completed, and communication continues using the session keys.

Credits

Cons of RSA key exchange

The RSA handshake works, but has a critical weakness: the same public-private key pair is used both to authenticate the server and to encrypt the symmetric session key sent to the server. As a result, if an attacker gains access to the server’s private key and listens in on the exchange, then they can decrypt the the entire session. Worse, even if an attacker does not currently have access to the private key, they can still record the encrypted session and decrypt it at a later time once they obtain the private key.

As a result, the RSA handshake is being actively phased out and Diffie-Hellman key exchange is more popular now. Read more on Diffie-Hellman here.

Example

1. Browser connects to server using SSL (https)
2. Server Responds with Server Certificate containing the public key of the web server
3. Browser verifies the certificate by checking the signature of the CA
4. Browser uses this Public Key to agree a session key with the server
5. Web Browser and server encrypt data over the connection using the session key

---

And that was all for this now! Make sure to leave a comment and follow me for more content. Until next time