[Twisted-Python] Is AMP secure enough for the internet?
Hello, I'm planning a data collector gateway and wondering whether Twisted's AMP would be good for the task. 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. 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 ? 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... 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. How do you feel, is Twisted and AMP a good choice for that? Thanks,
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
On Sat, Feb 27, 2010 at 11:59 PM, Attila Nagy <bra@fsn.hu> wrote:
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)
If you're using SSL, then points 1 and 2 are the responsibility of SSL, not AMP, and you should be fine.
3. protect the server from malicious clients
I can't really comment on this, as I haven't studied the AMP implementation much; I think there are some built-in limits which will protect against certain kinds of resource DoS, but hopefully somebody else can comment in more detail. -- mithrandi, i Ainil en-Balandor, a faer Ambar
On Mon, 2010-03-01 at 02:33 +0200, Tristan Seligmann wrote:
On Sat, Feb 27, 2010 at 11:59 PM, Attila Nagy <bra@fsn.hu> wrote:
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)
If you're using SSL, then points 1 and 2 are the responsibility of SSL, not AMP, and you should be fine.
3. protect the server from malicious clients
I can't really comment on this, as I haven't studied the AMP implementation much; I think there are some built-in limits which will protect against certain kinds of resource DoS, but hopefully somebody else can comment in more detail.
AMP "keys" are limited to 256 bytes and "values" are limited to 64k. So that will prevent your program from handling a malformed AMP packet that tries to exceed those limits.... If the AMP parser detects a parsing problem it will drop the connection. One of the things you will need to implement yourself is preventing an otherwise legit client from flooding your server with legitimate requests... this is application-specific, and Twisted can't implement a generalized protection mechanize here. There should not be any way for a client to "access" any parts of your program apart from your pre-defined AMP command-handlers, and anything else for which you "give" access. Everything in AMP is length-prefixed, so this precludes any "quote-escaping" type vulnerabilities. There shouldn't be any issues with any of the built-in data types that AMP knows how to handle... if the data doesn't fall within acceptable parameters Python will thrown an Exception, and I *imagine* that also results in a connection tear-down, but it's been a while since I've studied the code in depth. Good luck, and let us know when you're AMP-DOSing test-suite is available ;) -teratorn
Eric P. Mangold wrote:
AMP "keys" are limited to 256 bytes and "values" are limited to 64k. So that will prevent your program from handling a malformed AMP packet that tries to exceed those limits....
Yes, I know that from the docs, but I haven't read the code, and it's not trivial where this is limited. If only on the client side, it doesn't protect...
One of the things you will need to implement yourself is preventing an otherwise legit client from flooding your server with legitimate requests... this is application-specific, and Twisted can't implement a generalized protection mechanize here.
That's right and clear, this needs to be implemented in the application. Thanks,
On Mon, Mar 1, 2010 at 2:15 PM, Attila Nagy <bra@fsn.hu> wrote:
Eric P. Mangold wrote:
AMP "keys" are limited to 256 bytes and "values" are limited to 64k. So that will prevent your program from handling a malformed AMP packet that tries to exceed those limits....
Yes, I know that from the docs, but I haven't read the code, and it's not trivial where this is limited. If only on the client side, it doesn't protect...
The first two bytes of the key are the length of the key. The server will stop reading after this length, and will bork if the length is bigger than 256. Actually, the client will do the same, since at this level, the protocol is symmetric. jml
participants (5)
-
Attila Nagy -
Eric P. Mangold -
Glyph Lefkowitz -
Jonathan Lange -
Tristan Seligmann