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.
>>
>>
>>
>
_______________________________________________
dev-tech-network mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-network

Reply via email to