Secure Web Communication: DNS, PKI, Certificates, and HTTPS

 

Secure Web Communication: DNS, PKI, Certificates, and HTTPS 

1. Domain Names and DNS Resolution

A domain name (e.g., mybank.com) is a human-readable identifier that resolves to one or more IP addresses (e.g., 192.0.2.1, 2001:db8::1). This indirection is implemented by the Domain Name System (DNS), a distributed, hierarchical naming system.

Resolution typically proceeds via:

  • Stub resolver → recursive resolver

  • Recursive resolver → authoritative name servers

  • Response caching at multiple layers (OS, browser, resolver)

DNS primarily provides availability and scalability, not security. Classic DNS responses are unauthenticated and susceptible to:

  • Cache poisoning (forged responses inserted into resolver cache)

  • Spoofing and on-path manipulation

DNSSEC (Domain Name System Security Extensions) augments DNS with origin authentication and integrity using a chain of trust from the root zone down to the queried name. Records are signed (RRSIG), and resolvers validate signatures via DNSKEY/DS records. DNSSEC does not provide confidentiality; it ensures that the data received is authentic and unmodified.

2. Public Key Infrastructure (PKI)

PKI is the trust framework that enables entity authentication and secure key establishment over untrusted networks. It combines:

  • Asymmetric cryptography (public/private key pairs)

  • Digital certificates (binding identities to public keys)

  • Trust anchors (root CAs embedded in client trust stores)

  • Validation and revocation mechanisms (path building, OCSP/CRL)

Core security properties delivered by PKI-enabled protocols:

  • Authentication (entity identity assurance)

  • Confidentiality (encryption of data in transit)

  • Integrity (tamper detection)

Trust is transitive via certificate chains: end-entity certificate → intermediate CA(s) → root CA (trust anchor).

3. Digital Certificates (X.509)

A digital certificate is a signed data structure (typically X.509 v3) that binds a subject identity (e.g., mybank.com) to a public key.

Key fields include:

  • Subject (often represented via Subject Alternative Name—SAN—for DNS names)

  • Subject Public Key Info (SPKI)

  • Issuer (the signing CA)

  • Validity (Not Before / Not After)

  • Extensions (e.g., Key Usage, Extended Key Usage, Basic Constraints, SAN)

  • Signature (CA’s digital signature over the TBSCertificate)

Modern TLS clients rely on SAN rather than the deprecated Common Name for hostname validation.

4. Certificate Authorities (CAs) and Trust Model

A Certificate Authority validates domain control (DV), organizational identity (OV), or extended validation (EV), and issues certificates by signing them with its private key.

Operational realities:

  • Public trust stores (browsers/OS) define which root CAs are trusted

  • Intermediate CAs are used to limit exposure of root keys

  • Certificate Transparency (CT) provides append-only public logs of issued certificates, enabling ecosystem-wide auditing

  • Revocation is handled via OCSP (online checks) and CRLs, though revocation remains a known weak point in practice

Absent trusted CAs, clients cannot reliably distinguish legitimate servers from impostors.

5. HTTPS and the TLS Handshake (Modern View)

HTTPS = HTTP over TLS. TLS (v1.2 and v1.3) provides authenticated, encrypted channels.

Connection Establishment (TLS 1.2 with ECDHE or TLS 1.3)

  1. DNS Resolution
    Client resolves mybank.com to an IP address (optionally validated with DNSSEC).

  2. ClientHello
    Client proposes protocol version, cipher suites, supported groups, and extensions (e.g., SNI, ALPN).

  3. ServerHello + Certificate
    Server selects parameters and presents its certificate chain (end-entity + intermediates).

  4. Certificate Validation (Client-side)

    • Chain building to a trusted root

    • Signature verification at each step

    • Hostname validation against SAN

    • Validity period checks

    • Revocation status (OCSP/CRL; OCSP stapling preferred)

  5. Key Exchange (Critical Detail)
    Modern deployments use ephemeral Diffie–Hellman (e.g., ECDHE):

    • Both parties contribute ephemeral key shares

    • A shared secret is derived without transmitting it

    • Ensures Forward Secrecy (compromise of long-term keys does not expose past sessions)

    Note: Older RSA key transport (encrypting a premaster secret with the server’s public key) is deprecated and largely eliminated in TLS 1.3.

  6. Handshake Completion
    Both sides derive symmetric session keys via a key schedule (HKDF in TLS 1.3), authenticate the handshake (Finished messages), and switch to encrypted records.

  7. Secure Data Transfer
    Application data is protected using symmetric AEAD ciphers (e.g., AES-GCM, ChaCha20-Poly1305) for performance and integrity.

