Re: [hybi] Extensibility mechanisms?

[Willy Tarreau <[e-mail]>]

On Thu, Jul 22, 2010 at 12:08:02AM -0700, Adam Barth wrote:
> On Wed, Jul 21, 2010 at 11:49 PM, Willy Tarreau <[e-mail]> wrote:
> > My concern is also that we're becoming too much different from this
> > stylized subset, by introducing special features that nobody cares
> > to qualify possible negative impacts nor means of exploitation. I'd
> > rather stick to something well mastered which shares the same class
> > of possible vulnerabilities and attacks as the other ones targetting
> > the same agents, so that when we spot one and fix it, the issue is
> > fixed for all uses.
> 
> I didn't understand the concrete implications of this paragraph.

I was talking about the blind 8 bytes that must be forwarded. This
proposal was added to the draft without apparently anyone noticing
the impact on the HTTP protocol itself. Each time we try to divert
from working standards, we're risking to fall into traps that were
avoided by those standards.

(...)
> You're describing a defense which we've been calling rigidity.  By
> making the handshake rigid, it's harder to squeeze though some other
> protocol's state machine.  However, you can imagine protocols that are
> vulnerable to a perfectly rigid handshake.  As an example, imagine a
> protocol like gopher where the attacker might be able to control all
> the bytes returned by the server (e.g., because the server accepts
> uploads).

Is it possible to make a gopher server respond with a WS-compatible
handshake to a valid WS request ? I don't know what the gopher protocol
looks like, but that sounds scary since in my opinion, the WS handshake
request should be small and limited enough to limit the risk of such
protocol manipulations, if not prevent them.

> There's value to having other defenses against cross-protocol attacks
> in addition to rigidity.  Just as Greg's nonce isn't magic security
> pixie dust, neither is rigidity.

Yes, I agree. They can at least reduce the probability of success,
rendering them useless in practice.

> > Yes, but as Scott said it, it was a proposal to work on something with
> > a constructive approach. Not everyone is perverted enough to think how
> > a protocol can be abused, and that's why we need a variety of people to
> > work on the same protocol.
> 
> I'm take some offense at being called perverted.

Don't take offense for that, I see it more as a quality that only a few
people have to imagine how apparently reliable systems can be abused :-)

Regards,
Willy