022.2 Lesson 1

In web communications, it is crucial to distinguish between plain text protocols and transport encryption. Plain text protocols send data in a readable format, meaning information can be easily intercepted and viewed by malicious actors. HTTP (Hypertext Transfer Protocol) is a plain text protocol, where all data is transmitted without any form of encryption, leaving it vulnerable to eavesdropping and tampering.

HTTP defines how web clients (e.g., browsers) communicate with web servers. As an application-layer protocol, HTTP is independent of the underlying transport-layer or session-layer protocols (HTTP as part of the internet stack). However, in its original form, HTTP transmits data as plain text, encapsulated in transport segments (such as TCP) without encryption, making it susceptible to interception.

Transport encryption offers a solution by encoding data during transmission, converting it into an unreadable format. Even if the data is intercepted, it cannot be decoded without the correct decryption keys. This approach ensures the confidentiality and integrity of data, preventing unauthorized access and modification. Transport Layer Security (TLS) is the most widely used protocol for transport encryption, providing the foundation for the secure version of HTTP, known as HTTPS.

As the internet evolved to handle sensitive and commercial transactions, a need arose for a protocol to protect this data. Secure Sockets Layer (SSL), introduced in the 1990s, served this purpose but has since been replaced by its successor, Transport Layer Security (TLS). TLS remains the standard for securing communication between clients and servers over insecure channels.

TLS is comprised of several key elements, including encryption protocols, digital certificates for server identity verification, and two primary TLS protocols: the TLS handshake protocol and the TLS record protocol. These components work together to provide a secure connection between client and server (TLS protocols as part of the internet stack.).

The TLS handshake protocol is responsible for the initial authentication between the client and server, during which they exchange cryptographic keys and agree on an encryption algorithm. The TLS handshake ensures that the connection is secure before any application data is exchanged. Successful authentication requires the server to present a digital certificate signed by a trusted Certificate Authority (CA), confirming its identity.

TLS also includes the TLS record protocol, which encapsulates higher-level protocols and provides privacy and data integrity. Privacy is achieved through symmetric encryption, while data integrity is ensured by incorporating a Message Authentication Code (MAC) to detect tampering during transmission. This dual-layered approach guarantees that communications remain private and secure.

HTTPS, or Hypertext Transfer Protocol Secure, is simply HTTP running over TLS (HTTPS as part of the internet stack). The purpose of HTTPS is to safeguard data transmitted between a visitor’s browser and a web server by encrypting it and verifying the server’s identity.

When a visitor requests access to a website using HTTPS, the server presents an X.509 digital certificate to the browser. This certificate, issued by a trusted Certificate Authority (CA), authenticates the server’s identity. Once verified, the browser establishes a secure connection using symmetric encryption, often facilitated by key exchange methods such as Diffie-Hellman or Elliptic Curve Diffie-Hellman (ECDH).

The primary advantage of HTTPS is that it provides confidentiality, integrity, and authentication for web communications. Data transmitted via HTTPS is protected from interception or tampering, and the server’s identity is verified to prevent visitors from unknowingly interacting with malicious websites.

Modern browsers offer visual indicators, such as a padlock icon in the address bar, to signal that a website is using HTTPS. However, if the certificate is expired, improperly configured, or untrusted, browsers may display warning messages to inform visitors of potential security risks. These warnings help prevent attacks such as man-in-the-middle interceptions by alerting visitors when the connection may be compromised.

The shift from HTTP to HTTPS has been driven by the increasing demand for privacy and security on the web. Most browsers and search engines now prioritize HTTPS-enabled websites, reflecting the importance of secure communication in today’s digital landscape.

The default port for HTTPS communication is TCP 443, while HTTP uses TCP 80. The difference in port numbers allows servers to distinguish between secure and insecure traffic. When a browser requests a webpage via HTTPS, the initial connection involves the TLS handshake, during which the server’s identity is authenticated and encryption keys are exchanged.

Once the TLS handshake is complete, the browser sends the first HTTP request, and all subsequent data exchanges are encrypted, ensuring that sensitive information, such as login credentials or payment details, remains secure throughout the session.

