Squid configuration for BBC iPlayer

Hello everyone.

This might be of use for me in the future when I’ve managed to lose an existing configuration or setup – or might be of use for anyone reading this who needs to do something similar to one of my setups.

I have a customer who uses Squid in their network. The Squid proxy is used to do content filtering to prevent access to undesired content on the internet. However – to do this Squid passes all the requests on to a cloud filtering company.

The side effect of this is, even though the cloud filtering company servers are based in the UK, the BBC have tagged the egress IP as being something that they don’t allow on iPlayer! Here is the response from BBC support…

I understand you’re unable to access iPlayer as you are not recognised as being within the UK.

Your IP is showing as being registered to CLOUD FILTER COMPANY DATACENTER NAME REDACTED (third party IP databases concur). It’s also listed as proxy type: hosting, proxy description: dns. While the proxy type itself indicates that this IP isn’t recognised as a broadband connection, it’s the description of it being a DNS that is actually causing the block here.

This all seems like going the direction of getting the BBC or their “data provider” to re-categorise an IP that the customer doesn’t even own will be far too difficult.

The easiest solution was to work out the configuration required for only allowing the iPlayer content to go direct and bypass the upstream cloud filtering company.

The following lines in the correct positions within the Squid config did the trick. In this case I’ve just made all of bbc go direct as I was too lazy to identify just the iPlayer domains.

acl bbcuksites dstdomain .bbc.co.uk .bbci.co.uk
tcp_outgoing_address 10.0.0.253 bbcuksites
tcp_outgoing_address 10.0.0.254 !bbcuksites

acl step1 at_step SslBump1
acl step2 at_step SslBump2
acl step3 at_step SslBump3

ssl_bump peek step1 all
ssl_bump splice all

In this instance they were using squid as an https_port and http_port “intercept”. You may not need the SSL Bump stuff if you are using Squid as an explicit proxy as the CONNECT request seen by Squid is likely to be the hostnames already instead of just an intercepted IP.

If using intercept… Squid needs to have ssl-bump enabled which also means you need to be running Squid 3.5 or higher. SSL peeking is required so you can tell the https sites being accessed. A couple of components on iPlayer (even though the main page is non-https) are over https:

Looking up CONNECT request from 192.168.35.4 with url component.iplayer.api.bbc.co.uk:443

Without ssl peeking Squid would only see “52.31.81.220:443” and wouldn’t know to send that traffic direct.

In the example config lines above I’m using source based routing at the router. Traffic from 10.0.0.254 goes via the cloud provider and traffic from 10.0.0.253 goes direct.

You could easily change this to just parent proxies, tcp_outgoing_mark or any other similar routing rule ability.

Advertisements
This entry was posted in Uncategorized. Bookmark the permalink.

4 Responses to Squid configuration for BBC iPlayer

  1. alex says:

    Hello

    I’m stuck trying to switch from sniproxy to squid and use the bump & splice features. What I want to achieve is the opposite of your setup: have the traffic going through the squid proxy on a cloud machine, so I can access BBC iPlayer. Can you give me some tips or an example conf by email? many thanks :)

  2. You would probably somehow want to use whatever the similar rules to these are:
    tcp_outgoing_address 10.0.0.253 bbcuksites
    tcp_outgoing_address 10.0.0.254 !bbcuksites
    But instead of setting the outgoing IP, work out of Squid can be told to use a parent proxy instead.

  3. alex says:

    thanks for getting back so quickly.
    There is no parent proxy, squid itself is the only one. It works fine for port 80 in clear-text with “http_port 80 accel allow-direct” thus proxying all incoming connections from my LAN, and that’s the exact behavior I’d like to achieve for HTTPS. It shouldn’t hijack certificates but just redirect them based on SNI. sniproxy does that very well, just that I suspect it isn’t compatible with some of the recent implementations at BBC and some other streaming sites, for example SPDY. So it is acting strangely and mostly not working, that’s why I’d like to give squid a try. The whole ssl_bump is new to me that’s why I am stuck by just trying examples found all over the Internet. Ideas? :)

  4. I’ve not been too impressed with the SSL interception of Squid.. I am looking to replace it with a Bluecoat or Smoothwall proxy in the places I have Squid deployed. Squid has many strange issues with SSL.

    I can’t give you much on how to set it up other than a bunch of my brain dump notes which has worked for my setups. Obviously these notes are pretty specific to my network setups and in transparent mode.. but might get you started.

    cd /etc/squid
    mkdir ssl_cert
    chown proxy:proxy ssl_cert
    chmod 700 ssl_cert
    cd ssl_cert

    openssl req -new -newkey rsa:2048 -sha256 -days 3650 -nodes -x509 -keyout myCA.pem -out myCA.pem
    openssl x509 -in myCA.pem -outform DER -out myCA.der #Create a DER-encoded certificate to import into users’ browsers

    /usr/lib/squid/ssl_crtd -c -s /var/lib/ssl_db
    chown proxy:proxy -R /var/lib/ssl_db

    ###Edit Squid Config to read:
    http_port 3128 intercept
    https_port 3143 intercept ssl-bump cert=/etc/squid/ssl_cert/myCA.pem generate-host-certificates=on dynamic_cert_mem_cache_size=4MB
    http_port 9898

    always_direct allow myNetworkACL
    acl step1 at_step SslBump1
    acl step2 at_step SslBump2
    acl step3 at_step SslBump3
    acl nobumpSites ssl::server_name “/etc/squid/nobumpSites.txt”
    ssl_bump peek step1 all # at step 1 we’re peeking at client’s TLS-request in order to find the SNI
    ssl_bump splice nobumpSites # here we’re splicing trusted connections to servers which names match our whitelist
    ssl_bump bump # and finally we’re bumping all other SSL connections
    #sslproxy_cert_error allow all #potentially dangerous
    #sslproxy_flags DONT_VERIFY_PEER #potentially dangerous
    sslproxy_options NO_SSLv2,NO_SSLv3,SINGLE_DH_USE

Comment on this topic

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s