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

[Willy Tarreau <[e-mail]>]

I have reused Maciej's code for AES-128-CTR to make it emit a constant
stream and look there for a supposedly processable request (which is
valid since Apache processes it and transcodes it if it finds it at
the beginning of the stream).

willy@pcw:~/c$ time ./aes-128-ctr-get 
Found the 'GET\n' pattern on the wire after 1608425803 bytes

real    0m20.761s
user    0m20.761s
sys     0m0.000s

It requires the client to send more data, but here we're only
at 1.6 GB, roughly just 1000 times more than with the basic XOR
method.

However, it's limited to 640 Mbps only. It means that using this
as a mandatory masking method will not even allow me to use a
memcache at gigabit speeds on my local network :-(

Once again, I'm not saying that I'd believe that any intermediary
would seek a request that far. Neither do I believe it would seek
one after one megabyte nor after any non CRLF byte BTW.

But we're proposing this method because other ones are not deemed
sure enough. However, it does not either cover the issues which
caused the other methods to be proposed.

So now either we should conclude that using AES to prevent a request
from popping up is acceptable because the risks are low, so it must
be possible to disable it for some use cases, or we conclude that
it's not usable and the only masking solution consists in never
putting a CR/LF on the wire.

But we have to make choices. We can't disable the protocol that way
to fix a problem we finally don't fix.

Regards,
Willy