Many websites are configured to automatically redirect visitors from HTTP to HTTPS to enforce secure connections. For example, if a visitor requests http://www.example.com, the server may redirect them to https://www.example.com, ensuring that the communication is encrypted and secure.

HTTPS server authentication relies on digital certificates, specifically X.509 certificates, to verify the identity of the server. When a visitor enters a URL, the browser retrieves the server’s digital certificate, which contains the public key and identity information. This certificate is signed by a trusted Certificate Authority (CA), ensuring that the server is legitimate.

X.509 certificates, also known as SSL or TLS certificates, bind a public key to the server’s identity, referred to as the Subject of the certificate. The CA’s digital signature confirms the validity of this binding, which is stored in the signatureValue field of the certificate.

The X.509 standard defines the structure of digital certificates. Version 3 (X.509v3) introduced the ability to add extensions to certificates, allowing the inclusion of additional information, such as alternate names for the server.

The Subject Alternative Name (SAN) extension enables a certificate to associate multiple identities, such as DNS names or IP addresses, with the same server. This flexibility is crucial for servers that operate under multiple domain names or IP addresses, as it allows one certificate to cover all relevant identities.

The process of verifying a certificate involves checking the Subject or Subject Alternative Name against the server’s identity. If a match is found, the certificate is considered valid. Wildcards, such as *.example.com, can also be used to match multiple subdomains, providing greater flexibility in certificate management.

Certificates are issued by Intermediate CAs, which are part of a chain of trust that leads back to a trusted Root CA. The browser verifies the chain of trust by matching the Issuer field of each certificate with the Subject of the next certificate in the chain, ultimately reaching a trusted Root CA.

Certificates have a defined validity period, which indicates the time frame during which the certificate is valid. If a certificate becomes compromised before its expiration, the CA can revoke it and publish its serial number in a Certificate Revocation List (CRL). Browsers use CRLs to verify the certificate’s status and ensure it hasn’t been revoked.

HTTPS servers are often configured to automatically redirect HTTP traffic to HTTPS. Suppose that the web client in this situation, such as if an internet browser sends a request to the following URI, specifying HTTP:

The HTTPS server would redirect the client to a URI specifying HTTPS, such as:

When a web browser connects to a website using HTTPS, it performs several essential validity checks on the website’s X.509 certificate to ensure that the connection is secure and trustworthy. These checks verify the authenticity of the certificate, confirm the identity of the website, and protect visitors from potential security threats such as man-in-the-middle attacks. The browser conducts a series of steps to evaluate the certificate’s validity.

The format of public key certificates is defined by the X.509 standard, which was first published in 1988. The X.509 version 3 (v3) certificate format, which was developed in 1996, extends the format by adding provision for additional Extensions fields (X.509 v3 certificate).

The public key certificate’s Subject field identifies the HTTPS server associated with the public key stored in the Subject Public Key Info field. The Extensions field can convey such data as additional subject identification information.

The Subject Alternative Name extension to the X. 509 specification allows additional identities to be bound to the subject of the certificate. Subject Alternative Name options can include a DNS hostname, an IP address, and more.

The subject name may be carried in the Subject field, in the Subject Alternative Name extension, or in both. If a SAN extension of type DNS Name is present, it is used as the server’s identifier. Otherwise, the most specific Common Name field in the Subject field of the certificate is used as the identity.

If more than one identity of a specific type is present in the certificate — e.g., more than one DNS Name field — a match in any field of the set is considered acceptable. Names can contain the * (asterisk) wildcard character to match any single domain name component or component fragment. Thus, if the URI is https://www.example.com/~carol/home.html and the server’s certificate contains *.basket.com, abcd.com, and *.example.com as DNS Name options, there is an acceptable match: The *.example.com name matches www.example.com. That wildcard name would not match basket.carol.example.com because the latter domain name contains an extra component.

Similarly, c*.com matches carol.com because the asterisk can match a fragment of a component, but does not match basket.com.

If the URI’s host field includes an IP address, such as https://8.8.8.8, rather than a hostname, the client verifies the IP Address field of the Subject Alternative Name extension. The IP Address field must be present in the certificate and must exactly match the IP address in the URI.