6. Security Guarantees

  • Authentication: Server identity is verified via certificate and PKI trust chain

  • Confidentiality: Strong encryption protects data in transit

  • Integrity: AEAD ensures tamper detection

  • Forward Secrecy: Ephemeral key exchange protects past sessions against future key compromise

7. Threats and Mitigations

Phishing (lookalike domains, IDN homographs)

  • Mitigations: user vigilance, browser heuristics, HSTS preload lists, certificate transparency monitoring

Man-in-the-Middle (MITM)

  • Mitigations: strict certificate validation, TLS 1.3, HSTS, certificate pinning (primarily in mobile/controlled clients)

Misissued or Rogue Certificates

  • Mitigations: CT logs + monitoring, rapid revocation, reduced certificate lifetimes, multi-perspective validation

Compromised CA

  • Mitigations: ecosystem response (trust store updates), CT auditing, constrained intermediates, short-lived certs

DNS Attacks

  • Mitigations: DNSSEC for authenticity; DoT/DoH for confidentiality between client and resolver (complementary, not a replacement for DNSSEC)

8. Synthesis

A secure web session to https://mybank.com is the composition of:

  • DNS → name resolution (optionally authenticated via DNSSEC)

  • PKI → identity binding and trust distribution

  • X.509 certificates → verifiable association of domain to public key

  • TLS (HTTPS) → authenticated key exchange and encrypted transport

Together, these layers provide a robust, interoperable security model for high-risk domains such as online banking and financial services.

Comments

Post a Comment

Popular posts from this blog

Differences Between Ubuntu 24.04.2 LTS and Ubuntu 25.04

Differences Between Ubuntu 24.04.2 LTS and Ubuntu 25.04 Ubuntu 24.04.2 LTS is part of the Ubuntu 24.04 LTS series , and it will be the second point release in that LTS series. As an LTS release, Ubuntu 24.04.2 will receive long-term support for 5 years, ensuring stability, security updates, and backports of important features throughout its support lifecycle (up to 2034). Key Features of Ubuntu 24.04.2 LTS (Desktop & Server) : LTS Support : Full support for 5 years (until 2029) with extended support for 5 more years (until 2034). GNOME 44 : Modern, polished desktop environment with features like Wayland improvements, better multi-monitor support, and increased performance. Linux Kernel 6.x : Enhanced hardware support, including support for newer CPUs, GPUs, and other devices. Security Enhancements : Updates for AppArmor , SELinux , and automatic security updates to ensure the system remains secure over time. Cloud & Server Features : Improved support fo...
Read more

Kapardak Bhasma: A Comprehensive Review and use

Image
cowrie shells Kapardak Bhasma: A Comprehensive Review Introduction Kapardak Bhasma, also known as Kapardika Bhasma, is an Ayurvedic calcined preparation obtained from cowrie shells ( Cypraea moneta Linn. ). It is a well-documented mineral formulation used in Ayurvedic medicine for treating various ailments, particularly digestive disorders, respiratory conditions, and metabolic imbalances. Kapardak Bhasma is classified under Sudha Varga , a group of medicinal substances derived from marine sources. Sources and Identification Kapardak (cowrie shell) is a small, glossy, convoluted shell found in marine environments. It comes in various sizes and colors and has been traditionally used in Ayurveda for its medicinal properties. According to classical Ayurvedic texts, Kapardak is categorized into three varieties based on weight: Sardha Niska (4.5 gm) – Superior quality Niska (3 gm) – Medium quality Padona Niska (2.5 gm) – Inferior quality Preparation of Kapardak Bhasma The preparation of Ka...
Read more

Vanga Bhasma: A Traditional Ayurvedic Metallic Formulation and use

Image
Raw Tin Vanga Bhasma: A Traditional Ayurvedic Metallic Formulation Introduction Vanga Bhasma is a well-known Ayurvedic preparation made from tin (Vanga). It has been extensively used in traditional medicine for treating various ailments, including diabetes, respiratory issues, genitourinary disorders, and digestive problems. The preparation of Vanga Bhasma follows rigorous purification and incineration methods to ensure safety and efficacy. Preparation of Vanga Bhasma The preparation of Vanga Bhasma involves the following key steps: Shodhana (Purification) : Raw tin is purified using herbal extracts such as lemon juice or other acidic mediums. The process removes impurities and enhances the bioavailability of the metal. Marana (Incineration Process) : The purified tin is triturated with herbal ingredients and subjected to controlled heating cycles (Puta system). This process converts tin into a fine, bio-absorbable ash. Analytical Standardization : Modern techniques such as X-ray dif...
Read more