Consider a scenario where my ISP attempts to use a Man-in-the-Middle attack against me to read and possibly modify my Internet traffic.

What can I do to access the Internet and still ensure the integrity and confidentiality of my traffic?

Furthermore, are there techniques I can employ to make it more difficult for the ISP to notice that I am trying to evade their Man-in-the-Middle attack?

Additional context from the comments: The ISP doesn't install a cert on my PC. Rather, I get a warning, and my only options are either to: A) skip the warning and let the ISP Man-in-the-Middle me; or B) stop using the Internet.

2 Answers 2


How to protect confidentiality and integrity?

Limit who you trust; encrypt everything.

Obviously, don't install any CA certificate imposed by the ISP. Consider removing certificates that are controlled by parties you do not trust.

At a minimum, make sure HTTPS is used for everything; you could even block traffic to port 80 and other HTTP ports to ensure nothing is leaked. Even with HTTPS, the ISP can still see the hostnames of the site you are visiting, thanks to SNI, if using TLS < 1.3 without ESNI. To mitigate this, only use TLS 1.3, and/or use a browser that supports ESNI. Problem is, not all websites may support these technologies.

The other major threat is DNS. DNS reveals just as much as SNI, but it also has no guarantee of integrity. Even if you change your DNS provider to something outside of your ISP, your ISP could theoretically redirect your DNS queries to their own servers and modify the traffic without any way to detect it. There are several replacements for DNS which attempt to mitigate the confidentiality and integrity problems, notable of which are DNS-over-HTTPS (DoH), DNS-over-TLS (DoT), dnscrypt, and dnscurve (note DNSSEC is not listed; it does not solve the problem of confidentiality). These protocols are all incompatible with each other and have varying degrees of standardization; it appears that DoH and DoT have gained the most traction. Various big-names have started promoting these protocols and have started offering them within browsers and mobile operating systems. These protocols can either be enabled individually on each device in the network, or configured on the router so that all devices speak normal DNS to the router, which then proxies the request using DoH or DoT.

But the above may not cover everything you do. To ensure more complete safety, use something that can tunnel all of your traffic, such as a VPN*, IPsec, or Tor (as written in the other answer, the ISP may have blacklisted known Tor nodes, so you may need to choose an entry node manually). Ensure that wherever the tunnel ends, it is beyond the reach of your ISP (e.g. don't set up a VPN tunnel to a friend's house that uses the same ISP), and it with a party that you trust (relatively). This depends on your exact threat model, so "free-VPN-that-collects-and-logs-all-your-traffic" may be acceptable compared to an ISP that is actively hostile.

If you own and control your own router (preferred anyway), you may be able to configure it as a VPN client such that all devices on your network will automatically use the VPN. If you do not control your router (i.e. ISP owned), connecting to a VPN from each device on the network will mostly mitigate the threat of the router.

*Most modern VPN providers and software will have pretty safe defaults, but VPNs can be configured without encryption as well, so don't automatically assume they are equivalent in all possible scenarios.

How to evade detection of these methods by the ISP?

This is definitely a hard problem, as it is fairly trivial to analyze network traffic. That is, changing the port you use for a protocol may not fool anyone (unless the traffic is encrypted and unrecognizable, and on a port that normally has such traffic). So, tunneling all of your traffic over a VPN on UDP port 53 may defeat some basic firewall rules, but deep packet inspection (DPI) will immediately raise red flags; port 53 is usually for DNS, which is a well defined protocol. Your traffic won't look like this at all.

Likely, the best option is to choose a port such as TCP 443. Still, it may be possible to profile the traffic and determine that it is not purely web traffic, with a decent degree of certainty, but it may not raise too many red flags since most internet traffic is probably over 443 anyway.

