HTTP (Hypertext Transfer Protocol) and HTTPS (Hypertext Transfer Protocol Secure) are fundamental protocols for transmitting data over the web. They govern how information is exchanged between clients (such as web browsers) and servers. Let's dive into how HTTP and HTTPS work, using examples to illustrate their functionalities and security aspects.
HTTP: The Basics
Consider Alice as a user and Bob as a web server. When Alice accesses a website using HTTP, her browser sends a request to Bob's server, asking for specific content, like a web page. Bob's server then responds by sending the requested data back to Alice's browser.
HTTP operates over port 80 by default and transfers data in plaintext, making it susceptible to interception and tampering. Here's how a typical HTTP scenario might unfold:
Alice's Request (HTTP):
Alice's browser sends an HTTP request to Bob's server for a webpage (e.g., http://example.com).Bob's Response (HTTP):
Bob's server responds to Alice's request with the requested webpage's content in plaintext.
Now here is the catch, suppose Bob wants to transmit a confidential information that only Alice should receive, he can not do so in this protocol. The request is hopped over multiple routers before it reaches Alice and vice versa for Bob. Any information provided in plain text, is vulnerable to cyber secruity attacks like phishing, man in the middle attack and replay attacks.
HTTPS: Enhancing Security
HTTPS addresses the security vulnerabilities of HTTP by adding an extra layer of encryption using SSL/TLS (Secure Sockets Layer/Transport Layer Security). Let's see how Alice and Bob communicate securely using HTTPS:
Alice's Secure Request (HTTPS):
Alice's browser initiates a secure connection with Bob's server by sending an HTTPS request (e.g., https://example.com).SSL/TLS Handshake:
Alice's browser and Bob's server perform an SSL/TLS handshake to establish a secure encrypted connection. This involves exchanging cryptographic keys and verifying the server's identity.Encrypted Data Transfer:
Once the secure connection is established, all data exchanged between Alice's browser and Bob's server is encrypted, ensuring confidentiality and integrity.Bob's Secure Response (HTTPS):
Bob's server responds to Alice's HTTPS request with encrypted data, which Alice's browser decrypts for display.
This sounds simple when represented like above. But the main issue is, how do we ensure that the encrypted data is read properly by the receiver? We need a way to exchange the keys securely. If our keys are exposed, this protocol will become no better than simple HTTP.
Public key cryptography:
Public key cryptography is a very smart way of encrypting the data. Algorithms like RSA, DSA and Diffie-Hellman algorithms are used for public key cryptography.
These algorithms are capable for taking the plain text as input and generate two keys - one using which the data is encrypted, other using which we can decrypt the data. These 2 keys are called our public and private keys. Based on our applications, like Digital Signature, Encryption etc, we use them interchangeably.
Key Exchange in HTTPS
Client Hello:
When Alice's browser initiates an HTTPS connection to Bob's server, it sends a "Client Hello" message. This message includes supported cryptographic algorithms, random data, and other parameters.Server Hello:
Bob's server responds with a "Server Hello" message. This message contains the chosen cryptographic algorithms, a server-generated random value, and the server's SSL/TLS certificate.Certificate Exchange:
The server sends its SSL/TLS certificate to Alice's browser. This certificate contains the server's public key, information about the certificate issuer (Certificate Authority or CA), and the server's domain name.Public Key Encryption:
Alice's browser uses the server's public key from the certificate to encrypt a "pre-master secret" and sends it to the server.Master Secret Derivation:
Both Alice's browser and Bob's server use the exchanged pre-master secret and their respective random values to derive a "master secret." This master secret is used for symmetric encryption during the HTTPS session.
Server Identity Verification and Certificate Validation
Certificate Chain Validation:
Alice's browser checks the server's SSL/TLS certificate for validity. This includes verifying the certificate's expiration date, the issuing CA's signature, and ensuring the certificate hasn't been revoked.Root CA Trust:
Alice's browser validates the server's certificate chain up to a trusted root CA (Certificate Authority) stored in the browser's trust store. If the chain is valid and trusted, the server's identity is considered verified.Hostname Verification:
Alice's browser matches the server's domain name (e.g., example.com) with the domain name listed in the server's certificate (Subject Alternative Name or Common Name field). This ensures that Alice is connected to the intended website.
Certificate Handling and Renewal
Certificate Issuance:
Bob's server obtains an SSL/TLS certificate from a trusted CA. This certificate includes the server's public key and is digitally signed by the CA to establish its authenticity.Certificate Renewal:
SSL/TLS certificates have expiration dates. Bob's server periodically renews its certificate before expiration to ensure uninterrupted HTTPS service. Renewed certificates undergo the same validation and issuance process.Certificate Revocation:
If a certificate is compromised or no longer valid, it can be revoked by the issuing CA. Alice's browser checks for certificate revocation using Certificate Revocation Lists (CRLs) or Online Certificate Status Protocol (OCSP) to ensure the server's certificate is still valid.
Browser Validation and Secure Connection
Secure Connection Established:
After successful key exchange, certificate validation, and identity verification, a secure connection is established between Alice's browser and Bob's server.Encrypted Data Transfer:
All data exchanged between Alice's browser and Bob's server during the HTTPS session is encrypted using symmetric encryption keys derived from the master secret.Trust Indicators:
Alice's browser displays trust indicators such as a padlock icon and "https://" in the URL bar, indicating a secure connection. Extended Validation (EV) certificates may display the organization's name for enhanced trust.
Advantages of HTTPS Over HTTP
Data Encryption: HTTPS encrypts data during transmission, preventing unauthorized access and interception.
Data Integrity: HTTPS ensures that data remains unaltered during transmission, preventing tampering by malicious actors.
Authentication: HTTPS verifies the identity of the server, protecting against phishing and man-in-the-middle attacks.
Trustworthiness: HTTPS builds user trust by indicating a secure connection through the padlock icon in browsers and "https://" in URLs.
Conclusion
HTTPS ensures secure data transmission over the internet by employing strong encryption, server identity verification through SSL/TLS certificates, and rigorous validation processes. Understanding the intricate steps involved in key exchange, certificate handling, and browser validation helps ensure secure and trustworthy web interactions for users like Alice and servers like Bob.
HTTP and HTTPS are critical protocols for web communication, with HTTPS offering enhanced security through encryption, data integrity, and server authentication. In the digital age, where privacy and security are paramount, HTTPS has become the standard for secure data transmission over the internet. Understanding the differences between HTTP and HTTPS helps users like Alice and servers like Bob ensure secure and reliable web interactions.
Top comments (1)
Interesting. But still I feel confused about the "master secret". How does it get transferred and at the same time be asosciated with a different random value on both sides ?