Hypothetically speaking, let's say I purchase the domain eve-mail.com and get a cert via LetsEncrypt. I then use a reverse proxy to point to the reputable and widely used alice-mail.com.

Connecting to eve-mail.com would present with a 🔒 but would allow for the sniffing of clear text data between the client and alice-mail.com.

What (if anything) prevents this from happening?

  • You are using vague terms to explain vague terms. I'd suggest taking a bit more time with the question you have. I think you need to look up what a reverse proxy is and how it works. – schroeder Sep 6 at 16:03
  • @schroeder not sure what parts are vague, and I have written my own reverse proxy in nodejs a while back for testing reasons ... but I did it w/ a self signed cert and never thought about using it in this way. – CaffeineAddiction Sep 6 at 16:05
  • What do you mean by "this" in "what prevents this from happening", though? Are you asking if it would trick an IT manager into logging in with their alice-mail.com account on eve-mail.com? If it would trick a grade school kid? If there is some technological workaround that alice-mail.com could implement to prevent the page from loading correctly, or to redirect to the legitimate site? – Ghedipunk Sep 6 at 16:08
  • Ok, so let's break this down a little. You send someone a link to https://evil.com and your server proxies to https://example.com. TLS connections are maintained. You're asking what prevents one server from talking to another? Because the link and the browser are both going to say https://evil.com – schroeder Sep 6 at 16:09
  • 1
    A login page is HTML. A proxy requires access to the network. I can hack a site and add a phishing page far more easily than setting up a proxy. And attackers do use proxied sites, too. – schroeder Sep 6 at 16:16

What you describe is basically a typical phishing attack, where the victim is lured into visiting your evil domain while the victim is assuming that it is visiting the correct domain. The victim is then expected to leave sensitive data which the attacker can grab.

The main difference to the usual credential phishing sites is that the attacker forwards the data between the victim and the original site, so that the victim gets the expected behavior from the site while the attacker gets the secret data of the victim. The idea is not new, see for example New Reverse Proxy Tool Can Bypass Two-Factor Authentication and Automate Phishing Attacks.

There are a some possible protections against this:

  • Look at the URL and make sure it is the expected one. But this is not as easy as it sounds since similar or look-alike URL's (similar names, punycode attacks, ...) are possible.
  • Use a password manager which fills in the password to the domain in the URL. This way the password will not automatically be entered into the website and the user will hopefully wonder why this is the case and look more closely at the URL.
  • Similar newer authentications like FIDO have authentication bound the the actually visited URL and will not be tricked by this either.
  • If the original site requires client certificates the attack will also not work, since in order to create a TLS connection to the original site the attacker would need not only the victims certificate but also the matching private key, which is kept in the victims browser and not transferred inside a TLS handshake.
  • The site itself might use some JavaScript to check which URL it is on and in doubt enforce the correct URL or block access. Sure, once the attacker knows that and how this is done he might try to replace the script and spoof the response.

If the user connects to eve-mail.com, Eve will be able to inspect any data sent to it, as the TLS connection is terminated at eve-mail.com, of course.

Whether Eve chooses to reverse proxy the user requests to Alice or not simply depends on whether Eve wants to keep up the illusion; it isn't really relevant beyond this.

Can this be prevented? It depends. The user connects to eve-mail.com, so content served from eve-mail.com will be trusted. OTP 2FA doesn't really help either as eve-mail.com could just proxy the OTP.

However, there are some defenses.

  • If you are using a YubiKey or similar alternative as a second factor, the device would use origin-bound keys to prevent phishing as described. From the FIDO U2F spec:

    When the user registers the U2F device at an account at a particular origin (such as http://www.company.com) the device creates a new key pair usable only at that origin and gives the origin the public key to associate with the account. When the user authenticates (i.e., logs in) to the origin, in addition to username and password, the origin (in this case, http://www.company.com) can check whether the user has the U2F device by verifying a signature created by the device.

    As long as you initially registered with alice-mail.com, you're protected by origin-bound keys.

  • In the absence of a security key, services could block login on confirmation via a second channel. Both Apple and Google prompt for login confirmation via second factors, and the login confirmation prompt traditionally displays both the IP and/or the associated location of the login request. A savvy user might notice that the location does not match up with their own location, or that the IP does not match up with their own IP, and deny the login request, reset their password, etc.


The common method for this type of phishing attack however is not to act as a proxy but rather the entity itself.

  1. eve-mail.com would run a webserver generating a familiar log-in page.

  2. User enters their credentials now eve.mail can log-in to alice.mail and change the password.

One method to prevent this type phishing attack based on user deficiency is to offer some additional verification information such as after only entering the user name, prompt the user to select a correct previously determined (like at registration) or code. Only after this is successful will a password be asked for. All of this though depends on user understanding.

To prevent this type of phishing completely using X.509 client-certificates for log-in (stored on the browser) could be used where the server alice-mail could verify the client bypassing the user having to enter a password.

  • 1
    I think you are missing how it works. The browser does not connect to the original domain but to the attackers domain and the browser will not expect a certificate for the original domain but for the attackers domain there. This means there is a fully validated TLS connection between the browser and the server of the attacker and this connection terminates there so that the attacker can read everything. He then just forwards the data to the original server (maybe manipulated). There is nothing a "proper implementation of TLS" can do against this - it is about tricking the victim and not TLS. – Steffen Ullrich Sep 6 at 20:49
  • 1
    Your first suggested mitigation provides no mitigation at all. Client certificates are effective though. – AndrolGenhald Sep 6 at 21:04
  • Thanks Steffan. I removed the bad information but left the reaming information there. Please delete if not relevant. – James Sep 6 at 21:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.