How HTTPS (SSL) Works πŸ” & Differs From HTTP

Stop Web Form Spam - Our team is passionate about creating the best StopWebFormSpam stop spams for your business.
How HTTPS (SSL) Works πŸ” & Differs From HTTP

There has been a great deal of talk in the last few years about moving every website to HTTPS and SSL, and for a good reason.

If you want to know why you should use HTTPS, there are many reasons.

There are many benefits to switching to HTTPS, including better search engine rankings and better performance. You will also be able to use more features in your browsers. HTTPS is one of the three basic requirements for a progressive web application. Also, Chrome and other browsers will not mark your website as “not secure.”

HTTPS is also required to unlock modern browser features like Service Worker and hardware APIs like WebUSB and Bluetooth access.

SSL stands for secure Socket Layer. However, this protocol is obsolete and has been replaced by TLS (Transport Layer Security). Because many people have become accustomed to the acronym SSL, we still use it. The two terms are now interchangeable, but the actual encryption is now TLS, not SSL.

In the past, SSL certificates were expensive, which has changed today, as most certificates are free. When you pay for a certificate, you buy a certificate with a more rigorous authentication process and possibly insurance.

How does HTTPS or SSL work?

HTTPS is a secure form of HTTP. There is an encrypted Transport Layer Security (TLS) layer around HTTP. Communication between clients and servers using HTTP is now secure thanks to the TLS wrapper.

HTTPS is an acronym and stands for HyperText Transport Protocol secure. The “secure” part is essential because it makes a big difference.

HTTP is a “plain text” or binary file (e.g., an image) that anyone can read or view. HTTPS is based on public/private key cryptography. There is one key pair:

  1. The public key is used for encryption
  2. The secret private key is needed for decryption.

A certificate is a public key with a mark that identifies the holder.

Why Use HTTPS? What are the Advantages?

Consumer confidence is the first benefit. Internet security is important because nobody wants their private data to fall into the hands of the bad guys.

Browsers now visually show when a website is secured with HTTPS. If it is not secured, browsers display messages like ‘not secure‘ next to your domain. nothing tells you to hit the ‘back’ button more than when the browser tells the user that the page is not secure.

HTTPS unlocks new functionality. The website has added many new features, and many require a secure connection to protect user data. These features include service workers (a key feature of advanced web applications), Bluetooth, USB, WebRTC, push notifications, and more. You want to use many of these new features to engage with your customers.

HTTP/2, a modern refinement of the HTTP protocol, requires secure connections. With HTTP/2, your website can load much faster because it optimizes requests. HTTP/1.x allowed 2-6 parallel connections. HTTP/2 multiplies requests so that it can process more requests at the same time.

Search engines are utilizing HTTPS as a ranking signal. Consumers want secure sites, and search engines want to recommend secure sites over insecure destinations.

Lately, Bing has shown a ‘secure‘ icon for each HTTPS web page in the results, and Google has also experimented with secure icons.

How HTTP Works

Before we dive into how HTTPS works, let’s look at how HTTP works.

HTTP is a request-response protocol for asynchronous communication between clients and servers.

The browser acts as the client for websites and pages, and the webserver acts as the server, such as Apache or IIS. The server stores files (e.g., HTML, audio, video, etc.) and sends back data responses to client requests. It contains the status of the request depending on the request-response.

A series of messages are passed back and forth between the client and the server during the process. The process starts when the connection is initiated, followed by a process known as TCP slow start. Data is passed b/w the two parties via data packets and often needs multiple round trips.

The purpose of TCP slow start is to gradually increase the amount of data passing over the wire with each round trip. The initial packet size is 16 Kbytes, doubling over subsequent round trips until it reaches its maximum size. This can vary, but for most connections, it is usually around 4 MB.

This is used because the server does not know how much bandwidth the client can handle. Instead of overloading the client, the server uses a sparing size and increases it until the limit is reached.

The transmission of data or requests between client and server takes place in plain text, and this can be seen by anyone or by software that monitors network traffic.

This is not so important for general content. However, even if we do not assume that sensitive data is exchanged between the two parties, several sessions provide identifying information. Therefore, all websites should use TLS to protect HTTP connections.

The HTTPS Stack

For HTTPS, you must install a TLS certificate on your server. You can apply certificates to different protocols, such as HTTP (web), SMTP (email), and FTP. An SSL or TLS certificate works by storing your randomly generated keys (public and private) on your server. The public key is validated with the client, and the private key is used for decryption.

HTTP is only a protocol, but it is encrypted in combination with TLS or Transport Layer Security.

You might recognize TLS by an additional acronym, SSL. secure Socket Layer (SSL) was the original method we secured the Internet. As we progressed our criteria, we retired SSL; however, the acronym remains the additional, prominent term for TLS.

If you check out a network Stack diagram, HTTP goes to the top, on top of TLS, which sits on top of the TCP and IP layers.

I understand those are a lot of acronyms but don’t stress.

When HTTP is integrated with TLS, you get HTTPS, this secure version of HTTP.

The HTTPS Handshake

When your browser interacts with an HTTPS server, the server responds with its certificate. The browser checks whether the certificate is valid:

  1. the owner information must match the server name requested by the user
  2. a trusted certification authority must sign the certificate.

If any one of these conditions is not met, the user is notified of the problem.

When using HTTP, a series of handshakes take place. The first request is sent to the server for verification. If the server responds that it is the requested server, the client sends a welcome message.

