Going on 5 years ago, I had to do some integrations with SimpleSAMLPhp for a client. Now, in a Day Job, one of my colleagues is trying to get an integration working, and I’m amused that they find that my post is top hit when they google the error.

Anywho… what I wrote in my post wasn’t working, so I had to dig a little deeper.

Logins were working, but not from Chrome.

After digging into it a little, I found that SameSite headers were being set on the cookie, but no Secure flag.

This is Not Good, and so a lot of the more security focussed browsers will ignore these headers. You can even see this if you look at your developer tools.

Ok, so set the secure flag in your app, and job done, right?

Well. Normally, yes. But the added complexity comes from how our estate is currently configured – containers sat behind a load balancing gateway. This gateway, running haproxy, performs SSL offloading (yes, I know, NSA Smiley, but this is just temporary).

Solution

Once I figured out what was going on, the fix is quite simple. Namely, rewrite any cookies coming from the backend containers to include the secure flag.

This is fine, since none of our services are available over vanilla HTTP.

Adding the following:

rspirep ^(set-cookie:.*) \1;\ Secure

Did the trick after a restart.

Of course, previous tips still apply, you’re going to want to clear your caches etc so that the old cookie isn’t preserved, etc.

Hope this helps!

Tor (which stands for The Onion Router), is a powerful anonymity service originally developed by the US Navy, which helps protect citizens around the world from abuse and monitoring.

Most people use Tor via the Tor Browser, which simplifies setup, and I encourage you to use that where you can. This article discusses going one step further, and routing all traffic through Tor via the use of a HTTP proxy.

In the UK, the passage of the disastrous #IPBill places everyone under suspicionless surveillance, and I have client confidentiality to consider. So, as a matter of due diligence, I wanted to ensure that when my ISP’s surveillance database was inevitably hacked, the information the Russian Mafia got was of limited use.

This was easy enough to set up.

Install and configure Tor

The first step is to install Tor; not the browser, but the software the browser talks to in order to make it’s connection. On Debian based systems, apt-get install tor.

Tor comes with a SOCKS proxy, so enable support by editing /etc/tor/torrc and uncomment the line:

SocksPort 9050

If this is a network server, you may want to enable an external proxy on your network as well (for example, I have an always on Raspberry Pi running a tor proxy for all the various iOS devices on my home network).

Chain a simple HTTP Proxy

Once that’s done, you’ll have a SOCKS proxy up and running that’ll route anything it gets through Tor. Many things (e.g. the aforementioned iOS devices) won’t talk SOCKS. To solve this, I use a light weight HTTP proxy called polipo to create a HTTP proxy wrapper for Tor’s SOCKS proxy.

Install polipo: apt-get install polipo

Then configure the proxy to chain to Tor’s SOCKS proxy, modify /etc/polipo/config:

...

allowedClients = 127.0.0.1, 192.168.1.0/24 # Expose your network (modify accordingly)

socksParentProxy = "localhost:9050"
socksProxyType = socks5

proxyAddress = "0.0.0.0"    # IPv4 only

...

On my Raspberry Pi, I also disable the caching by adding diskCacheRoot = "" to the config, as this prevents polipo from filling up the SD card and breaking the proxy.

Restart both tor and polipo, and now you should have both a tor SOCKS and HTTP proxy.

Change your browser settings

Finally, you need to configure your browser (or your entire system) to use this proxy. This is different depending on what you’re using, but on Ubuntu you can set global proxy settings in your system settings, which will route all traffic over your new proxy (default port 8123).

iOS devices have a per-network proxy configuration found in your wireless network configuration (click on the little “i” icon).

Verify everything is working by visiting check.torproject.org.

So, it’s been a frustrating few days debugging a supposedly simple single sign-on handshake conducted over SAML.

Further to my last post, here are a couple of gotchas that tripped me up.

Watch your session settings

If you’re using sessions, you need to make damn sure your cookie settings are the same in both your app and SimpleSAML’s config.php.

Sadly, this isn’t always possible, at least not without making an offering to the Elder Gods. SimpleSAMLPHP’s settings are fiddly, and in the time I was poking at it, I couldn’t find a way of getting it to entirely match the application’s more enhanced security settings (we, for example, stipulate various ini flags and up the session’s hash algorithm).

SimpleSAMLPHP also seems to have a habit of generating its own session ids, although I might have been blinking at the source too long.

Either way, I ended up commenting out the session initialisation code in SessionHandlerPHP::__construct() and replacing every instance of the session starting code with a call to the app’s session initialisation code.

This adds some maintenance debt, but life is too short.

Debug in incognito mode

If you’ve been banging your head against session problems for long, you’ll have a lot of cruft in your cookie jar.

A hard learnt lesson (obvious in hindsight) was that even if the code works, it’ll likely fail with our old friend Exception: The POST data we should restore was lost.

The simplest way of ensuring you’re going to be clicking through with a fresh session is to use your browser’s incognito mode to test, and after each test shut down all of these windows (they share a context, so you’ve got to close all tabs and windows to fully clear the context) and open a new one.

Hopefully this might save you some time and frustration.