Re: Authentication and TCP Connection State

On Fri, Oct 3, 2014 at 3:01 PM, Willy Tarreau <w@1wt.eu> wrote:
> On Fri, Oct 03, 2014 at 01:31:15PM -0400, Michael B Allen wrote:
>> On Fri, Oct 3, 2014 at 12:22 PM, Matthew Cox <macox@microsoft.com> wrote:
>> > It doesn't work, but we had a proposal a couple years ago to address this: http://tools.ietf.org/id/draft-montenegro-httpbis-multilegged-auth-01.txt
>>
>> Rats. This is absolutely going to block HTTP/2 in the enterprise. And
>> even after clients are updated (and we're not just talking about
>> browsers), how will the client even know it needs to serialize
>> requests?
>>
>> Only the server knows if authentication is required. I think the
>> server should provide a TCP-level option that makes the server
>> serialize until the first 200 status is reached. I can imagine there
>> are numerous instances where it logically and conceptually should
>> block to the first 20x to "negotiate" something. I suspect it already
>> does (TLS/SSL).
>>
>> This whole "HTTP is stateless" business is just false. HTTP is NOT
>> stateless. Cookies and sessions are hacks to work-around this fact.
>
> No this is wrong. HTTP *is* stateless, it's just that people didn't
> know it and invented a crappy insecure authentication mechanism which
> authenticates the TCP connection instead of the requests. Result:
> anybody behind a proxy can share anyone else's connection, and I guess
> that all subscribers on this WG have already done it at least for fun
> in such enterprises.

I appreciate that someone who gets into an HTTP proxy can possibly
hijack a conventional TCP connection and any identity associated with
it.

But any application that is not largely read-only uses state all over
the place which makes the whole "HTTP is stateless" commandment ring
flat.

But, more important, if the network is assumed to be hostile, isn't
that a job for transport security?

Wouldn't TLS or IPsec or IPv6 thwart this kind of proxy problem?

If yes, HTTP is unecessarily forcing everthing running through it to
effectively compute and send a potentially large encrypted blob with
every single request. That's a drag (literally).

Mike

Received on Friday, 3 October 2014 20:32:20 UTC