What is MITM: Man in the middle?
A man-in-the-middle attack (MITM) is an attack where the attacker secretly relays and possibly alters the communication between two parties who believe they are directly communicating with each other.
A MITM attack requires three players: there's the victim, the entity with which the victim is trying to communicate, and the "man in the middle", who's intercepting the victim's communications. Critical to the scenario is that the victim isn't aware of the man in the middle.
Every HTTP request goes through multiple routers, server before it reaches its destination. These middle entities can simply read data you sent and especially the cookies, that may contain user identification information. So if these cookies are read by some man-in-middle, then anyone reading that cookie can fake as another user.
SSL Strip
In order to "strip" the SSL, an attacker intervenes in the redirection of the HTTP to the secure HTTPS protocol and intercepts a request from the user to the server. The attacker will then continue to establish an HTTPS connection between himself and the server, and an unsecured HTTP connection with the user, acting as a "bridge" between them.
If the victim wants to access a server by typing the URL in the address bar, the browser connects to the attacker machine and waits for a response from the server. In an SSL Strip, the attacker, in turn, forwards the victim's request to the real server and receives the secure HTTPS page. At this point, the attacker has complete control over the secure page. He downgrades it from HTTPS to HTTP and sends it back to the victim's browser. The browser is now redirected to the website over HTTP. From now onward, all the victim's data will be transferred in plain text format, and the attacker will be able to intercept it. Meanwhile, the website's server will think that it has successfully established the secure connection, which indeed it has, but with the attacker's machine, not the victim's.
SSL Strip attacks can be implemented in a number of ways. The most common method is by creating a Wi-Fi hotspot and allowing the victims to connect to it. Many attackers establish fake hotspots with names similar to legitimate hotspot names. Unaware, the user connects to the malicious hotspot. Once the user tries to connect to the server, the attacker uses his control over the hotspot and attacks the user.
DNS hijacking
The way in which domain names and their DNS records are managed is complex. Organizations called registries manage the DNS zones for specific TLDs, but the records in those zones come from domain registrars — the companies that have agreements with registries to sell domain names. The registrars themselves can have other resellers or can work with third-party companies that manage DNS operations for them.
Domain owners also have the power to change the nameservers for their domain names from their accounts on the registrar's website. And they too sometimes delegate DNS management to third-party companies. It's easy to see how this complex system might offer many potential entry points for hackers. And depending on which link in the chain gets compromised, attackers could get access to one or thousands of domains as a result of a single breach.
Breaches at the registry level are obviously the most serious ones because they can have a widespread impact. Registrars and their resellers have also been hit by hackers over the years. A single compromised domain account can also have serious consequences, especially if the domain names in that account belong to a large company or service provider.
Malefactors can create their own DNS server that returns another IP address (say, 6.6.6.6) in response to the request, and that address might host a malicious website. The success of the venture depends on having a method that makes a victim use a malicious DNS server, which will direct them to a fake website, instead of a legitimate one.
Protect against MITM attacks
The simple solution is to implement HTTPS especially when you are exchanging cookies that contain sensitive information like a session ID. With HTTPS, man-in-the-middle becomes very difficult if not impossible. Secure communication protocols, including TLS and HTTPS, help mitigate spoofing attacks by robustly encrypting and authenticating transmitted data. Doing so prevents the interception of site traffic and blocks the decryption of sensitive data, such as authentication tokens.
It is considered best practice for applications to use SSL/TLS to secure every page of their site and not just the pages that require users to log in. Doing so helps decreases the chance of an attacker stealing session cookies from a user browsing on an unsecured section of a website while logged in.
Another thing to be aware when using HTTPS is that many websites automatically redirect the user to HTTPS when they attempt to use HTTP. Now, if the user had already logged in previously and tried to use HTTP, there is a possibility that for that one request man-in-the-middle can happen.
The simple solution is to use Secure cookie flag, then cookies are exchanged if and only if you use an HTTPS connection.
HSTS: HTTP Strict Transport Security
Enabling HTTPS for all web apps and services hosted on a domain name should be a top priority. This will protect users from man-in-the-middle attacks in general and has many other benefits, like the ability to turn on HTTP/2 and gain a significant performance boost. However, to mitigate the effects of SSL Strip and DNS hijacking, HTTPS needs to be combined with a security mechanism called HSTS.
The HTTP Strict Transport Security (HSTS) is a security policy expressed through a server header that is honoured by all modern browsers. It was designed to prevent protocol downgrade attacks and cookie hijacking and can be used to instruct browsers to always access a website over encrypted connections (HTTPS).
Without it, an attacker who hijacks the DNS records of an HTTPS-enabled website can still pull off a phishing attack by directing visitors to a fake version of that site that doesn't use HTTPS. The success of this attack would then depend on whether visitors will notice the absence of the green SSL/TLS padlock in their browser's address bar, something that users don't check very often.
With an active HSTS policy on top of HTTPS, browsers will simply refuse to load the website if served over an unencrypted connection. To bypass this defence the attacker would have to obtain a valid certificate for the domain name from a certificate authority and install it on his rogue server. While this is not impossible — there have been cases of CAs being hacked or tricked to issue fraudulent certificates — it requires a lot of effort on the attacker's part and their chance of success is pretty low.
A website's HSTS policy is recorded by the browser when the user visits the website for the first time, so there's technically an opportunity for a man-in-the-middle attacker to prevent the HSTS policy from being received by the client during this first visit. To close this attack window, modern browsers come with a preloaded list of websites for which HSTS is always enforced and webmasters can submit their websites for inclusion on this list.
Max-Age
Specifying a max-age allows web browsers to cache the fact that a site uses HSTS. This means even if you try to visit the HTTP version, the browser will automatically convert that to HTTPS for you before it even sends the message to the web server. This is a great security feature, and means if you ever connect to a network that attempts to listen in, or reroute your traffic, it is not able to keep you on HTTP as you were never on it. This makes attacks significantly harder. However, this means if you ever have a need for an HTTP call, then this will potentially not work for some visitors who have cached the policy until the max-age expires.
So you had better be pretty sure that your website is indeed all HTTPS before you turn this on!
includeSubdomain
The includeSubDomains option is there to add additional protection. It's sometimes possible for subdomains to get or set cookies for the other domain, which can present a security risk, particularly when accessed over HTTP. By setting the includeSubDomains, you reduce that risk. However, that means every subdomain better be HTTPS. If you have a sub-site that you never got round to securing (e.g. http://mail.larapulse.com), then you've just forced yourself to upgrade with this policy. Sound far-fetched? There are examples of includeSubDomains causing issues already. Similarly companies that use the external website domain name, as their internal domain as well for internal servers, can easily DoS any internal HTTP only web-servers (e.g. intranet.larapulse.com) by including this policy on their external website top-level domain (which is easy to do inadvertently with most web servers by only having one vhost without realising the impact of this).
Be aware of forcing HTTPS on every domain, as some of them could be used by third-party providers, like Gmail services, which will not work on such subdomains.
preload
And the most dangerous item, because you have the least control over it: preloading HSTS right into the browser. You can submit your website to a list of sites that the browser knows uses HSTS. This means the policy is preloaded, which helps protect the first visit to the site, which would not normally be protected until each visitor had successfully connected to the site and downloaded the policy for the first time. The problem with this (along with the fact that it demands includeSubDomains and a long expiry) is that there is no real way to undo this. From Chrome preload site:
Be aware that inclusion in the preload list cannot easily be undone. Domains can be removed, but it takes months for a change to reach users with a Chrome update and we cannot make guarantees about other browsers. Don't request inclusion unless you're sure that you can support HTTPS for your entire site and all its subdomains in the long term.
That's a serious commitment right there. Chrome maintains a list of removal requests and it's obvious a number of sites are making mistakes with this feature. Given that Chrome takes about 12 weeks from initial build, until it's put to the public that's basically a minimum of 3 months to remove this setting from Chrome (assuming everyone auto updates). Other browsers also use this list and have given no such guarantees when (or even if!) they will be removed. Preloading is basically permanent.
TL;DR: Conclusion
A MITM attack is an equivalent of a mailman opening your bank statement, writing down your account details and then resealing the envelope and delivering it to your door.
Use HSTS with a short time initially growing over time, and withoutincludeSubDomains and without adding to the preload list, unless you fully understand what these mean.
