Re: TLS Renegotiation and HTTP/2 (#363)

On 3 April 2014 01:59, Yoav Nir <ynir.ietf@gmail.com> wrote:
> I’m wondering if it’s possible to write some sensible text on what to do with the two connections. Suppose a resource is fetched from a server, and the server sends the 401 response. The client opens a new connection, this time with client authentication. So now there are two connections, one authenticated, while the other is not. The triggering resource obviously has to be fetched in the authenticated connection. I suppose we let all in-transit streams conclude normally, but what does the client do with any other resources that it needs. Do they go in the old or new connections? What about pushed resources from the server?  Does the server even know that the two connections are associated?  Probably not (unless there’s some outside mechanism at work such as cookies). Does the client close the original (non-authenticated) connection once the streams are closed?

It's worse than that even.  What happens when you have multiple realms
on the server, each requiring a different client certificate?

But I don't think that it's completely intractable.  As far as I'm
aware, most current HTTP authentication implementations send
subsequent requests with the new credentials.  That means switching
over to the new connection for that origin.

I imagine that if there were multiple realms and certificates, then it
would get properly ugly.  But I can imagine a few solutions that -
while totally suboptimal - wouldn't completely fail.

(Push is a non-issue, since pushes are always associated with an
existing stream.  And presumably a server wouldn't push things a
client isn't authorized to receive...)

Received on Thursday, 3 April 2014 16:59:31 UTC