Next, the browser checks the certificate’s chain of trust. It verifies that the certificate has been issued and signed by a trusted Certificate Authority (CA). This involves tracing the certificate’s chain from the website’s certificate through intermediate certificates up to a trusted root CA, which is included in the browser’s pre-installed root certificate store. If any certificate in this chain is not valid or is issued by an untrusted CA, the browser flags the connection as insecure, warning the visitor.

Another critical check involves the certificate’s validity period. Every X.509 certificate specifies a timeframe within which it is valid, defined by the notBefore and notAfter fields. The browser checks the current date and time against this validity period. If the certificate has expired or is not yet valid, the browser alerts the visitor, suggesting that the connection may not be safe. This process ensures that certificates are renewed regularly to maintain secure communication.

Additionally, browsers perform checks to determine whether the certificate has been revoked by the CA. This is done through methods like querying a Certificate Revocation List (CRL) or using the Online Certificate Status Protocol (OCSP). If the certificate has been revoked due to reasons such as a compromised key or mis-issuance, the browser warns the visitor that the certificate is no longer trustworthy and that the connection may be insecure.

The browser also validates the certificate’s digital signature to confirm that it has not been tampered with since it was issued. This involves verifying the cryptographic signature of the issuing CA. If the signature fails to verify, it suggests that the certificate may have been altered or forged, leading the browser to block the connection to ensure the visitor’s safety.

Finally, browsers review any key usage or extension fields within the certificate. These fields specify the intended purposes of the certificate, such as server authentication or code signing. The browser ensures that the certificate is being used in line with these defined purposes. If the certificate is being used for a purpose outside the allowed scope, the browser issues a warning to the visitor.

These checks collectively ensure the security of web communications by validating the authenticity, integrity, and proper use of X.509 certificates. If any of these checks fail, the browser displays a security warning or error message, advising the visitor to proceed with caution or to avoid the website entirely. This rigorous validation process plays a critical role in maintaining the trustworthiness of online interactions and helps prevent malicious entities from impersonating legitimate websites.

Determining whether a website is encrypted is a crucial step in ensuring secure communication between a visitor’s browser and the website’s server. Encrypted websites use HTTPS, which provides encryption through the TLS protocol, ensuring that data exchanged between the visitor and the site remains private and protected from eavesdropping or tampering.

To determine whether a website is encrypted, visitors can rely on a few visual cues provided by web browsers. The most common indicator is the padlock icon that appears in the browser’s address bar to the left of the URL. If the website is using HTTPS, the padlock will appear closed or locked, signaling that the connection is secure. In some browsers, clicking on the padlock icon will display more detailed information about the website’s encryption, such as the type of encryption being used and the issuing CA.

In addition to the padlock, the URL itself is another indicator of whether a site is encrypted. Secure websites begin with https://, while unencrypted sites use http://. The presence of https:// indicates that the connection is protected by TLS encryption. Some browsers may also highlight this by changing the color of the address bar when a secure connection is established.

When a website does not use encryption, modern browsers often display a warning message to inform visitors of the potential risks. For example, when a visitor tries to access a site using plain HTTP (without encryption), the browser may show a message such as “Not Secure” in the address bar. In some cases, browsers may display a more prominent warning, alerting the visitor that the “connection is not private” and advising them to avoid entering sensitive information such as passwords or credit card numbers. Browsers such as Google Chrome, Mozilla Firefox, and Microsoft Edge have been increasingly stringent in flagging unencrypted websites, especially on pages where visitors are asked to submit personal information.

If a website’s HTTPS configuration is invalid or incorrectly set up, browsers provide additional warning messages. For example, if a site has an “expired,” “misconfigured,” or “untrusted” certificate, the browser may present a full-page warning message with a description of the issue. Messages like “Your connection is not private” or “Potential Security Risk Ahead” indicate that the certificate is expired, revoked, or signed by an untrusted CA. These warnings usually recommend that visitors return to safety by not proceeding to the site, though they often provide an option to proceed at the visitor’s own risk.

Determining whether a website is encrypted involves checking for visual indicators such as the padlock icon and https:// in the URL. Browsers also display clear warnings when a site is not secure, ensuring that visitors are informed of potential risks associated with unencrypted or misconfigured connections. Understanding these browser messages is essential for safe browsing and avoiding exposure to security threats.