On Sun, May 7, 2017 at 3:01 PM, Patrick McManus <[email protected]> wrote:
> > > On Sun, May 7, 2017 at 5:51 PM, Eric Rescorla <[email protected]> wrote: > >> >> >> On Sun, May 7, 2017 at 2:46 PM, Patrick McManus <[email protected]> >> wrote: >> >>> This is probably particular to TLS, as the windows auth stuff does >>> apply more like http basic auth (it returns 401 to bootstrap things, rather >>> than making a challenge at the session layer with a request in flight) >>> >>> wrt tls client auth I would think if the outstanding requests is marked >>> anonymous we should not allow authentication to proceed if the server sends >>> a helloRequest (and I have no idea whether we apply that check now or not - >>> that code hasn't changed in forever) just because that's a nonsenica >>> combinationl, right? Again, seems like we can handle that as an >>> implementation issue without drawing a bright line for 99% of the world >>> that doesn't do connection based client auth and creating a burden on >>> webdevs to get this junk right in markup. >>> >> >> I think you'd have to handle this by actually tearing down the connection >> and re-initiating on another >> one. >> > > by handle it I figured that meant fail the one in flight.. why would the > server do something different on a new connection? The server demands auth, > the request is marked anonymous - that's not going to work out. > Sorry, I should have expressed my concern differently. Say that we decide to allow coalescence and then we have two requests: A (anonymous) N (non-anonymous) So, what happens if from the client's perspective we have N, A, HR. At this point we need to re-issue N on a new connection so it doesn't contaminate A. We may actually need to tear down the connection and start two new ones, one with N and one with A. That said, I'm also worried that there are misguided servers which bind >> HTTP-level authentication >> to the TLS connection. Those servers are going to have a bad day if we >> coalesce... Do we know >> that there aren't any? >> >> > 'any' is not a standard the web can ever meet :). You're concerned that > cookies on transaction 1 will be implicitly applied to transaction 2 even > though 2 doesn't have cookies? That would be a pretty big bug I think we > would have already seen - but that's basically what the change would boil > down to. > Not just cookies. Say, for instance, usernames and passwords. Maybe it doesn't happen. -Ekr > >> -Ekr >> >> >>> On Sun, May 7, 2017 at 5:34 PM, Eric Rescorla <[email protected]> wrote: >>> >>>> >>>> >>>> On Sun, May 7, 2017 at 2:06 PM, Patrick McManus <[email protected]> >>>> wrote: >>>> >>>>> >>>>> On Sun, May 7, 2017 at 4:44 PM, Eric Rescorla <[email protected]> wrote: >>>>> >>>>>> >>>>>> Hmm... What about when you have post-handshake auth that retroactively >>>>>> blesses requests that should have been anonymous? >>>>>> >>>>> >>>>> >>>>> TLS client auth doesn't retroactively apply. >>>>> >>>> >>>> Not sure I agree here. One of the standard idioms is that the server >>>> receivesn >>>> a a sensitive request, then sends HelloRequest, and then when the >>>> handshake >>>> completes, delivers the response.I would call that retroactive >>>> >>>> -Ekr >>>> >>>> >>>> >>>> >>>>> so yeah, when I said every request on that conn I should have said >>>>> every request on that conn while it is authenticated (and it can change >>>>> and >>>>> whatnot, not trying to write a taxonomy here.). windows auth has a similar >>>>> property that it starts with an unauthenticated connection and a http >>>>> response at any point could choose to start the authentication dance - but >>>>> it doesn't apply backwards. You can see why the mulitplexing of h2 booted >>>>> all this stuff off the island. >>>>> >>>>> >>>>> >>>> >>> >> > _______________________________________________ dev-tech-network mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-network
