In this article, we have explained key issues involved in ensuring secure communications between a user and a website. These are supplemented with several small exercises to augment the reader’s understanding.
Our articles thus far have discussed the fundamentals of HTTP and web communication. We have developed a few simple experimental exercises to better understand HTTP and HTTPS. In the next series of articles, we will explore the working of transport layer protocols, specifically Transport Control Protocol (TCP) and UDP (User Datagram Protocol). Using a similar approach, we will explore the working of these protocols by conducting simple experimental exercises to help consolidate understanding.
All the example webpages as described in these exercises can be downloaded from  .
a. Find out the IP address of google.com (e.g. using
ping –c 1 google.com) and access that IP address using HTTPS in your preferred browser i.e. enter https://a.b.c.d in the browser when a.b.c.d is Google’s IP address. Do you see the Google search page or a warning? Explore why this happens. Repeat this exercise for any other website and understand the way SSL certificates work.
b. For the above IP address (e.g. a.b.c.d), make an entry in your local /etc/hosts file with some domain name (e.g. mydomain.com), as shown in Table 7. Access this new domain name using HTTPS, i.e. https://mydomain.com. Explain why you still get the warning page.
c. Generate a self-signed certificate (see Appendix) for your domain (e.g. mywebsite.com) and deploy this certificate on the webserver. Make a corresponding entry in the client machine and access the website using HTTPS. Explain the reason(s) for the difference from the warnings you observed in first two steps above.
d. Import the certificate file into your browser repository (steps in Table 6) and repeat the step above. You should see the website content without the warning page.
a. Create web page with secure references to other objects (similar to pure.html in Table 2) which accesses embedded objects without specifying the protocol in the URL. The objects should only be referred with just the path name.
b. Create a web page with insecure references to other objects (similar to mixed.html in Table 3). The objects should be explicitly referred via HTTP protocol.
d. Deploy these web pages on your web server.
e. Access these web pages in the (Firefox) browser with HTTPS and analyze the lock icon behavior.
a. Create a web page based on the code shown in Table 4, and set
Secure attribute for some cookies and don’t set this attribute for other cookies.
b. Access this web page in the browser. After the web page is accessed with HTTPS, open the browser preferences (or settings) and look for the values of these cookies. For Firefox, this can be done via
Preferences->Privacy & Security->History->Show Cookies. Search for the website and analyze all the attributes. For cookies set with Secure attribute,it should show the value
Encrypted connections only under the field
c. Access the same web page with HTTP and do a
wireshark/tcpdump capture, and analyze the cookies. For HTTP, you should see only those cookies being transmitted for which
Secure attribute is not set explicitly.
a. Enable Apache web server to send additional headers. Run the command
sudo a2enmod headers.
b. Configure its configuration file, e.g. ssl default. conf and add the entry
“Header always set Strict-Transport-Security "maxage=86400; includeSubDomains" under
c.Access this website (e.g. mywww.com) using HTTPS and verify the presence of HSTS header. For example, on client machine, run
wget –d – no-check-certificate https://mywww.com. This will dump both the request and response headers and HSTS should be present in response headers.
d. Verify the same in the browser by accessing a website that support HSTS e.g. amazon.in. Close the browser and open the browser again. Explicitly enter the URL with
HTTP protocol e.g. http://amazon.in
and do a wireshark/tcpdump capture on port 80 and 443 for this website. You should not see any capture on port 80.
e. Repeat the above step for a website that does not support HSTS at all or weakly supports it, e.g.
airtel.in. With wireshark/tcpdump, you should see the data capture on port 80.
This exercise demonstrates use of Content Security Policy. Please note with every change of server configuration files, the server needs to be restarted.
a. Configure the web server with CSP policy as disabling all external links e.g.
Header set Content-Security-Policy “default-src ‘none’;
b. Design a webpage containing some images and scripts with embedded link. Access this web page, and neither image should show up nor script should run.
c. Change the CSP polity to allow all from parent web page i.e. set the CSP policy as
Header set Content-Security-Policy “default-src ‘self;
d. Access this web page, and both images should be shown as well script should run.
This exercise simply demonstrates a simple MITM attack using netcat (
Warning: Please note this exercise must NOT be done on any public/institutional/organizational network as it would imply stealing of information, and you may have to face consequences for stealing such information. The authors of this article strongly recommend that you carry out this exercise in a controlled setup (e.g., in your home), and only to develop a better understanding to help you protect your data.
a. Connect 3 machines in a simple LAN network e.g. as shown in figure below.
b. Here let A and C be the normal users and B acts as an MITM attacker. Please note down the IP Addresses of A and C as per your network. For the steps below, we will use the IP Addresses as shown in diagram. Please change these values as per your network setup. This further assumes that B is running Ubuntu Linux. A and C can run any OS (e.g. Windows, Mac etc.).
c. Convert B into a router by executing
sudo sysctl -w net.ipv4.ip_forward=1.
d. Install ARP spoofing software (package dsniff) on B
sudo apt install dsniff
e. Issue ARP spoof command on B for A and C. This assumes Ethernet network interface on B is eth0.
Replace it with the network interface name on your machine B.
sudo arpspoof -i eth0 -t 175.25.4.x -r 175.25.4.z sudo arpspoof -i eth0 -t 175.25.4.z -r 175.25.4.x
f. Run the wire shark on B and capture the traffic between A and C, Use the capture filter as
host 175.24.5.x and host 174.24.5.z
g. Run netcat (nc) chat between A and C. The wireshark capture on B should show this chat contents between A and C.
To capture the web traffic as discussed in the article, you need to install
sslstrip tool and configure it as per your setup in addition to running ARP spoofing on B.