On Feb 27, 2010, at 3:59 PM, Attila Nagy wrote:

Hello,

Hello!

I'm planning a data collector gateway and wondering whether Twisted's AMP would be good for the task.

Yes, I believe so.

AMP seems to be a good fit for the job, but I'm not sure about the security. I make the client side too, but I won't operate it, bad guys can take over that side and I want to protect my side.

This is a good rule to live by with any internet protocol :).

What would I like to do: 1. authenticate and authorize connecting clients with their SSL certificates 2. securely transfer arbitrary (binary and json) data from and to the clients (both the server and client would be twisted) 3. protect the server from malicious clients

I have some concerns about all three. For the first, is this OK now: http://twistedmatrix.com/pipermail/twisted-python/2007-August/015926.html ?

I'm not sure what you're asking. The example given in that message is doing a blocking handshake, which is still a bad idea. I don't believe the bug being described has been fixed (although I hope someone will correct me and tell me I'm wrong). However, you can authenticate connections with TLS certificates by using a command that inherits from AMP's StartTLS, and do the verification in the provided callback. Bootstrapping the TLS connection off of a plaintext connection is generally a better idea anyway, since that way you can support features like virtual hosting - when your client asks to secure the connection, the server can know who the client thinks it is talking to and intermediaries can route the connection to the appropriate back-end endpoint without necessarily understanding the protocol past that point.

For the second: the server should not be affected by the data which the client sends. I mean exploiting bugs in the data paths and limited protection from DoS, like abusing blocking pieces of code and therefore halting the reactor, or preventing memory overflow (if it sends 3TBs of data, it shouldn't be queued up in RAM, I should be in control about what happens in this case, or twisted should be clear measures for these) etc...

If you really want to harden Twisted's AMP implementation, you'll have to do a bit more work. Right now, individual AMP keys can only be 255 bytes, individual values are restricted to 65535 bytes, but boxes (messages of key/value pairs) can be arbitrarily big. It would be good to have a limit which restricted their size, and it would be fairly simple to do. Really DoS-proof protocols are really hard, but AMP's wire-level design is intentionally simple to make it amenable to lots of implementation hardening against many different types of attack. In other words, it is not already the protocol code that you want, but it would be easier to make AMP into the code that you want than to start from scratch.

And by the third I mean the above, plus for example if I have only one command defined for AMP with one string argument then no matter what happens, the client should only access that function with that argument and no other part of the program.

To my knowledge, AMP is already completely secure in this sense. I'm not a security auditor, but I would be _very_ surprised if you could execute arbitrary code by sending any sequence of bytes to a simple Twisted AMP server which only took a string argument.

How do you feel, is Twisted and AMP a good choice for that?

Yes. Thanks for considering it, -glyph