Re: [hybi] Masking only Payload/Extension Data

[Ian Fette (イアンフェッティ) <[e-mail]>]

That said, looking at the wiki again, I am not really sure I understand the
benefits that intermediaries would get from this. Either way it looks like
they need to be able to pick out frame boundaries, and to do that reliably I
think they have to read frame header 1, see how long that frame is, and
basically skip that many bytes to get to frame 2. I don't understand how
they could do it without parsing the frame header for frame 1. The masking
doesn't make it that difficult to get to the frame header, you have to xor
on the order of 10 bytes. A lot of the complexity savings seem predicated on
the thought that we may choose a different, stream-based masking algorithm,
which I thought we already decided against because of some of those exact
issues?

Again, I'm not against it, but I don't really see enough benefit to say I'm
for it either.

-Ian

2011/3/10 Ian Fette (イアンフェッティ) <[e-mail]>

> The attacker is relatively free to select the length of the message, but
> that may or may not translate into the length of a given frame. For
> instance, a browser may decide to fragment a large message. Looking at the
> base framing, the attacker can also choose between a text and binary frame.
> In practice, I would be surprised if the attacker had control over more than
> seventeen bits coming from a browser. We (the browser at its discretion)
> could also choose to e.g. fragment a message if it saw a length equal to
> "GET\n" or "POST" or any number of such keywords, though I admit that it is
> no sure fire defense against potential attacks.
>
> At the end of the day, I think you are right in saying that it does open up
> additional attack surface and potential. The question is how plausible do we
> believe such an attack to be, what is the potential damage, and what do we
> gain in exchange? The handshake in theory means that we're looking at
> attacks against ill-formed proxies as the primary attack target/vector. We
> can argue about whether these are likely to grow in number or shrink in
> number, but at the end of the day it is a relatively small number of
> endpoints that are already exploitable via other means as you demonstrated.
> I am willing to live with masking, but at some point I do think we need to
> look at it as a cost benefit analysis, and not be willing to afford infinite
> cost to the "proxies may get exploited" line of reasoning. I don't mean to
> dismiss the issue by any means, but merely to say that there is a limit to
> how much we should accomodate these things.
>
> -Ian (hopefully that's a sufficiently cryptic response to maintain my
> previously stated neutral stance)
>
> On Thu, Mar 10, 2011 at 3:30 AM, Adam Barth <[e-mail]> wrote:
>
>> Thanks for having an open mind Joel.  Let's start with some basic
>> assumptions:
>>
>> 1) Attacks only get better over time.  Over the (hopefully) many years
>> folks will be using this protocol, the attacks we know about today
>> will continue to exist, and security researchers will continue to
>> learn more techniques and improve their attacks.  That means we should
>> design protocols with a margin of safety rather than pushing up
>> against the razor edge of what we can reliably exploit today.
>> Admitted, this aspect of security is somewhat of an art, and at some
>> point we'll need to defer to the judgement of security experts as to
>> how much of a margin we need for safety.
>>
>> 2) If an attacker can choose a moderately long sequence of bytes of
>> the wire, we lose.  More specifically, we can construct attacks today
>> that abuse certain configurations of proxies using a moderate length
>> of chosen bytes.  Because of (1), we should expect the length of these
>> sequences and the amount of damage attacker can cause with them to
>> increase over time.  The story would be different if we had some solid
>> reasoning about lower bounds on length or upper bounds on damage, but
>> we don't.
>>
>> For simplicity, let's consider the base framing protocol:
>>
>>
>> http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-06#section-4.3
>>
>> Let's assume we're only going to mask the extension data and the
>> application data.  That leds approximately 10 bytes at the beginning
>> of the frame that's unmasked.  Are these bytes under the control of
>> the attacker?  In large part, they are.  For example, the attacker is
>> relatively free to select the payload length.  The attacker is also
>> likely to have a large amount of control over the opcode (recall that
>> the attacker can drive the protocol state machine into relatively
>> arbitrary states).  As for the various reserved bits, we don't know
>> very much about how these bits will be used, but if they're likely to
>> be at least partially under the influence of the attacker.
>>
>> Worse, consider the case where the attacker sends a sequence of very
>> short (e.g., zero or one byte) messages.  Now the attacker can control
>> (or can strongly influence) an appreciable fraction of the bytes on
>> the wire.  Additionally, the attacker gets feedback (i.e., by seeing
>> the bytes that arrive at the server) and can dynamically adjust
>> subsequent messages based on this feedback.
>>
>> So, does the above add up to an attack I can demonstrate today?  No.
>> Is there reasonable evidence that attackers will be able to stich
>> together the above weaknesses to construct an attack in the future?
>> Yes.  Given what we know today, my view is that not masking the entire
>> frame is an unacceptable level of risk.
>>
>> Adam
>>
>>
>> On Thu, Mar 10, 2011 at 3:05 AM, Joel Martin <[e-mail]>
>> wrote:
>> > I've been following this discussion pretty closely and I'm willing to
>> change
>> > my mind if Adam (or somebody else) can clearly lay out a threat model
>> that
>> > isn't easily addressed by minor tweaking. I really am interested in what
>> > real threat may exist and not just being stubborn. Please enlighten me.
>> > As somebody else has proposed, the allowable range of values in the
>> length
>> > field can always be reduced in the future by fragmenting to avoid
>> _specific_
>> > known vulnerable intermediaries (in the implementations without even
>> > changing the protocol). I.e. if "GET\n" is a problem, then client
>> > implementations can just never send that value.
>> > I suspect most would agree that masking of everything is better than
>> > stalling the protocol any longer, but if Adam is the only objector and
>> the
>> > browser folks are okay with masking only payload then perhaps we should
>> move
>> > forward with it.
>> > Joel Martin (kanaka)
>> > On Thu, Mar 10, 2011 at 1:39 PM, Willy Tarreau <[e-mail]> wrote:
>> >>
>> >> On Thu, Mar 10, 2011 at 02:25:28AM -0800, Brian wrote:
>> >> > By my count, we have six voices in favor so far, including myself:
>> >> > Andy Green
>> >> > Ytaka Takeda
>> >> > Greg Wilkins
>> >> > Willy Tarreau
>> >> > Joel Martin
>> >> > Brian McKelvey
>> >> >
>> >> > One on record as not having a strong opinion one way or the other:
>> >> > Ian Fette
>> >> >
>> >> > And one opposed:
>> >> > Adam Barth
>> >> >
>> >> >
>> >> > Adam's curt and patronizing reply is once again unenlightening as to
>> >> > any viable reason why we need to mask the frame header as well as the
>> >> > payload, beyond just his gut feeling on the matter.  I'd like to
>> >> > re-assert that since the only field under a potential hacker's
>> control
>> >> > is the length (and potentially rsv bits via undefined extensions in
>> >> > the future) that the practical possibility of the frame header being
>> >> > used for an attack that actually accomplishes anything is so remote
>> >> > it's utterly laughable.
>> >>
>> >> I'd like to add that it's important to remember that this controllable
>> >> length is not even at the beginning of the frame, and that there are
>> >> uncontrollable bytes before.
>> >>
>> >> Regards,
>> >> Willy
>> >>
>> >> _______________________________________________
>> >> hybi mailing list
>> >> [e-mail]
>> >> https://www.ietf.org/mailman/listinfo/hybi
>> >
>> >
>> > _______________________________________________
>> > hybi mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/hybi
>> >
>> >
>> _______________________________________________
>> hybi mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/hybi
>>
>
>