DNS Security and HTTPS

# CHAPTER 10

DNS Security and HTTPS #

1. Introduction #

The internet relies on immense trust. When you type bank.com into your browser, you trust that the network is routing you to your actual bank, and not to a hacker's identical-looking server in another country. Furthermore, when you type your password into that website, you trust that the network isn't letting anyone read it along the way. In this chapter, we will explore how the Domain Name System (DNS) can be manipulated, and how HTTPS and TLS Certificates establish a cryptographic chain of trust to guarantee privacy and authenticity on the web.

2. Learning Objectives #

By the end of this chapter, you will be able to:

• Understand the function of DNS as the "Phonebook of the Internet."

• Define DNS Spoofing (Cache Poisoning) and its impact.

• Explain the difference between HTTP (Port 80) and HTTPS (Port 443).

• Understand the role of SSL/TLS in encrypting data in transit.

• Explain the function of Digital Certificates and Certificate Authorities (CAs).

3. Beginner-Friendly Explanation #

Imagine using a phonebook to call your bank.

• DNS (The Phonebook): You look up "Bank of America" in the phonebook, and it gives you the phone number.

• DNS Spoofing (The Hack): A criminal sneaks into your house and glues a fake page into your phonebook. Now, when you look up "Bank of America," it gives you the criminal's phone number. You call, the criminal answers "Hello, Bank of America," and you willingly give them your account numbers.

• HTTPS & Certificates (The Defense): Before you give your account number, you demand the person on the phone provide a mathematically unforgeable, government-issued ID (A Digital Certificate) proving they are actually Bank of America. Furthermore, you conduct the entire phone call in an unbreakable secret language (TLS Encryption) so nobody listening on the line can understand you.

4. The Threat of DNS Spoofing #

Computers do not understand google.com; they only understand IP addresses like 142.250.190.46. When you type a URL, your computer asks a DNS Server, "What is the IP for this domain?" If an attacker compromises the DNS server (or executes a Man-in-the-Middle attack on your local Wi-Fi), they can perform DNS Spoofing. They tell your computer, "The IP for bank.com is [Hacker_IP]." Your browser unknowingly connects to the hacker's fake, identical-looking website, and you hand over your credentials.

5. HTTPS and SSL/TLS #

Historically, all web traffic used HTTP. This meant everything—passwords, emails, credit cards—was sent in plain text. Anyone on the network (like the person next to you at Starbucks) could use Wireshark to read it. HTTPS (HTTP Secure) wraps standard HTTP traffic inside a cryptographic tunnel called TLS (Transport Layer Security). TLS provides two massive security guarantees:

1. 1. Encryption: The data is scrambled into gibberish in transit.

1. 2. Authentication: It guarantees you are talking to the real server, defeating DNS Spoofing.

6. Certificates and the Chain of Trust #

How does TLS prove the server is the real bank.com? Using Digital Certificates. When you connect via HTTPS, the server sends your browser a Certificate. This certificate is essentially a digital ID card that says: *"I am bank.com, and my identity has been verified by a trusted Certificate Authority (CA) like DigiCert or Let's Encrypt."* Your browser has a pre-installed list of trusted CAs. If the server's certificate is signed by a trusted CA, the browser shows a secure padlock. If a hacker tries to spoof bank.com, they won't have a valid certificate signed by a CA, and your browser will display a massive red warning: "Your connection is not private."

7. Mini Project: Configure HTTPS Concepts #

Implementing HTTPS is no longer optional; it is mandatory for all websites.

The Workflow for a Web Administrator:

1. 1. Purchase/Generate a Certificate: The admin uses a service like Let's Encrypt to generate a free TLS certificate for their domain (example.com). Let's Encrypt verifies that the admin actually owns the domain before issuing it.

1. 2. Install on Web Server: The admin installs the certificate and private keys on their Nginx or Apache server.

1. 3. Configure the Firewall: The admin opens Port 443 (HTTPS) on the perimeter firewall.

1. 4. Force Redirection: The admin configures the web server to take any traffic arriving on Port 80 (HTTP) and automatically redirect it to Port 443 (HTTPS).

8. Real-World Scenarios #

In 2018, hackers executed a massive DNS hijacking campaign against MyEtherWallet, a popular cryptocurrency site. The attackers compromised the BGP routing of an internet service provider, intercepting the DNS requests for myetherwallet.com and redirecting users to a malicious server in Russia. However, the hackers did not possess a valid TLS Certificate for the domain. Users who ignored the browser's red "Invalid Certificate" warning and proceeded anyway had their cryptocurrency stolen. The TLS certificate system worked perfectly; the failure was human error in ignoring the security warning.

9. Best Practices #

• HSTS (HTTP Strict Transport Security): Even if a website supports HTTPS, a user might accidentally type http://www.bank.com. A hacker could intercept this initial unencrypted request before it redirects. HSTS is a web server header that tells the browser: "For the next year, *never* allow an unencrypted connection to this site, even if the user types HTTP." This definitively stops SSL Stripping attacks.

10. Legal and Ethical Notes #

Creating fake websites (clones) and manipulating local DNS records (like a local hosts file) to redirect traffic is a common technique in penetration testing to demonstrate the impact of Social Engineering and Man-in-the-Middle attacks. However, this must only be done against authorized targets within a defined Scope of Work.

11. Exercises #

1. 1. Explain the mechanical difference between HTTP and HTTPS. Which ports do they traditionally operate on?

1. 2. What is the role of a Certificate Authority (CA) in establishing trust on the internet?

12. FAQs #

Q: If a website has a green padlock (HTTPS), does that mean the website is safe and not a scam? A: No! This is a dangerous misconception. The padlock only means your connection to the server is *encrypted*. It does not mean the company running the server is honest. A hacker can easily set up a scam website (fake-bank-login.com) and get a valid HTTPS certificate for it. The padlock guarantees privacy, not morality.

13. Interview Questions #

• Q: Describe the process of a TLS Handshake. How do the client and server agree upon the symmetric encryption keys used for the session?

• Q: A user receives a "Certificate Authority Invalid" or "Self-Signed Certificate" error when navigating to an internal corporate application. Explain what this error means from a cryptographic standpoint and how the IT department should resolve it securely.

14. Summary #

In Chapter 10, we secured the routing and transmission of data. We explored the vulnerabilities of the Domain Name System, specifically DNS Spoofing, which redirects users to malicious infrastructure. We countered this threat by implementing HTTPS and TLS, establishing a rigorous, cryptographically backed Chain of Trust via Certificate Authorities. We concluded that enforcing encryption in transit and validating digital certificates are non-negotiable requirements for modern network security.

15. Next Chapter Recommendation #

We have secured the network perimeter and encrypted the data in transit. But eventually, a user must log in to access the data. Proceed to Chapter 11: Authentication and Access Control.