Re: Credentials and connection pools

 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.


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.
>>
>>
>>
>