From: "Zed A. Shaw" Date: 2005-10-24T15:01:27+09:00 Subject: Re: I want my MOM On Mon, 24 Oct 2005 13:51:50 +0900 Brian McCallister wrote: > Feedback is much appreciated! > > On Oct 23, 2005, at 9:17 PM, Zed A. Shaw wrote: > > 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. > > I disagree with this -- you can bring down a naive server > implementation with or without this change -- just slam data into > whatever buffer is accumulating it until it croaks -- almost every > (I would say every but I don't know for a fact) JMS implementation > available does a full read for messages which are not of type Stream > (which is an option for huge messages). > You can bring down any server (especially a niave one), it's just a hell of a lot harder if the server is able to always know received data sizes and to boot clients if they are over the allowed sizes. Normally these specifications are not designed to prevent attacks totally (can't be done) but rather to make it easier for a server to have a reason to boot bad clients. Additionally, it lets the server properly size receive resources so that it can scale appropriately. If your server knows the size of all data coming in then it's a piece of cake to meet service needs by setting input/output sizes appropriately. Another thing a pre-sized protocol does is make it much harder to have buffer overflows. Since all buffers always have a size, and the protocol always has a size for each read, then you don't get buffer overflows (as much). In other words, yes morons will always write bad clients/servers, and yes other people write their implementations with line-endings, but that sure as hell don't make line-ended protocols right. As a bit of history, line-ended protocols were almost exclusively the domain of UNIX systems since the BSD sockets guys convinced everyone that "a socket is just a file". This led people to think, "Oh, then I'll just read lines from it like a file." Problem is, how many files do you open up where there's a bad guy on the other end messing with your file's data using a dirty connection? This is why "sockets are files" and line-ended protocols are super bad. Sockets are not files, be safe. My best analogy is it's the difference between wearing a condom with your wife and going to a glory hole. Uh, ok, that's a *really* bad analogy. I'll stop right there. :-) But, like I said previously, saying that your protocol is telnet accessible is just a super bad idea. The only people who ever need telnet access are developers (who should be able to write a client), or attackers (who should not be given any more help than they already have). Anyway, that's my argument. Let me know if it goes anywhere with the STOMP folks. > > 7) State that ":" is not a valid header. This means that they > > can't send empty headers. > > What is wrong with an empty header? It wastes bytes, but then so > does a long message. > Empty headers are fine, I meant the null header (see below). > : > > is bizarre, and wastes a little bit of space, but doesn't *hurt* the > protocol. In a defensive server, it would be fair to consider it a > potential attack and consider dropping the client. I am not sure > specifying this behavior adds anything to the spec except "oh yeah, > make sure of this" for implementors. > It's simply a suggestion to close a potential loop-hole. Thanks for listening. Let me know what comes of it. I'm basically basing a kind of little messaging system on STOMP with these changes. Zed A. Shaw http://www.zedshaw.com/