At this point, the communication is encrypted, and Encryption keys or ciphers are exchanged.

At this point, the reader’s communication can continue. The first steps of the handshake take place within a few milliseconds.

When HTTPS is used, Which Element of the Communication is Encrypted?

After the HTTPS handshake is completed, the communication between the client and the server is encrypted. This includes the full URL, data (plain text or binary), cookies, and other headers.

The only part of the communication that is not encrypted is the domain or host to which the client has requested a connection. When the connection is established, the target server receives an HTTP request to establish a secure connection. Once HTTPS is established, the entire URL is used.

This initialization only requires to be done once for each connection. For this reason, HTTP/2 has a clear advantage over HTTP/1.1 because it can multiplex connections instead of opening multiple connections.

The Passive Attacker

First, we need to take a look at how HTTP works. It stands for Hypertext Transfer Protocol, and it is the way we move data around the Internet.

HTTP is unencrypted, which means that the data passing over the wire is visible to anyone who has access to it.

Bad people can passively read packets that pass over the internet, which means that they can read the text you send and receive. This is why it is essential to use secure protocols when sending personal and sensitive data. Let’s take a typical example of a cafΓ©. Many of us go to cafΓ©s, restaurants, and other public places with public Wi-Fi to work or socialize.

But if you know what the bad guys can see, you might want to rethink that strategy.

Wi-Fi is particularly vulnerable because it is transmitted over the air, and this means that anyone who wants to can see traffic in the air.

Attackers have been known to stay in public Wi-Fi environments and absorb the internet traffic around them. Using sophisticated analytics, they can then identify sensitive data that you may not have considered.

Maybe you’re researching data for an important work project, and the backstory happens to be a corporate spy. Of course, this is all made up, but it is meant to get you thinking about possible scenarios.

So with HTTP, your internet session is open to the public, and you have no absolute privacy.

Blocking the Passive Attacker

With HTTPS, the passive attacker I described earlier can no longer read your data, and this is because the actual data is wrapped in an encryption layer.

Only two parties can read the data, namely the server and your browser. The TLS layer acts as a shield that prevents unwanted eyes from watching your conversation.

The Active Attacker or Man In The Middle Attack

Sometimes the attackers are more aggressive. They create their infrastructure to redirect requests, and this is called a Man in the Middle attack. 

Man in the Middle attack Without utilizing HTTPS, you cannot be sure that you are communicating with the desired server. And the server can’t tell if it’s talking to you.

With HTTPS, there is a level of data integrity that shields you from an attacker intercepting your requests and the server’s responses. Certificates require that each end party knows how to encrypt and decrypt the data, and only they know how to do that.

If you’re wondering which TCP/IP protocol is the secure form of HTTP, it’s HTTPS. Without the keys to decrypt and encrypt packets, it’s just a bunch of gibberish.

When you develop a secure connection to a remote server, you effectively block this active attack. For example, baggy, I can’t install something on an Internet router that would intercept requests and route them to its server.

If you think the crook has forged the certificate, it can’t be done. At least he can’t create the certificate or try to decrypt the data using the public key. He will not have access to the private key. I told you encryption could be tricky!

The certificate includes the public key of the webserver. The attacker’s proxy server does not have a corresponding private key.

If the proxy server gives the client the actual certificate, it cannot decrypt its information to the webserver.

The attacker may create the certificate and provide its public key, which corrupts the Certificate Authority signature, and the browser will warn about the invalid certificate.

Is HTTPS secure?

Technically yes. The protocol can be attacked and potentially hacked, but this requires compromising components that are not under the control of the server and client. And these attacks are not simple.

  1. Break into any certification authority
  2. Compromise a router near any Certificate Authority
  3. Compromise a Certificate Authority‘s recursive DNS server
  4. Attack any other network protocol, such as TCP or BGP.
  5. The government may require the Certificate Authority to provide a malicious certificate (speculative only).

These attacks essentially mean that the issuing authority has been compromised. While Certificate Authority tends to be particularly crazy about their security, nothing is quite perfect, but as I said, an attack against these points is not a simple attack.

You should also note that TLS is not securing your server but the connections between your client and the server. If a hacker enters your server, it is probably a different attack, and they can’t sniff the data transmitted between the two nodes.

Different Type of HTTPS/TLS Certificates

There are three different levels of certificates:

  1. Domain validated
  2. Organization validated
  3. Extended validated

There is no technical difference b/w the three levels, at least not how they work, encrypting HTTP communication.

The difference is in how the website owner is validated. Today’s free certificates are domain validated. According to the domain’s WHOIS record, this is generally done by sending a confirmation email to the owner. It can also be validated via DNS records. This is my preferred method using AWS Route 53 and AWS Certificate Manager, and they work together to verify the certificate within seconds.

Organization and advanced validation require more documentation. These certificates also cost money, and the money usually covers the cost of the certification authority’s review of the documentation and provides better insurance coverage.

For most websites, a certificate with domain validation is sufficient. I discount the value of an OV or EV certificate, but I am aware it is suitable for some websites.

Wrapping it Up

HTTPS should be utilized everywhere. The excuses of the past are no more valid.

When you use HTTPS, you offer your visitors a secure connection. You can also trust that the communication is with your server and that someone is not passively or actively peeking in.

Enjoy the post? For More Posts Visit Stop Web Form Spam

Read More:

Comments

Popular posts from this blog

Protecting your WordPress site from spam with user-friendly contact forms

Load Time and Network Security: Ensuring Fast and Secure Web Performance