From: "Zed A. Shaw" Date: 2005-10-24T13:17:27+09:00 Subject: Re: I want my MOM Hey Brian, I've got an alternative hack that fixes my two problems with the protocol. My big problem is that line-ended protocols are a pain in the ass to implement and scale. Sure it makes it easy for you to use telnet rather than write a real test client (which seriously took me like 10 minutes in Ruby BTW), but line-ended protocols leave open huge areas for abuse. With that in mind here's my proposal to fix the STOMP protocol so that it's still telnet accessible but all sizes are predefined to avoid abuse: 1) Define the official line ending. This is important since most IETF protocols end lines with \r\n. For the rest of this I assume \n. 2) Header is changed to be: SIZE COMMAND\n with SIZE being a decimal string of the byte size of the HEADER portion immediatly after this line. 3) Specify that the first line is never longer than X bytes. This is important as a classic DOS attack is to "trickle" characters forever never giving the \n. If you explicitly state that it can't be longer than say 128 characters then servers can boot bad clients quick. 4) The SIZE of the header specifies the exact length, and removes the need for the \n\n separator. This is also important because I can boot a client that tries to send more than SIZE or that says it's going to send a SIZE that I don't want. This prevents another attack where I just trickle header lines until the server croaks. 5) Require that the header MUST have the content-length settings. This is again to make sure that requests which are too large are always booted. Making this optional just leaves open an attack where you again slam the server with never ending data until it dies. This also makes it very clear how the content is always sent and leaves nothing open for debate. 6) State that the header has an exact format of "key: value\n" and that the value goes from the space after the ":" until \n always. Even other ":" characters are included. 7) State that ":" is not a valid header. This means that they can't send empty headers. 8) Also state that clients SHOULD be booted immediately if they don't follow these rules exactly. I really don't like protocols that try to be "nice to users". These protocols are actually just leaving things open for attackers to exploit. In the end "users" do not write clients, developers do and being explicit about everything makes it easier for them. This also makes it easier for server implementers to boot bad clients without any excuse reducing their attack vectors and improving their chances of withstanding DOS attacks. Anyway, that's just my opinion on it. Take it or leave it. Zed A. Shaw http://www.zedshaw.com/ On Mon, 24 Oct 2005 12:41:51 +0900 Brian McCallister wrote: > Zed, > > The \0 terminator is used if there is *not* a content-length header, > it is recommended that a content-length header be used. The primary > reason for this is that I *really* want to support telnet and netcat > for emergencies and debugging =) > > That said, please keep the criticism coming, I don't think for a > moment that I know everything, and the folks helping with stomp are > all merely trying to solve a problem, no one is pushing an agenda > (that I am aware of!). > > I would very much appreciate your further feedback! > > -Brian > > On Oct 23, 2005, at 8:31 PM, Zed A. Shaw wrote: > > > I'm kind of in the process of writing something like this, but if > > you want take a look at STOMP and the following: > > > > http://stomp.codehaus.org/Ruby+Client > > > > STOMP will then let you talk with several different JMS > > implementations > > (mostly open source). > > > > Be careful though, STOMP isn't as well designed as I'd like. For > > example, it uses \0 to end the message body, without any way of > > escaping the \0. This means you have to base64 things you send if > > they > > have \0 characters. > > > > Zed A. Shaw > > http://www.zedshaw.com/ > > > > > > On Mon, 24 Oct 2005 12:03:26 +0900 > > swille wrote: > > > > > >> Err.. :) Can anyone tell me if there's a MOM for Ruby? Anything > >> like JMS? I haven't quite found one in my googling. > >> > >> Also, and this is a long-shot, is there possibly a workflow engine > >> that anyone has stuffed away? > >> > >> > > > > > >