technology from back to front

Archive for the ‘Our Software’ Category

Controlling fast producers in a Rabbit-as-a-Service

Offering a RabbitMQ server on the public internet poses a few challenges. Today we’ll look at the problem of controlling fast producers.

Read more…

by
Frank Shearar
on
31/08/13

Visualising RabbitMQ Topologies

I’m currently documenting an application that uses RabbitMQ extensively. I want to show the routing topology within the broker, but I want the bulk generated automatically because there are a lot of entities to deal with. Given that I can export the broker definitions into JSON, it seemed like it would be fairly straightforward to generate something using Graphviz.

Read more…

by
Lee Coomber
on
04/11/12

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.

by
david
on
25/05/12

Persuading mercurial-server to work on Windows

A few years back, needing decent authentication and key management for Mercurial repositories, we wrote mercurial-server. Recently, we were in the position of wanting to use this with one of our clients, but this time it would need to run under Windows. This was a bit of a problem as it was designed for a Unix-type environment. On the other hand, it’s mostly written in Python, and we could use Cygwin, so how bad could it be?

As it turns out, not too awful. I needed to make a few small modifications, and we’ve now managed to deploy a working mercurial-server under Windows.
Read more…

by
Tom Parker
on
05/04/12

mercurial-server needs a long-term Debian sponsor

Thanks to the patient work of Jakub Wilk, mercurial-server 1.2-1 has hit the Debian “unstable” repository, where all being well it should make its way into testing, stable, Ubuntu and so forth. Jakub stepped in at the last minute when I discovered that the project’s previous sponsor, Steve Kemp, had resigned as a Debian developer in April.

I’d like to arrange a longer-term Debian sponsor for mercurial-server now, in advance of the next release, so that we can make sure we fix any issues with the package in advance and we’re ready when release time comes. If there are any Debian developers out there who use mercurial-server, please do get in touch – thanks!

by
Paul Crowley
on
14/09/11

mercurial-server 1.2 released

Version 1.2 of mercurial-server is now available. This fixes a security problem, adds compatibility with Mercurial 1.9 and fixes incompatibilities with older versions of Python, adds MQ compatibility, and some other minor things.

Unfortunately it may not immediately enter Debian, because my former sponsor is no longer a Debian developer. If you’re an official Debian developer and you’d like to sponsor this package, please get in touch – thanks!

mercurial-server on mentors.debian.net.

by
Paul Crowley
on
06/09/11

mercurial-server version 1.1 released

Version 1.1 of mercurial-server is now available. This permits one repository to be in a subdirectory of another, which makes subrepositories more convenient, as well as improvements to logging and documentation. I’ve also included the collection of scripts I use for testing under the “dev” subdirectory in the main repository, though I’d want to clean these up somewhat before including them in the release tarballs.

The Debian version also includes fixes for all the outstanding bugs against it in Debian; I’ve sent the files off to the sponsor, so hopefully that’ll enter Debian testing soon.

by
Paul Crowley
on
19/12/10

SpringSource / VMWare Acquire Rabbit Technologies

SpringSource, a division of VMware, Inc. today announced the acquisition by VMware of Rabbit Technologies, Ltd, a company set up by LShift and partners Monadic and CohesiveFT.

Read the full story

by
mike
on
14/04/10

On the limits of concurrency: Worker Pools in Erlang

A worker pool is a very common pattern, and they exist in the standard libraries for many languages. The idea is simple: submit some sort of closure to a service which commits to running the closure in the future in some thread. Normally the work is shared out among many different threads and in the absence of anything fancier, one assumes a first-come-first-served queue of closures.

Erlang, with its light-weight process model is not a language which you would expect would require such an approach: processes are dirt cheap, and the scheduler maps processes onto threads when they are ready to be run — in many ways, the ErlangVM is a glorified implementation of a worker pool, only one that does pre-emption and other fancy features, in a very similar way to an OS kernel. However, we recently found in RabbitMQ a need for a worker pool. Read more…

by
matthew
on
29/03/10

The fine art of holding a file descriptor

People tend to like certain software packages to be scalable. This can have a number of different meanings but mostly it means that as you throw more work at the program, it may require some more resources, in terms of memory or CPU, but it nevertheless just keeps on working. Strangely enough, it’s fairly difficult to achieve this with finite resources. With things like memory, the classical hierarchy applies: as you use up more and more faster memory, you start to spill to slower memory — i.e. spilling to disk. The assumption tends to be that one always has enough disk space.

Other resources are even more limited, and are harder to manage. One of these is file descriptors. Read more…

by
matthew
on
23/03/10

Search

Categories

You are currently browsing the archives for the Our Software category.

Feeds

Archives

2000-14 LShift Ltd, 1st Floor, Hoxton Point, 6 Rufus Street, London, N1 6PE, UK+44 (0)20 7729 7060   Contact us