Have you tried accessing a website that uses HTTPS without typing the https:// prefix? If you enter acc.digital  or flipkart.com in your browser, it will first assume the default http:// prefix. Next, your browser will be automatically redirected to the website with the https:// prefix. This is very convenient, but it is potentially a vulnerability. Thus, it is important to understand the exact sequence of steps involved.
In Figure 1, User A types http://ecomm.site (or just ecomm.site) which uses HTTP to communicate with the website (message 1). To ensure security, the website redirects the browser (HTTP status code 302) to use HTTPS (message 2). The browser re-establishes communication with the website using HTTPS (message 3), which establishes a secure session (message 4) for secure two-way information exchange (message 5).
Since the first request is over HTTP, it is possible to launch a MITM attack where the two parties (in this case User A and the website) believe that they are directly and securely communicating with each other whereas in fact a third party is monitoring and/or modifying the data being exchanged between them. One such attack is shown in Figure 2.
The attacker (User X) first becomes the “man in the middle” by using Address Resolution Protocol (ARP) spoofing  to alter User A’s ARP table to map the next hop router’s IP address to User X’s MAC address, and to similarly alter the router’s ARP table to map User A’s IP address to User X’s MAC address. (To do so, User X can use a tool such as dsniff.) Now, whenever User A sends a packet to the router or the router sends a packet to User A, the destination MAC address filled at the link layer corresponds to User X. Hence, unknown to User A and the router, these packets are delivered to User X.
To maintain the appearance of a normal connection, User X can forward these packets to the intended target, but it can do so selectively and can record all communications (e.g., using tcpdump). An exercise to carry out ARP spoofing and capturing such data in a controlled environment is described in Exercise 6.
Let us now examine the attack shown in Figure 2. As with our previous scenario, we assume that User A types http://ecomm.site (or just ecomm.site). User X intercepts this request (message 1) and forwards it to the website (message 2) but, crucially, does not forward the redirect request (message 3) to User A. Instead, User X initiates an HTTPS communication with http://ecomm.site directly (message 4). Note that the website has no idea whether User A initiated this HTTPS request – it simply sets up the HTTPS session (message 5).
At this point, User X uses a tool such as sslstrip  to manipulate the website response by rewriting all references to HTTPS links with HTTP and sends this modified webpage to User A (message 6). Since the webpage has a very similar look and feel to the original webpage, User A is unlikely to notice that this connection is HTTP (e.g., by noting the absence of the lock icon for HTTPS near the URL bar in the browser). Believing that the connection is secure, User A now enters sensitive information (message 6a), which User X can view (since it is unencrypted) and record. User X can also forward this information securely to the website (message 6b) and continue to eavesdrop on the ostensibly secure session that follows.
Let us consider some of the ways in which the MITM attack described above could have been prevented.
- i. User A could have explicitly entered the https:// prefix or configured his/her browser to forcibly use HTTPS for selected websites  . However, many web users are unaware of these issues and the steps needed to prevent them, and it is not practical to educate all Internet users. Other web users (including the authors of this article) find themselves skipping this important step, despite being fully aware that the simplest way to avoid eavesdropping or MITM attacks is to use HTTPS and not HTTP when accessing websites that require users to input sensitive information.
- ii. Before entering sensitive information, User A could have ensured the presence of the lock icon. Once again, this assumes that users are sensitized to such issues.
- iii. The browser could warn users before submitting sensitive information over HTTP. This is feasible for passwords, because web pages typically use the HTML tag <input type=”password” …> for such user inputs. Modern browsers can warn users if they try to submit such data over HTTP  . However, a page can request several other kinds of sensitive information (credit card numbers, identification numbers such as Aadhaar or passport numbers, etc.), and browsers cannot recognize all such instances.
- iv. User A (or the IT staff in charge of User A’s network) could regularly monitor the network to ensure that ARP spoofing does not occur. This assumes adequate technical knowledge andresources (including time) on the part of User A or the IT staff, which is usually lacking in many contexts (e.g., small/medium-sized businesses).
- v. The website could entirely disable serving HTTP requests and force users to use HTTPS. It is very unlikely that businesses would adopt such an approach because it risks losing clients. For instance, User A
in Figure 1 would be unable to access the website and may thus abandon this business. Further, when the web server handles all URLs using HTTPS, performance can become an issue (especially when all the encryption is carried out in software).
- vi. The website could attempt to thwart MITM attacks, for instance by injecting web pages with encoded content to verify that HTTPS is indeed being used. (If not, the website could block the interaction and attempt to warn the registered user of the possible attack.) However, this complicates website development and requires suitably sensitized and experienced developers. Further, if User X is sufficiently determined, he/she can detect and remove the HTTPS checks before presenting the modified page to
Thus, no approach is entirely satisfactory.
To render a typical web page, several embedded objects need to be fetched  . Web developers sometimes hard-code these URLs into web content using HTTP instead of HTTPS (e.g., content fetched from other domains that do not support HTTPS). Further, websites often generate dynamic content via database lookups, executing external programs, etc. This dynamic content may also hard-code HTTP links. Converting such hard-coded links to HTTPS may require changes to external code, which is often infeasible.
When HTTPS is used to access such a web page, we say that it has mixed content   . As we shall see, since the entire communication does not use HTTPS alone, such a page is vulnerable to tampering  . Modern browsers indicate whether HTTPS content is mixed (i.e., potentially unsecure) or pure via an icon near the address bar. Table 1 shows these icons for Firefox  .
To view the difference between pure and mixed content in your browser, access the following links:
The HTML code for these pages are in Table 2 and Table 3 respectively. The key difference is that the code in Table 3 hardcodes the prefix http:// for Image 02. The prefix for Image 01, in contrast, is inherited from the protocol prefix used to access the web page. If these pages are accessed with the http:// prefix, the browser will show no difference other than in the page title. However, if these pages are accessed with the https:// prefix in Firefox, the page with pure content will show a green icon (see Figure 3) whereas the page with mixed content will show a gray lock with a warning symbol (see Figure 4).
Images in webpages are considered passive elements. When a webpage has active elements (e.g., scripts that generate content upon execution) that are invoked insecurely, the browser displays a different icon. For instance, when https://rprustagi.com/accs/mixed-active.html is accessed in Firefox, the lock icon with a crossed gray image and a red line is displayed, as shown in Figure 5.
The active content associated with the button labeled “Insecure access” is fetched via HTTP. Users can choose whether to allow or block such active content. In the above example, the button would work fine when protection is disabled (the browser would show the gray lock icon with the red line), but it would be blocked when protection is enabled (the browser would show the green lock icon). In the former case, an attacker can hijack the HTTP access and replace the script with code that performs malicious actions. Thus, it is safer to block this content, and instructions to do so are available  .
It is thus clear that web developers must ensure that embedded elements inherit the protocol scheme or use HTTPS as the default. The reader is encouraged to carry out to develop a better understanding of Mixed Content.