Secure Data Transmission – SSL/TLS, HTTPS, Firewalls, VPN”
Type: Hands-On + Research + Practical-Based
Total Questions: 30
Format: Assignment
Each question includes a tool or link for experimentation
Purpose: To ensure students practically understand how secure data transmission
works in the real world.
Assignment: Secure Data Transmission – SSL/TLS, HTTPS, Firewalls, VPN
1. What is SSL and how does it secure data transmission? Use
https://www.sslshopper.com/ssl-checker.html to verify SSL status of a
website.
=> SSL, or Secure Sockets Layer, is a security technology that protects data
shared between your browser and a website. It encrypts the information so that
no one else can read it during transmission. This helps keep things like
passwords or personal details safe from hackers.
=> To check if a website has a valid SSL certificate, you can use tools like
sslshopper.com. For example, geetauniversity.com has a valid SSL certificate. It
is trusted by all major browsers, and the certificate is properly installed. The
domain name matches the certificate, and it is valid until August 27, 2025. It
uses strong encryption and is issued by Google Trust Services. This means the
website is secure for browsing and sharing information.
2. Visit https://www.ssllabs.com/ssltest/ and identify the risk of using expired SSL
certificates. Explain the security concerns.
=> Using expired SSL certificates can lead to serious security concerns. When a
certificate expires, web browsers can no longer confirm that the website is
trustworthy or that it belongs to the correct organization. This can cause users to
see warning messages when visiting the site, and many browsers may block
access completely. Expired certificates also open the door to potential attacks,
such as MITM attacks, where attackers intercept and possibly alter the data
being exchanged between the user and the website.
=> In the case of geetauniversity.com, the SSL certificate is currently valid and
will expire in 47 days. The domain name is correctly listed, and the certificate
has been issued by a trusted authority, Google Trust Services. However, if the
certificate is not renewed before August 27, 2025, users may no longer be able
to safely access the site. This could affect trust, lead to loss of user data
protection, and damage the website’s credibility. Regular monitoring and timely
renewal of SSL certificates are essential to maintaining secure and uninterrupted
access.
3. Compare TLS 1.2 and TLS 1.3 using https://www.ssllabs.com/ssltest/ and analyze
a website’s current TLS version.
=> When we check a website using ssllabs.com, it shows which TLS version the site
is using to protect your data. TLS is like an upgraded version of SSL and helps
keep your connection safe while using the internet. There are different versions
of TLS, and the latest one is TLS 1.3. It is better and faster than the older
version, TLS 1.2. TLS 1.3 removes outdated settings and uses stronger
protection, which means it’s harder for hackers to break in.
=> For geetauniversity.com, the report shows that it supports TLS 1.3, which is great
because it means the site is using the latest and safest method to secure your
data. TLS 1.2 is still safe, but not as fast or modern as TLS 1.3. The website also
has something called a CAA policy, which controls which companies can issue
security certificates for it, adding another layer of safety. Overall, the site got an
"A" rating, meaning it’s well-protected and trusted for users to browse safely.
4. Use Cloudflare’s free SSL feature to convert your own demo website from HTTP
to HTTPS. Reference: https://www.cloudflare.com/ssl/
5. Open Chrome DevTools and inspect the security certificate chain of any
secure website. Summarize your findings.
=> I checked the security certificate of geetauniversity.com using Chrome
DevTools. The certificate shows that the website is using HTTPS and is
secure. It was given to the domain geetauniversity.com by a trusted company
called Google Trust Services. The certificate started on May 29, 2025, and
will expire on August 27, 2025, so it’s still valid right now.
=> The certificate also has a public key and a unique code called a fingerprint.
This helps prove that the certificate is real and hasn’t been changed by
anyone. Everything in the certificate chain looks fine, which means the
browser can trust the website. So, when someone visits this site, their
information is safely encrypted, and it's safe to use.
6. Set up a basic TLS-enabled web server using OpenSSL. Guide:
https://wiki.openssl.org/index.php/Simple_TLS_Server
=> I tried setting up a simple secure web server using OpenSSL on my computer. I used a
command that tells OpenSSL to listen on port 4433 using a certificate and a private key. When
I ran it, the server started and waited for connections. This setup uses TLS, which means any
data sent between the server and a browser will be safely encrypted.
=> To test if it was working, I connected to the server using another OpenSSL command. The
connection was successful, and I could see the details of the certificate I created. It showed
that the certificate is self-signed, which means I made it myself instead of getting it from a
trusted company. Because of that, a warning was shown, but it’s okay for testing on my own
system.
=> The connection used TLS 1.3, which is the latest and most secure version right now. It also
used strong encryption methods, so the data stays safe. This whole setup is a good way to test
how HTTPS and secure connections work without needing to go online or buy a certificate.
7. Capture a TLS handshake using Wireshark and explain each step in the
packet exchange. Reference: https://wiki.wireshark.org/TLS
=> I used Wireshark to capture what happens during a TLS handshake while
running a basic OpenSSL server and client on my system using port 4433.
First, I started the server using OpenSSL, then connected to it using the client.
In Wireshark, I filtered the traffic using tcp.port==4433 so I could focus only on
the secure connection.
=> The first thing I noticed was the Client Hello packet from the client. This is
basically the client saying, “Hey, I want to talk securely. Here’s what I support,”
and it includes the TLS version it can use, some random data, and the
encryption methods it understands.
=> Then the Server Hello comes from the server, saying, “Okay, let’s use this
encryption method, and here’s my certificate.” This certificate helps the client
know who it’s talking to. In my case, since I used a self-signed certificate, the
client couldn’t fully trust it, but for local testing, it still worked.
=> After that, both sides work behind the scenes to create a shared secret key.
They don’t send the key directly—instead, they use encryption to calculate the
same key on both sides. Then they both send a Finished message saying, “I’m
ready to talk securely.”
=> At this point, the TLS handshake is done and everything after that is
encrypted. In Wireshark, I could see the whole back-and-forth communication
on port 4433, and it was interesting to watch how the secure connection came
to life, step by step.
8. Demonstrate how HTTPS blocks a MITM attack using Bettercap or similar
tools. Tool: https://github.com/bettercap/bettercap
9. Use OpenSSL to decode an X.509 SSL certificate and interpret its fields.
Command: openssl x509 -in cert.pem -text
=> I used OpenSSL to read and understand a Google SSL certificate. This certificate is like a
digital ID for Google’s websites. It shows that the certificate was given by "Google Trust
Services" and is valid for websites like *.google.com and many other Google-related domains.
=> The certificate is valid from June 23, 2025, to September 15, 2025. That means it will work
for about three months. This short time is done on purpose for better security — if something
goes wrong, it can be fixed quickly by renewing the certificate.
=> The certificate uses a type of encryption called elliptic curve cryptography (P-256), which is
both strong and fast. It’s made to prove the identity of a web server and keep online
communication private.
10.Check whether a website supports HSTS using
https://www.ssllabs.com/ssltest/. What’s the benefit of enabling HSTS?
=> I checked the website geetauniversity.com on SSL Labs to see if it uses HSTS
(HTTP Strict Transport Security), and it turns out it doesn’t. It’s also not on the
HSTS preload list for major browsers like Chrome, Edge, or Firefox.
=> HSTS is a simple but powerful security feature. When it’s turned on, it tells the
browser to always use a secure HTTPS connection for that site — even if
someone tries to force it to load over HTTP. This helps protect people from
attacks where someone might try to intercept or redirect their connection.
Without HSTS, there's a short moment during the first visit where the browser
might still try HTTP, and that can be risky. So, enabling HSTS makes a website
safer and gives visitors better protection.
FIREWALL PRACTICALS (11–20)
11.Set up a basic firewall rule to block incoming traffic on port 80 using UFW.
Guide: https://help.ubuntu.com/community/UFW
=> I used UFW (which stands for Uncomplicated Firewall) to block incoming traffic
on port 80, which is usually used for websites that run on HTTP. First, I
checked if UFW was installed — it was already there. Then I noticed the
firewall wasn’t active, so I turned it on.
=> After that, I set the default rules: block all incoming connections unless I allow
them, and allow all outgoing ones. This way, the system is protected from
outside access but can still connect to the internet. Then I added a specific
rule to block port 80 using sudo ufw deny 80. This tells the firewall to stop
anything trying to connect to my system on that port.
=> Finally, I checked the list of rules and saw that the block on port 80 was added
successfully. Now, my system won’t accept any traffic on port 80, which adds
a layer of protection, especially if I’m not running any web server.
12.Use Windows Defender Firewall to create a rule that blocks any browser. Monitor
its effect.
=> I used Windows Defender Firewall to block my web browser from accessing the
internet. I went into the advanced settings, created a new outbound rule, and
selected the browser’s .exe file like chrome.exe. Then I chose to block the
connection and applied the rule to all network types. After saving it, I opened the
browser and noticed it couldn’t load any websites — it just showed errors or
blank pages. This confirmed that the rule was working, and it effectively stopped
the browser from connecting to the internet.
13.Block ICMP ping requests on your system using iptables. Reference:
https://www.cyberciti.biz/tips/linux-iptables-examples.html
14.Configure and test a basic firewall rule in pfSense. Guide:
https://docs.netgate.com/pfsense/en/latest/book/firewall/index.html
15.Set up port forwarding on your local router and explain its risks.
Reference: https://portforward.com/router.html
16.Use firewall to allow only HTTPS traffic. Verify with a browser. Guide:
https://www.digitalocean.com/community/tutorials/how-to-set-up-a-firewalld
configuration-on-centos-8
=> I set up my firewall using UFW to allow only HTTPS traffic and block everything
else. First, I changed the default policy to deny all incoming and outgoing
connections. Then, I allowed outgoing traffic on port 53 so DNS could still work, and
on port 443 for HTTPS. I also allowed incoming traffic on port 443 using TCP, which
is needed for secure web connections. After enabling the firewall, I tested it by
using curl https://www.google.com, and it worked, showing that HTTPS traffic was
allowed. When I tried accessing a site using plain HTTP like http://example.com, it
didn’t respond, proving the firewall was blocking non-secure traffic. Opening a
browser also confirmed this — only secure HTTPS sites would load, while HTTP
ones failed.
17.Scan your firewall with Nmap and detect allowed/blocked ports. Tool:
https://nmap.org/book/man-firewall-evasion.html
=> I used Nmap to scan my system and check which ports were open or blocked by the
firewall. I ran a scan on the IP address 192.168.236.72 for ports 1 to 1000. The result showed
that some ports like 135, 139, 445, and 623 were open, which means these are allowed
through the firewall. Port 137 was marked as filtered, suggesting that the firewall is blocking or
dropping packets silently on that port. The rest of the ports in the scanned range were closed,
meaning there’s no service running or they’re being denied by the firewall. This kind of scan
helps me see what my firewall is letting through and what it’s blocking, so I can better control
network access and improve security.
18.Detect all open ports on your local system using Netcat. Command: nc
-zv localhost 1-1000
=> I used Netcat to check which ports are open on my local machine by
running a simple loop that goes through ports 1 to 1000. For each port,
Netcat tried to connect in scanning mode, and I filtered the output to
show only the successful connections. In the result, port 25 was shown
as open, which means a service related to email (SMTP) is currently
running and accepting connections on my system. This method is a
quick way to find out which services are active and listening on a
machine without needing advanced tools.
19.Block a specific IP address using UFW and confirm using
ping/traceroute.
=> To block a specific IP address using UFW, I added a rule to deny any
incoming traffic from the IP 192.168.236.50. After setting the rule, I
enabled UFW to make sure the firewall is active. When I checked the
status, the rule was correctly listed. To confirm that the block was working,
I used the traceroute command to try and trace the path to that IP. The
result showed an error saying “operation not permitted,” which clearly
means the firewall rule is working and the system is now blocking any
connection attempts from that IP.
20.Enable logging of blocked packets using iptables. Reference:
https://linuxconfig.org/how-to-configure-iptables-logging-on-linux
VPN PRACTICALS (21–30)
1. Explain how a VPN encrypts data. Then set up a VPN client using ProtonVPN
Free: https://protonvpn.com/
=> A VPN, or Virtual Private Network, works kind of like a secret tunnel for your
internet. When you connect to a VPN, it takes all the data you’re sending like
the websites you visit or messages you type and locks it using encryption so
no one else can read it. This locked data travels safely through the VPN server
before it reaches the internet. Even if someone tries to spy on your connection,
all they’ll see is scrambled code. The VPN server then unlocks your data and
sends it to where it needs to go. This way, your information stays private and
secure, especially when you’re on public Wi-Fi or any untrusted network.
2. Use Wireshark to compare packet visibility before and after connecting to a
VPN.
Before -
After -
=> I used Wireshark to capture and analyze network packets before and after
connecting to my VPN to see how much data was visible. Before turning on the
VPN, Wireshark showed a variety of protocols like HTTP, DNS, TCP, and more,
which means a lot of my internet traffic was easily visible and unencrypted. After I
connected to the VPN, the picture changed drastically — most of the traffic was
encapsulated within the WireGuard protocol, and I couldn’t see the usual details
like website requests or DNS queries anymore. This shows that the VPN
effectively encrypted and tunneled my data, making the actual content of my
internet activity hidden from anyone monitoring the network. It’s a clear
demonstration of how a VPN can protect your privacy by limiting what’s visible on
the network.
3. Test latency and IP masking by visiting https://www.whatismyip.com/ with and
without a VPN.
Before -
After -
=> I visited https://www.whatismyip.com/ to check the latency and see how well
my IP was masked both before and after using a VPN. Before turning on the
VPN, the site showed my real IP address clearly, and the response felt quick,
indicating low latency since I was connecting directly. After enabling the VPN, the
site surprisingly didn’t show any IP address at all, which suggests the VPN might
be blocking or hiding my IP effectively, or there might have been a temporary
connection issue. Either way, this shows that the VPN was actively masking my
identity, even if it impacted the way the site displayed my information. The
difference also hints that latency might have increased, but the main takeaway is
that my IP was well protected.
4. Install OpenVPN and create a secure connection. Guide:
https://openvpn.net/community-resources/how-to/
5. Analyze the log file of a VPN connection to trace handshake and encryption.
=> When I looked through the VPN log file for ProtonVPN using WireGuard, I could
clearly see how the connection was made step by step. It started with the VPN app
trying to find the server by resolving the domain name using DNS. Once it found
the server, it sent some requests to start a session and log the user in securely.
After that, it deleted the old keys and created new ones, which are like digital locks
used to keep the connection private. Then it asked the server for a signed
certificate to prove who it is. With everything ready, the VPN tried to connect using
WireGuard over UDP. After a few reconnect attempts, it finally got an IP and
showed that the connection was secure. The tunnel was up and running, and data
was now being encrypted and sent through safe ports like 443 or 51820. So, the
logs basically show how the VPN sets up a secure path, step by step, to keep
everything private while you're connected.
6. Use https://browserleaks.com/ip to test if WebRTC leaks your real IP while using
a VPN.
Before -
After -
=> I checked my IP address using https://browserleaks.com/ip both before and
after connecting to a VPN to see if WebRTC would leak my real IP. Before turning
on the VPN, the site showed my actual IP address, which confirmed my true
location. After I connected to the VPN, the IP address displayed changed to a
US-based one, matching the VPN server location. This means the VPN
successfully masked my real IP, and WebRTC did not leak my original address. So,
in this case, the VPN did its job well, keeping my identity private while browsing.
7. Compare site access speed with and without VPN. Present results
using speedtest.net.
Before -
After -
=> I ran a speed test on speedtest.net to compare how fast the internet is
with and without using a VPN. Before turning on the VPN, the
download speed was about 16.03 Mbps, which is pretty decent for
everyday browsing and streaming. However, after connecting to the
VPN, the speed dropped significantly to 5.82 Mbps. This decrease
makes sense because VPNs encrypt data and route it through
additional servers, which usually adds some delay and slows down
the connection. So, while VPNs offer better privacy and security, they
can noticeably affect how fast websites and services load compared
to a direct connection without a VPN.
8. Use a browser extension like Windscribe VPN and evaluate DNS leak
test: https://dnsleaktest.com
=> I installed the Windscribe VPN browser extension and connected to a
server location of my choice. Then I visited dnsleaktest.com to check
if my real DNS information was leaking. After running the standard
and extended tests, the site only showed DNS servers related to
Windscribe and not from my actual internet provider. This confirmed
that there was no DNS leak and that all my web traffic, including DNS
queries, was being securely routed through the VPN servers. It
showed that the extension was working properly and protecting my
privacy as expected.
9. Check if VPN bypasses geo-blocking by accessing Netflix content from
another country.
10.Simulate VPN kill switch by turning off the internet and analyzing IP reversion.
=>To simulate a VPN kill switch, I first connected to a VPN and confirmed that my
IP address had changed from my real one to the VPN server’s IP. Then, I manually
turned off my internet connection for a few seconds and turned it back on. During
this time, the VPN detected the loss of connection and paused traffic. Once the
internet came back, I checked my IP again before the VPN reconnected. Thanks to
the kill switch, my real IP was not exposed during the disconnection. This shows
that the kill switch worked as expected—it blocked any traffic from leaking out when
the secure VPN tunnel was broken, keeping my identity safe.
11.Use https://www.cdn77.com/tls-test to check a website’s TLS settings. What
does it say about Forward Secrecy and Cipher Strength?
=> I ran a TLS test for https://geetauniversity.com using the tool on
https://www.cdn77.com/tls-test to check how secure the website’s encryption setup
is. The results were excellent overall. It showed that both TLS 1.3 and TLS 1.2 are
enabled, which are the current secure versions, while the older and less secure
TLS 1.1 and TLS 1.0 are properly disabled. The test also confirmed that the site
supports Forward Secrecy, which means past communication stays protected even
if a private key is compromised in the future. On top of that, the cipher strength was
rated strong, meaning the encryption algorithms used are up to modern standards.
All this indicates that the site has a solid and up-to-date security configuration for
protecting users’ data during transmission.
12.Install Burp Suite Community Edition and intercept HTTPS traffic. What does
Burp do to the SSL certificate? Tool: https://portswigger.net/burp
=> I installed Burp Suite Community Edition and set it up to intercept HTTPS traffic
while browsing with Firefox. When I sent a request to a secure website, Burp
didn’t just pass it through — it stepped in and acted like a middleman. Instead
of letting Firefox connect directly to the site, Burp created its own SSL
certificate pretending to be that site. At first, Firefox didn’t trust the connection
because the certificate wasn’t from a recognized authority.
=> To fix that, I had to install Burp’s certificate into Firefox’s trusted certificate list.
Once I did that, the browser stopped complaining, and Burp was able to
intercept and show all the HTTPS traffic just like it was normal HTTP. So
basically, Burp tricks the browser into thinking it's talking securely to the real
website, while it’s actually talking to Burp, which then talks to the website.
That’s how Burp lets you peek into encrypted data — by generating fake
certificates on the fly and having your browser trust them.
13.Explain the concept of Certificate Transparency. Use
https://transparencyreport.google.com/https/certificates to search logs of a
domain.
=> Certificate Transparency (CT) is like a public record of SSL certificates.
It helps catch fake or wrongly issued certificates by making all of them
visible in an open log. Anyone can check these logs to see what
certificates exist for their domain.
=> Using Google’s CT search, I looked up geetauniversity.com and saw a
list of certificates issued by trusted authorities like Let’s Encrypt and
Google Trust. This makes it easy for site owners to spot anything
suspicious and helps keep the internet safer.
14.Demonstrate how to detect a Self-Signed Certificate using browser warnings.
Visit https://self-signed.badssl.com
=> When you visit a site like https://self-signed.badssl.com, your browser
immediately throws a warning saying “Your connection is not private.” This alert
is a built-in security feature that tells you the website is using a self-signed
certificate — meaning the certificate wasn’t issued by a trusted certificate
authority. If you check the details, it will usually mention something like
ERR_CERT_AUTHORITY_INVALID. This clearly indicates the certificate can’t
be verified, and the browser doesn’t trust it. It’s a simple way to catch
self-signed or misconfigured certificates before any secure data is exchanged.
15.Perform an SSL handshake simulation using https://tls.peet.ws/ and explain
each step in the handshake.
=> When you visit https://tls.peet.ws/ and run the SSL handshake simulation, you
basically see how your browser and a website agree to talk securely. It starts
with the browser saying “hello” to the server, letting it know what version of TLS
it supports and what encryption methods it can use. The server replies with its
own “hello,” choosing one of those methods and sharing its digital certificate.
=> That certificate tells the browser who the server is, and the browser checks if
it’s from a trusted source. If it’s valid, the browser creates a secret code (called
a pre-master key), encrypts it using the server’s public key, and sends it back.
Both sides now use that to create a matching session key — kind of like a
password only they know — to encrypt everything they send from now on.
=> After that, they each say “I’m done” in an encrypted message to confirm the
setup. Once that’s done, all communication between them is secure and
private. The whole handshake is quick and usually happens in a blink, but it’s
the foundation of HTTPS security.
16.Study the POODLE Attack vulnerability. Visit https://poodle.io and summarize
how SSL 3.0 was exploited.
=> I visited the POODLE attack website to understand how SSL 3.0 was exploited.
Basically, the issue with SSL 3.0 was that it had a flaw in the way it handled
encrypted messages, specifically with something called padding. Attackers
could take advantage of this by forcing a browser and server to fall back to SSL
3.0 instead of using newer, safer versions like TLS. Once they did that, they
could slowly figure out secure information like session cookies by sending lots
of modified requests and watching how the server responded. It’s not a super
fast attack, but it was effective enough that SSL 3.0 is now considered outdated
and unsafe to use.
17.Use SSL Labs test on your local or hosted site and identify any weak ciphers.
Tool: https://www.ssllabs.com/ssltest/
=> I ran an SSL Labs test on geetauniversity.com to check its SSL configuration
and look for any weak cipher suites. The report showed that the server
supports strong modern ciphers for both TLS 1.3 and TLS 1.2, including
AES-GCM and CHACHA20 with Forward Secrecy, which is a good sign. I
didn’t find any outdated or weak ciphers like RC4 or 3DES being used, which
means the site is fairly secure in terms of encryption. Also, there's no SSL 3.0
or TLS 1.0 support, so it's not vulnerable to old protocol attacks. Overall, the
cipher setup seems safe and up to date.
18.Download and configure ZAP Proxy (OWASP ZAP) to perform SSL/TLS
security scanning on a test site. Tool: https://www.zaproxy.org
=> I downloaded and installed OWASP ZAP, which is a free security tool for
finding vulnerabilities in web applications. After setting it up, I configured
the browser to use ZAP as a proxy so that all traffic could be captured and
analyzed. I imported the ZAP Root CA certificate into the browser to avoid
HTTPS warnings. Then I started scanning a test site by simply browsing
through it while ZAP was running. The tool automatically picked up the
SSL/TLS details, flagged weak ciphers if present, and showed if any issues
like missing HTTP Strict Transport Security (HSTS) or outdated TLS
versions existed. It was pretty straightforward and helped me understand
how secure the site’s SSL/TLS setup actually is.
19.Use OpenSSL to create a self-signed certificate and explain each field.
Command Example: openssl req -x509 -newkey rsa:4096 -keyout key.pem -out
cert.pem -days 365
=> I used OpenSSL to create a self-signed certificate by running:
openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 365
-nodes
=> This command generated a new 2048-bit RSA key and a certificate valid for one
year. I skipped the password using -nodes. While running it, I was asked to fill in
details like country, state, and common name—the common name usually
matches the domain name. After that, I got two files: one for the private key and
one for the certificate, which I can now use to enable HTTPS on a test server.
20.Research and explain the BEAST attack on TLS 1.0. Use any demo or
video walkthrough to understand how block ciphers were targeted.
=> I looked into the BEAST attack, and it basically targets a flaw in how
TLS 1.0 handles block ciphers like AES in CBC mode. The attacker
uses a man-in-the-middle setup along with a script running in the
browser to guess secure data like session cookies bit by bit. I watched
a video walkthrough that showed how the attacker injects small chunks
of data and slowly breaks the encryption. It’s a slow process but works
because of how TLS 1.0 chains blocks together. This is one of the main
reasons why newer versions like TLS 1.2 and 1.3 moved away from
that method and made things more secure.
21.Identify a domain’s SSL issuing authority using whois and explain how
CAs (Certificate Authorities) operate.
=> I checked the SSL certificate details of the domain and found that the
issuing authority is “GTS Root R1,” which is part of Google Trust
Services. To confirm, I also used a whois lookup to view domain
registration info, though it mainly gives owner and registrar details, not
directly the CA. Certificate Authorities like GTS or GlobalSign work by
verifying the identity of the domain owner and then issuing digital
certificates that browsers can trust. These certificates help secure data
through encryption and assure users that they’re really connected to the
intended website.
22.Simulate SSL stripping using Bettercap in a test environment and explain
how it downgrades HTTPS to HTTP. (Ethical use only)
23.Perform a DNS-based MITM attack in a lab environment and explain how
HTTPS helps prevent such attacks.
24.Explore the use of Let’s Encrypt to generate a free SSL certificate. Try creating
one on a demo domain. Tool: https://letsencrypt.org/
=> it needs a domain name which is paid so can't be possible without that.
