Cynical bugger that I am…

I can be a little cynical sometimes though going through the morning news it seems there’s been a couple of rather heartwarming moves by a some  of our overlords today…

Microsoft to require suppliers to provide paid leave to workers (though Bill doesn’t look too happy in the photo he’s got my respect for the work of the Gates Foundation).

Apple boss Tim Cook ‘to donate millions’ to charity (and he can pay my sons university fees if he wants to as well!).

I suspect the shareholders of neither MS or Apple will care much though as it doesn’t really affect them and there’s a long way to go yet to address the inequality but… oops, there goes my cynicism again… 🙂


Security Vulnerability Review

Secunia have released an interesting report on the number of vulnerabilities found across various products. There’s much talk about MS and non-MS products which kind of makes sense from a Windows perspective but the report also contains a list of “20 core products” with most vulnerabilities identified in 2014.

Trouble is the report doesn’t specify where and how this “core” list was compiled; contrary to the 50 portfolio products which is based on the Secunia client running on Windows devices.

If it’s the same Secunia client – and I suspect it is since the number of vulnerabilities match for those products in both lists where I would expect some potential variance (Chrome on Windows v OSX for example) – then it’s rather odd that OSs such as Oracle Solaris and Gentoo Linux crop up… Hypervisors perhaps…

Another shocking thing for me was the number of IBM products in that top 20; 8 out of 20! Really? 40% of the products with most vulnerabilities are from IBM? Of course few people use these things (IBM Tivoli Composite Application Manager for Transactions anyone?) but it’s possible the stats are skewed due to too little data but it doesn’t sing well for big-blue… other than perhaps noting that they seem to find-’em and fix-’em.

… and that Java was #17 on the list is more worrying. That beastie is everywhere and riddled with problems…

Session Abolition

I’ve been going through my bookcase; on orders from a higher-being, to weed out old, redundant books and make way for… well, I’m not entirely sure what, but anyway, it’s not been very successful.

I came across an old copy of Release It! by Michael T. Nygard and started flicking through, chuckling occasionally as memories (good and bad) surfaced. It’s an excellent book but made me stop and think when I came across a note reading:

Serve small cookies
Use cookies for identifiers, not entire objects. Keep session data on the server, where it can't be altered by a malicious client.

There’s nothing fundamentally wrong with this other than it chimes with a problem I’m currently facing and I don’t like any of the usual solutions.

Sessions either reside in some sort of stateful pool; persistent database, session management server, replicated memory etc., or more commonly exist stand-alone within each node of a cluster. In either case load-balancing is needed to route requests to the home node where the session exists (delays in replication means you can’t go to any node even when a stateful pool is used). Such load-balancing is performed by a network load-balancer, reverse proxy, web-server (mod_proxy, WebSphere plugin etc.) or application server and can work using numerous different algorithms; IP based routing, round-robin, least-connections etc.

So in my solution I now need some sort of load-balancer – more components, joy! But even worse, it’s creating havoc with reliability. Each time a node fails I lose all sessions on that server (unless I plumb for a session-management-server which I need like a hole in the head). And nodes fails all the time… (think cloud, autoscaling and hundreds of nodes).

So now I’m going to kind-of break that treasured piece of advice from Michael and create larger cookies (more likely request parameters) and include in them some every-so-slightly-sensitive details which I really shouldn’t. I should point out this isn’t is criminal as it sounds.

Firstly the data really isn’t that sensitive. It’s essentially routing information that needs to be remembered between requests – not my credit card details.

Secondly it’s still very small – a few bytes or so but I’d probably not worry too much until it gets to around 2K+ (some profiling required here I suspect).

Thirdly, there are other ways to protect the data – notably encryption and hashing. If I don’t want the client to be able to read it then I’ll encrypt it. If I don’t mind the client reading the data but want to make sure it’s not been tampered with, I’ll use an HMAC instead. A JSON Web Token like format should well work in most cases.

Now I can have no session on the back-end servers at all but instead need to decrypt (or verify the hash) and decode a token on each request. If a node fails I don’t care (much) as any other node can handle the same request and my load balancing can be as dumb as I can wish.

I’ve sacrificed performance for reliability – both in terms of computational effort server side and in terms of network payload – and made some simplification to the overall topology to boot. CPU cycles are getting pretty cheap now though and this pattern should scale horizontally and vertically – time for some testing… The network penalty isn’t so cheap but again should be acceptable and if I avoid using “cookies” for the token then I can at least save the load on every single request.

It also means that in a network of micro-services, so long as each service propagates these tokens around, the more thorny routing problem in this sort of environment virtually disappears.

I do though now have a key management problem. Somewhere, somehow I need to store the keys securely whilst distributing them to every node in the cluster… oh and don’t mention key-rotation…