Re: [hybi] Draft 13 - a bit too historical about the masking debate

[Alexey Melnikov <[e-mail]>]

Greg Wilkins wrote:

>Draft 13 contains a lot of text about the reasons for masking.   That
>must not have been easy to write and for the most part it reads well.
>However I'm not sure we should go into so much detail about the
>history of the disagreements and the process.  Specifically I think
>the following paragraph:
>
>  To avoid such attacks on deployed intermediaries, the working group
>   decided to adopt a solution that would provably protect against such
>   attacks.  There were many proposed solutions that people argued
>   "should" protect against the above attacks, such as adding in more
>   random data and null bytes to the handshake, starting each frame with
>   a byte that has the first (highest order) bit set such that the data
>   appears to be non-ASCII, and so forth, but in the end none of these
>   solutions were provably secure.  The deployed intermediaries were
>   already not conforming to existing specifications, and given that we
>   can't possibly enumerate all of the ways in which such
>   nonconformities could exhibit themselves and that we cannot
>   exhaustively discover and test each nonconformant intermediary
>   against each possible attack, there was consensus to adopt an
>   approach that did not require people to reason about how
>   nonconformant intermediaries might behave.  Namely, the working group
>   decided to mask all data from the client to the server, so that the
>   remote script (attacker) does not have control over how the data
>   being sent appears on the wire, and thus cannot construct a message
>   that could be mis- interpreted by an intermediary as an HTTP request.
>
>
>could be changed to to something like
>
>  To provably avoid such attacks on deployed intermediaries,  it is not
>  sufficient to prefix application supplied data with framing that is not
>  compliant HTTP, as it is not possible to exhaustively discover and test
>  that each nonconformant intermediary does not skip such non HTTP
>  framing and act incorrectly on the frame payload.  Thus the defence
>  adopted is to mask all data from the client to the server, so that the
>  remote script (attacker) does not have control over how the data being
>  sent appears on the wire, and thus cannot construct a message that
>  could be misinterpreted by an intermediary as an HTTP request.
>
As there seems to be some support for your text, it will appear in the 
next revision.