May, 2012: Fun with Blocks

We’ve already seen that Smalltalk has a very lightweight syntaxes for closures: [:x | x] for the identity function, for instance. We’ve seen them form an essential part of Smalltalk’s structure, allowing us to have all control structures part of the library rather than baked into the language. For what else might we use them?

(more…)

May, 2012: Secure communication in the Cloud

The internet does reliability end to end. That is, when a node A sends a message to node B, the message travels through many other nodes. These intervening nodes make a best effort at delivery, but if they don’t succeed, they just forget about it. B must confirm receipt, and A must try again if it doesn’t.

Communicating securely requires the same approach. We should not guarantee each step is secure, and hence the whole path is secure, but design a system in which only the design of A and B matters.

The more we do our computing in the cloud, the more true this becomes. Simply put, the security of our communications depends on too many people, and the chances of failure multiply.

For example, we might use a messaging service, provided in the cloud. A and B could authenticate to the message server, and ensure privacy by connecting using SSL. The server could implement access controls, to ensure other users of the service won’t receive messages they are not entitled to receive. In this arrangement, you are making some assumptions:

• The authorisation code in the server is correct. I.e. bugs don’t cause it to deliver messages to the wrong recipients.
• The code which configures authorisation in each of the clients is correct. I.e. bugs in the client don’t cause deliveries to the wrong recipients.
• The server is never remotely hacked.
• The server is physically secure.
• The administrators of the server never looking at you messages, and never pass them on to anyone else.
• The administrators of the server never provide access to someone unauthorised.
• The backups of the server are securely stored, and a never used for anything other than restoring the service. They are never passed on to someone unauthorised.
• Backup media is securely disposed of.
• The servers disks are securely disposed of at the end of their life.
• The SSL private keys of A, B are never transmitted to someone unauthorised

Actually, this list only cover’s privacy. If I covered authenticity, my list would be twice as long.

Alternatively, A could encrypt messages using B’s private encryption key, and sign them with its private signing key. Then we are assuming:

• The private keys of A and B are never transmitted to someone unauthorised.

Now you can perhaps see that if you are not encrypting and signing messages before sending them via a message server, you need a good excuse.

Unfortunately good excuses abound:

• What standard encryption scheme or software should I use?
• What key management software should I use?

For example, GPG requires you to fork a process for each message you sign and encrypt, and when it decrypts and validates messages, it only tells you the message was from someone you trust, but not who, so it assumes you trust everyone equally.

I’ve recently designed a solution which uses end to end encryption of messages, and a message server to minimise the attack surface of the solution, and ensure privacy while transferring data over the internet. The attack surface is minimised to the extent that the nodes are behind firewalls that allow no incoming connections. Because messages must have valid signatures to be accepted, an attacker cannot use specific payloads in messages to attack the system. They are limited to attacking the code which parses the envelope. This code is extremely simple.

To do this efficiently, we have designed our own cryptographic suite, based on the NSA Suite B specification. Because this specification does not specify an encoding, we have designed our own envelope for messages. The resulting library also includes a sophisticated, extensible trust model. We plan to publish the result as open source.

We see lots of sites that use RabbitMQ, and other message servers, and would benefit from the security this architecture provides. Either these sites allow clients to interact with services via a message server, or use cloud based messaging services. Using cloud based messaging services has significant cost benefits over hosting your own message server, and in this architecture, the decision to do this has no security implications.

May, 2012: Continuous Integration for Haskell: Cabal TeamCity plugin!

I’m happy to announce that my Haskell Cabal TeamCity plugin is available for download.

With this plugin you can practise continuous integration (CI) with your Cabalised Haskell projects using a CI server called TeamCity.

In case you haven’t heard of TeamCity, it’s a really neat piece of kit. Internally we use TeamCity quite extensively to perform automated continuous builds (and sometimes deployments) of our Maven, Ant, and NAnt-based projects. It’s incredibly feature-rich, and has a very visual, clean and clear web interface.

(more…)

May, 2012: Visualising your web browsing history

I’ve been doing a bit more data visualisation work, with a focus this time on my web browsing. If you’re using Firefox or Chrome (not Opera, as they don’t provide this data), then it turns out that your local history also contains referrer data i.e. you have a history record of not just where you’ve been, but how you got there…

Why is this interesting? Well, because it shows a slightly different view of the web. There’s an awful lot of hyperlinks out there, especially when you get to heavily interconnected places like Wikipedia, but in a way that’s far too much data. Instead, we’ve got some data that shows how you interacted with the web, and if we’ve got a reasonable visualisation tool, then we can learn a few things. (more…)