Re: Client Certificates - re-opening discussion

[Yoav Nir <[e-mail]>]

> On Sep 21, 2015, at 3:22 PM, Kyle Rose <[e-mail]> wrote:
> 
>> Having the application layer stall doesn’t help. The client requests
>> resources A, B, and C. Resource B requires client authentication. By the
>> time the application stalls, waiting for the client authentication,
>> resources A and C may not have been noticed, or the requests may have been
>> serviced, with A and C in a buffer waiting to be encrypted, or the requests
>> may have been serviced and encrypted and on the way back to the client. A
>> and C may be received in the authenticated or the non-authenticated context.
>> Imagine, for example, that A is a bit of HTML that says “Hello, guest” in
>> the unauthenticated context, or “Hello, Mike” after authentication. You can
>> get the certificate picker and still see the “Hello, guest” on the page.
>> 
>> What’s more, I think HTTP authentication has the same issue. If one request
>> gets processed and generates a 401 with WWW-Authenticate, other resources
>> may or may not have been serviced. You can fix this by carefully designing
>> the application so that you don’t load resources that are different based on
>> state at the same time as the authentication is going on.
>> 
>> If multiple requests cause the server application to query the HTTP layer
>> for the client’s certificate, then all those requests will wait until the
>> client authentication has completed, just as they would have on a
>> non-multiplexed connection.  Where multiplexing adds a new wrinkle is that,
>> under HTTP/1.1, those connections that didn’t require authentication would
>> proceed without interruption until they’re used for a protected request.
> 
> How did this work in practice with HTTP/1.1, with browsers having
> multiple simultaneous connections open to the same server?
> 
> If I had to guess, I'd say that the primary resource requiring
> authentication was typically the root HTML for a page, which would
> then of course stall every subsequent request for subresources without
> any specific support required in the client: neither multiplexing H2
> nor simultaneous HTTP/1.1 connections would be subject to a race
> condition in this case, requests for the URLs from previously-loaded
> pages that vary on authentication notwithstanding.

Of course that’s how sane people built the web sites. If fact only the root HTML of some page (that you reached by clicking a button that said “Log in with a Certificate”) triggered renegotiation. After renegotiation on one particular connection, the server would plant a COOKIE, which would “bless” all the other connections.

The difference is that now the sane design is mandatory, else you get unpredictable results. A sane design works with renegotiation, #209 and HTTP-layer authentication.

Yoav