How to prevent a third party from proxying an HTTPS website?

Question

I am hosting some kind of database management interface on https://www.prettylongdomainname.example/ I have implemented HTTP Strict Transport Security to prevent people accessing this website over HTTP because I don't want my users to submit their login credentials over an unencrypted channel.

Now one user has registered the domain www.pld.example with a domain name provider that offers some kind "domain name redirection service" that effectively performs a man-in-the-middle attack on my website. It proxies the original website and makes it available at http://www.pld.example/ Some users are - for convenience - using the shorter URL and are unaware that they are now sending their passwords in plain-text to a third party.

What are the mechanisms I can use to prevent this type of MITM attack?

anx · Answer 1 · 2018-03-29T17:11:55.997

Heres a number of strategies you might want to consider:

1. From your server logs, figure out by which means the proxy is downloading your site and selectively change responses for him e.g. if hes using one specific provider, block or change responses for their address space

2. It may be completely sufficient to just informally notify the provider of the proxy be sure to contact their abuse department directly, not the sales guys. if their server IP is registered by different company than their domain registrar, take the path of least resistance - first ask the provider headquartered in a country closer to yours.

3. Depending on the TLD it will be anywhere from trivial to impossible to figure out the operator of the site and/or get a court order that forces their dns provider to drop them

4. Report them to Google Safe Browsing Use the option Report Phishing Page. This will - if our Google overlords decide so - create a big fat warning for users of the proxy AND it will remove the site from search results. Most users of most browsers are using the google safe browsing block lists, so this will effect not quite everyone, but close to.

Daniel · Answer 2 · 2018-03-29T12:20:55.497

We use combination of those headers(config for nginx):

    # Before enabling Strict-Transport-Security headers please read into this topic first.
    add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;";
    add_header X-Content-Type-Options nosniff;
    add_header X-Frame-Options "SAMEORIGIN";
    add_header X-XSS-Protection "1; mode=block";
    add_header X-Robots-Tag none;
    add_header X-Download-Options noopen;
    add_header X-Permitted-Cross-Domain-Policies none;

Be careful, depending on your application those might break your website. Read here before implementing them https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security

EDIT: As pointed those will not outright prevent proxing trough foreign domain, you should also set the additional step of serving requests that are only addressing you via the correct host name:

Change your default nginx.conf to something like:

server {
    listen       443 ssl http2;
    server_name  _;

### Set dummy certs 
    ssl on;
    ssl_certificate /usr/local/etc/ssl/dummy.crt;
    ssl_certificate_key /usr/local/etc/ssl/dummy.key;
    ssl_dhparam /usr/local/etc/ssl/dhparam.pem;

### Block all, allow only vhosts on this server
    location / {
        limit_req      zone=one burst=10 nodelay;
        deny all;
        return  418 "I'm a teapot"; # Just for the fun of it
    }
 }

 ### Virtual Hosting
   include /usr/local/etc/nginx/conf.d/*.conf;
}

Now in /usr/local/etc/nginx/conf.d/ (FreeBSD paths, adjust to your distro) create a domain_name.conf that contains settings for your actual site and set the accepted server_name for it:

server_name  www.example.com example.com;

That combined with the protection headers will stop most of the attacks of this kind.
However a really clever jackass can spoof the Host header on his reverse proxy as well.
The only truly working method was https://developer.mozilla.org/en-US/docs/Web/HTTP/Public_Key_Pinning however this standard is being deprecated as it was half cooked and quite dangerous to implement.

These headers are good security practice to mitigate client-side risks: click jacking, XSS, etc. They do nothing to prevent someone acting as an intermediary by intercepting traffic on a bogus domain name and passing this to the real back-end. — Cosmic Ossifrage, Mar 29 '18 at 11:41
That still won't work. **There is nothing server-side you can do** to prevent a third-party intercepting traffic on another domain and proxying it via a separate connection from their systems to the original hosting service. — Cosmic Ossifrage, Mar 29 '18 at 12:28
Yes it won't work if the malicious domain owner is doing this on purpose as s/he can go around it in various ways. If it it not by accident and a malicious attack, best bet would be to get in touch with the abuse contact of the domain / registrar and report this activity. — Daniel, Mar 29 '18 at 12:39
If I were shady and were to proxy traffic to your server, I would strip off all optional headers. This is really easy to do in haproxy. The client would never see HSTS. I could even re-encrypt with my own certs and intercept traffic on my server to capture passwords and cookies. — Aaron, Mar 29 '18 at 21:49

How to prevent a third party from proxying an HTTPS website?

2 Answers2