There are also ways to tunnel IP traffic over standardized, plaintext protocols such as HTTP, DNS (iodine), carrier pigeon, and ICMP (icmptx). While I do not think these may solve the problem (in fact, they could bring more attention to your traffic), they are interesting and perhaps relevant. I suppose there could be a scenario where your ISP forces you to use plaintext protocols that they can enforce and inspect with DPI. A VPN could be used to tunnel all traffic over another protocol while still conforming to the outer protocol's standards, thus evading the restrictions.


  • Require HTTPS and secure DNS

  • If this prevents your availability, e.g. the ISP forces HTTPS traffic to a proxy, use a VPN or Tor with manual entry nodes. The VPN may take some research or experimentation to get working; perhaps there are ports or protocols that are overlooked. E.g. perhaps TCP traffic is bent toward the proxy, but UDP is overlooked or mistakenly routed anyway (possibly only certain ports), but this is only a hypothetical misconfiguration

  • If all else fails, use application-layer encapsulation as a last resort. HTTP/DNS tunnels often still work behind proxies and forwarders, and may allow your traffic to pass through since it matches an allowed, cleartext protocol (but obviously your data would be encrypted). There may be some severe performance penalties to this method, but it can get you out of many a tricky scenario. This is not foolproof, it will still stand out and could be signatured.

  • Adapt to whatever they throw at you

  • Correct me if I am wrong, but if my ISP uses a Man-in-the-Middle proxy to break the TLS encryption, then using HTTPS will not help me at all.
    – user163495
    Aug 13, 2019 at 13:00
  • It will help you a little bit, in that you will be notified by your browser that the certificate is not valid.
    – hft
    Aug 13, 2019 at 16:15
  • @MechMK1 They can't "break" TLS, but merely circumvent it in certain conditions. Namely, if you install a CA certificate they provide (like in your linked example), or you ignore TLS warnings, or you navigate to a site over HTTP without HSTS preloaded. Otherwise they can't do much besides try to trick you into 1, 2, or 3 or some other variant Aug 13, 2019 at 22:44
  • @multithr3at3d Yes, but then you either have no confidentiality or integrity (in case you ignore the warning), or you have no availability (in case you don't ignore it).
    – user163495
    Aug 14, 2019 at 7:08
  • @MechMK1 So it would be wise to not proceed past warnings. ah, your original question doesn't mention availability. Also, since this is your ISP we're talking about, they could completely deny your availability at any time by cancelling your service for any reason. A bit difficult to mitigate. Aug 14, 2019 at 11:11

When you connect to web pages using ssl the only way for your ISP to make you man-in-the-middle is to install a CA in your device / browser and then be able to modify the certificates of the websites.

Another way would be that your ISP will redirect HTTPS websites to HTTP, but today the most important websites already use the HSTS header to prevent this an attack.

The best way to prevent your ISP from spying on you is to configure a VPN either on your device or directly on the router. Today there are many types of VPN: pptp, IPsec, OpenVPN, ... The best option is to use OpenVPN since it has proven to be the most reliable.

You can also use PGP in the emails, in this way asseguras that only the recipient can read the email, you also have the option to sign the message to verify that it has not been modified (in this case by your ISP)

In summary:

  • Use a VPN

  • PGP on mail

  • Verify / review the root certificates you have installed.

  • Try not to use the router that your ISP gives you since they often modify the firmware

  • Do not use the dns server of your ISP (change that on the dhcp option on you router and on your device)

When using a vpn, look to use ports 80 and 443 to connect, as it seems that your traffic is destined to the HTTP and HTTPS (web) protocol.

You can also use port 53 to connect to the VPN since this way it will appear that you are making DNS requests

I would tell you to route all traffic through the TOR network. But I would also tell you to mount a TOR relay server on a VPS server to use it as the first jump when connecting to TOR, in this way, this IP will not be in the blacklists of the internet that say that IPs correspond to the TOR network

An alternative is to use a vpn XORing the resulting packages.
In this way, it will be more complicated for the ISP to identify that you are using a VPN, the only thing they will see is that you are using the UDP protocol if you use a VPN configured to use UDP, that is why I think it is better to configure the VPN so that use TCP. In this link you will see openvpn_xorpatch to obfuscate vpn connection: https://github.com/clayface/openvpn_xorpatch

  • I object to the first part: If the ISP doesn't install a cert on my PC, I get a warning, and my only options are now either to a.) skip the warning and let the ISP MitM me, or b.) stop using the internet.
    – user163495
    Aug 12, 2019 at 12:35
  • What kind of warning? The typical message that tells you that the certificate is not valid?
    – thewolfx41
    Aug 12, 2019 at 12:41
  • Yes, exactly. Your only options now are to ignore the warning or to not connect to the site.
    – user163495
    Aug 12, 2019 at 12:41
  • Furthermore, the Port 53 is nice in theory, but if I were to watch e.g. a normal video on YouTube at 1080p, I would generate far more traffic than any DNS query would ever do. It'd stick out like a big red flag.
    – user163495
    Aug 12, 2019 at 12:42
  • You are absolutely right. Answer updated
    – thewolfx41
    Aug 12, 2019 at 12:51

You must log in to answer this question.