Improving the security of Swift's internal network

Swift assumes that its internal network (the connections between the proxy and the storage nodes) is secure. Therefore, Swift does not do any sort of on-the-wire encryption or request authorization.

At the San Diego summit, we had a good discussion led by Sam Merritt about how to improve the security of Swift's internal network. After the session, Robert Clark, Sam, and I got together to discuss some of the challenges and possible solutions in more detail.

Generally, the problem being solved is protecting the cluster if there is an attacker on the internal network. How can we prevent that attacker from sending messages to swift servers?

The most obvious solution is to use SSL. This gives us what we are looking for and also allows all of the messages to be encrypted. However, SSL is quite expensive on the object servers. We need to find a different solution.

One solution that will work is to sign each request that comes from swift servers with a shared secret key. If the signature does not match the request, then the request is denied.

Two keys should be supported at any time. This allows for key rotation and phased rollouts. The request signature should be generated in the same way as in existing Swift code (tempurl and formpost): hmac with sha1.

The request signing is good, but it would be nice if we could prevent unlimited replay attacks too. To do this, the servers should have a config option for a request signature TTL. Requests may include a TTL, but the server will use the shorter of the request TTL and the config TTL.

The signature is a hmac of the timestamp and the transaction id. It is validated on the timestamp, transaction id, and that the TTL has not expired.