Tag Archives: proxy

Posted on
by

I have previously talked about speeding up your site by using Squid as a reverse proxy to cache served pages. This is a great thing to do, but presents a problem now that all sites are moving over to HTTPS, since for various technical reasons reverse proxies can’t really handle HTTPS.

These days the standard way of doing this seems to be using Varnish as a cache, and Squid seems to be a little “old hat”, however I have several client estates which were set up before Varnish came on the scene, so I needed a solution I could get up and running very quickly.

Terminating HTTPS

Thankfully, the solution is very similar whatever reverse proxy you’re using. The solution is simple, you need to install something that terminates and handles the HTTPS session before sending it to your proxy. The simplest way to do this is to install NGINX and configure it to handle HTTPS sessions.

1) Disable Apache’s handling of HTTPS (if you’ve got an existing, un-cached, HTTPS server).

2) Install the basic nginx apt-get install nginx-light

3) Configure nginx to forward to your proxy (which you have previously configured to listen on port 80)

server {
        listen 443 ssl;
        server_name www.example.com;
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

        location / {
            proxy_pass http://127.0.0.1:80;
            proxy_set_header X-Real-IP  $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto https;
            proxy_set_header X-Forwarded-Port 443;
            proxy_set_header Host $host;
        }
}

After restarting nginx, you should be able to see https requests coming in on your squid proxy logs.

Gotchas

The biggest gotcha that you’re going to hit is that if you’re checking whether a request is HTTPS in your app (e.g. for automatically forwarding from insecure to secure), you’re not going to be able to use the standard protocol checks. The reason being is that HTTPS is being terminated by nginx, so by the time the session hits your app, it will not be seen as secure!

To perform such a test, you’re instead going to have to check for the X-Forwarded-Proto header instead ($_SERVER['HTTP_X_FORWARDED_PROTO'] in PHP).

Posted on
by

I’ve submitted a pull request over on the Known project git repo that allows you to specify a CURL proxy connect string (which has since been merged).

If specified, this connection string will make all web service and web mention calls be sent via a proxy server.

This was a relatively small change, but is useful in many ways – for example, for communicating through a corporate firewall. It is also provides a way of routing Known to Known communication over TOR.

Why would you want to do this?

Well, this is part of an ongoing effort to harden Known against the new attack realities we face on the internet in the 21st century.

One of the things that the Snowden documents have revealed, is that the bad guys are particularly interested in harvesting everyone’s social graph – who knows who – so that they can, among other things, automate guilt by association.

Going to some lengths to hide this information from an attacker sitting on the wire, is therefore, a prudent thing to do.

Ok, how?

  • Install the TOR proxy on your server; this may just be as simple as typing apt-get install tor.
  • By default the tor package only installs the client, so you’ll need to modify the config to open up a SOCKS relay.
  • Next, tell your known site to use this relay; open your config.ini and set the proxy_string:
proxy_string = 'socks5://path.to.tor.proxy:9100'

Gotchas

Routing over TOR is only part of the solution of course. For the communication to be properly safe, you should also encrypt the communication using HTTPS.

Unfortunately, whether a connection is conducted over encrypted HTTPS or not is largely up to your friend’s webserver. But, you wouldn’t be silly enough to run unencrypted, right?

Given the numbers of nasty attacks that can be launched against an unencrypted web connection, the internet at large is now moving towards deprecating unencrypted port 80 HTTP. Google search results will now give preferential treatment to encrypted websites, so that’s another reason!

So, don’t be part of the problem. Have fun!

Posted on
by

I recently had to reinstall Raspbmc for the 4th time in as many days, thanks to an automatic update, sunspot activity, and possibly an intermittently dodgy SD card.

Latest attempt seems to be working (touch wood); the Pi hasn’t bricked itself yet, and the networking is still working. However, fan art is not being downloaded.

This is a note to self, but might be of use to those of you in a similar situation.

The Problem

You’re running XBMC/Raspbmc on a box in your home network. This network sits behind a combined Squid + Privoxy proxy, to provide network level object caching and malware/advert filtering.

You update your library, and while TV season descriptions are loaded, season images and fan art are not.

The Solution

What seems to be happening is that Privoxy is incorrectly identifying fan art images as adverts, which is causing Privoxy to return a 403 error when XBMC attempts to retrieve the resource. This only seems to be happening with the thetvdb scraper, the IMDB scraper for movies seems to have no issue.

The fix is simple, all you need to do is add an exception for thetvdb.com in your /etc/privoxy/user.actions file:

{ allow-ads }
.thetvdb.com

Now you should find that season fan art is accessible once more!