HTTPS: Underneath the security umbrella

Most people are aware of the acronym HTTPS, which takes pride and place at the start of authenticated web addresses. However, many may not be as aware of its function, origin or limitations.

In this series, I want to shed some light on these and other fascinating facts associated with what has become the most common protocol for secure online communication.

What is HTTPS and where did it come from?

HTTPS (also called HTTP over TLS, HTTP over SSL, and HTTP Secure) is a protocol for secure communication over a computer network. It consists of communication over Hypertext Transfer Protocol (HTTP) encrypted by Transport Layer Security (TLS) or Secure Sockets Layer (SSL).

Its origins can be traced back to 1994 when Netscape Communications created SSL 1.0. However, this initial version was never shipped. The first working version, SSL 2.0, was packaged in Netscape Navigator in late 1994 and was updated to SSL 3.0 in 1995.

In 1996, the Internet Engineering Task Force (IETF) took over the responsibility for the protocol from Netscape and renamed it as Transport Layer Security (TLS), which they released in 1999. The combination of HTTP with SSL/TLS led to the formation of a protocol that would later rule the web – HTTPS.

How does HTTPS work?

The purpose of HTTPS is to ensure secure online communication. From a generic perspective, this “security” umbrella basically consists of three dimensions:

• Authenticity: The user is talking to the “real” website, and not to an impersonator or a “man-in-the-middle”.
• Confidentiality: The visitor’s connection is encrypted, obscuring URLs, cookies and sensitive metadata.
• Integrity: The data sent between the user and the website has not been tampered with or modified.

So the first requirement is to become “authentic”. To confirm authenticity, a website needs to obtain an SSL certificate from a certificate authority (commonly termed as CA).

How do you get a SSL certificate?

There are many entities providing CA services, for example, Comodo, Symantec, Godaddy, and Trustwave. However, this business is slightly fragmented, with national or regional providers dominating their home market. This is because the use of digital certificates are often linked to local laws, regulations, and accreditation schemes for CAs.

To buy an SSL certificate, you usually require the following:

• A unique IP address – A separate public IP address is required for each certificate.
• A CSR – A certificate signing request or CSR is text that gets generated on the web server while ordering the SSL certificate. The CA uses the information contained in the CSR (organization name, domain name, public key, etc…) to create the certificate.
• Correct contact information in WHOIS record – The CA usually checks the WHOIS record (the ownership and contact information associated with each domain name) to verify that the request has come from the right source.
• Business/organization validation documents – In case of purchasing a high-assurance certificate, CAs often check government databases to verify whether the company (owner of the web domain) is registered.

There are various kinds of SSL certificates, including:

Domain Validation (DV) SSL Certificates: Here the CA only checks whether the applicant has the right to use the mentioned domain name.

Organization Validation (OV) SSL Certificates: In this case, the CA checks the right of the applicant to use a specific domain name along with some verification of the organization. Additional vetted company information is displayed to customers when clicking on the Secure Site Seal.

Extended Validation (EV) SSL Certificates: In this case the (CA) checks the right of the applicant to use a specific domain name along with an extensive vetting of the organization. The issuance process of EV SSL Certificates is strictly defined in the EV Guidelines, as defined by the CA/Browser Forum.

The time required to validate an SSL certificate depends on the type of certificate. For example, domain-validated only certificates can be received within a few minutes. An organization-validated certificate can be obtained within an hour to a few days. And it can take several days to a few weeks to obtain an extended validation certificate (EV).

Once validated, the CA issues the requestor a new public key (certificate) encrypted with the CA’s private key. The requestor then installs the certificate on their web server.

How will this ensure authenticity, confidentiality and integrity during online communication?

To understand this, let’s take a simplified look at what happens when a user is accessing a secured HTTPS site which possesses an SSL certificate:

1. The user creates a connection to the site on an SSL port, typically 443. This connection is denoted with HTTPS instead of http.
2. The website sends back its public key to the user.
3. Once the user receives it, his/her browser decides if it is all right to proceed, based on the following checkpoints:
   • The public key has not expired
   • The public key is for that particular site only
   • The user has the public key of the corresponding CA (who has issued an SSL certificate to that site) in their browser certificate store. In almost all cases, the browsers have those CA public keys. Once the customer’s browser becomes sure that this SSL certificate has been issued by a trusted CA, they then proceed to communicate with that website.
4. The customer sends to the website their public key.
5. The website creates a unique hash and encrypts it (using the customer’s public key and its private key), and sends this back to the customer. This ensures that only that particular website has sent the hash and only the customer is able to read it.
6. The customer’s browser decrypts the hash.
7. The customer and website can now securely exchange information.

In my next posts I will look at the growth in popularity of HTTPS as well as some of its limitations.

Azfar Adib works for Bangladesh ISP and Telco, Grameenphone Ltd. He is focused on review and analysis of data-service related trends and their impact.

Rate this article

---

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.