- From: Stefan Eissing <stefan.eissing@greenbytes.de>
- Date: Mon, 21 Sep 2015 15:19:27 +0200
- To: Yoav Nir <ynir.ietf@gmail.com>
- Cc: Kyle Rose <krose@krose.org>, Mike Bishop <Michael.Bishop@microsoft.com>, Eric Rescorla <ekr@rtfm.com>, Ilari Liusvaara <ilari.liusvaara@elisanet.fi>, Mark Nottingham <mnot@mnot.net>, Henry Story <henry.story@co-operating.systems>, HTTP Working Group <ietf-http-wg@w3.org>
> Am 21.09.2015 um 15:04 schrieb Yoav Nir <ynir.ietf@gmail.com>: > >> >> On Sep 21, 2015, at 3:22 PM, Kyle Rose <krose@krose.org> wrote: >> [...] >> >> 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 Not even then. Client may reuse connections on matching certs. There are installations out there that have a cert for +3 domain names, lets say A, B and C. A has anonymous access, B and C both require different client certs. Depending on which tab the browser load first, the one or the other cert gets loaded in, leading the other site to fail since the cert is not accepted. The only approach available seems, inside the server, to check when renegotiation is triggered by a request: is the authority the same as in the SNI for this connection? If not, return a 421. But that overloads 421, which is not trivial to implement correctly and efficient in the client. Maybe client developers can add some wisdom to this discussion. As to the approach: "there is no problem, since renegotiation is forbidden in http/2!" Well. I can tell people to disable h2 if they have client certificates, sure. But I would prefer enabling http/2 and give clients a return code when they need a new connection, maybe even indicating the base URL *path* for that connection. //Stefan <green/>bytes GmbH Hafenweg 16, 48155 Münster, Germany Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
Received on Monday, 21 September 2015 13:19:53 UTC