Re: [hybi] AES-128-CTR not much safer, but not fast either

[Willy Tarreau <[e-mail]>]

On Mon, Jan 10, 2011 at 10:21:16AM +0800, Thomson, Martin wrote:
> On 2011-01-10 at 11:09:08, Willy Tarreau wrote:
> > willy@pcw:~/c$ time ./aes-128-ctr-get
> > Found the 'GET\n' pattern on the wire after 1608425803 bytes
> 
> You might also find the collected works of Shakespeare in the byte stream had you waited a little longer.

I know, that's just a matter of defining "a little longer", as none of us
will live long enough for that.

>  I'm not sure what you are hoping to prove by searching.

What I'm just showing is that we have the following points :
  1) it was reported by an experiment that some caching intermediaries
     were waiting for an HTTP request after the HTTP handshake was over

  2) it was speculated that some lazy intermediaries might possibly skip
     over whatever they did not understand to resync on an HTTP request
     they understand and execute it, hence the need for masking the
     stream or payload. Please note that no such intermediary has even
     been remotely detected, and that several people here who have
     already been involved with server code expressed that making them
     capable of doing so would be much more difficult than doing the
     right thing and would not even respect the principle of laziness.

  3) it has been suggested that a simple 32-bit XOR was not enough and
     that stronger cryptography was needed, because after a certain
     number of attempts, the server might get the client to send a
     request that such an intermediary can parse.

  4) it was reported that at least one intermediary (Apache) accepts
     an HTTP/0.9 request as simple as "GET\n".

  5) it was shown that whatever algorithm we used to address the third
     point was not enough to cover the second point for the supposedly
     lazy intermediaries from #2 acting like Apache.

So now, we have a choice :
  - either we agree that #2 above is not that much of a risk such that
    we don't need #3 to address it ;

  - or we agree that #2 is still much of a concern, but as #4 is real,
    then #3 is not a valid solution, as was proven with #5, and we
    must use another one.

But right now we're just complicating the protocol and removing some
possibilities of later extensions without addressing the reason why
we did that in the first place.

Thanks,
Willy