UPDATE 5: Craig Newmark still refuses to acknowledge his bug. All he has to do is correct his TCP settings and the whole problem goes away. Why won’t he?

I’m not sure… but reading some of the issues Craigslist is having related to it’s own firewall (see their system status page) I think they may be waiting on a vendor fix as well ;-)

A zero window simply means that the client will need to recieve an ACK from $server after every attempt to communicate with $server. The result is an incredibly slow TCP conversation that requires additional overhead (chatty) communication that may exceed timeout thresholds of higher level protocols (E.g. HTTP) There is no rule against the client continuing the conversation with a server advertising a 0 Window. It just needs more ACKnowledgements from the server before requesting additional data.

From what I’ve read, Authentium’s Achillies Heel is that it doesn’t respond correctly on subsequent packets when it is asked increase the window size.

This is only a problem when dealing with systems that don’t properly negotiate window sizes in the first place, and it’s not just an Authentium problem.. Many stateful firewalls (especially hostbased ones) only use the window sizes negotiated during the 3 way handshake, especially for stateless protocols like HTTP.

Craiglist’s webserver appears to only boost the window after the 3 way handshake occurs. I’ve just confirmed that myself via tcpdump.

A lot of these arguments are taking the form that Craigslist is a fault because “they were the last one who could avoid the accident.”

I disagree. Craigslist is the only people in charge of what Windows their hardware/servers are advertising, and since running a 24/7 web infrastructure requires technically more clue than installing and operating a host based firewall, it seems that Craig’s list could easily resolve all of the various problems they have with *MANY* firewalls (See their system status page for details) by fixing things on their end.