Quantcast

Credentials and connection pools

classic Classic list List threaded Threaded
36 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Credentials and connection pools

Anne van Kesteren
As I understand things we pick connections to reuse based on an origin and a credentials flag (set/unset). This got a little bit more complicated with HTTP/2 as it's not just an origin A, but also any other "origin" entries in A's certificate, but that's not what I'm after.

What I'd like to understand is the history behind using credentials as a key and what we can do to possibly change it. We now have some features that don't send credentials by default (even same-origin), such as <script type=module> and fetch(), and as a result you get two same-origin HTTP/2 connections. This plays poorly with HTTP/2 push.

A standards-related discussion on this is hosted here: https://github.com/whatwg/fetch/issues/341. (Fetch also defines when connections get reused (though it doesn't define the HTTP/2 certificate bits yet).)

(As an aside, having someone from the networking team watch whatwg/fetch and give feedback would really help that work progress faster. Alternatively, if you give me some GitHub IDs to ping when I get stuck that could work too. Much appreciated.)
_______________________________________________
dev-tech-network mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-network
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Credentials and connection pools

Patrick McManus
The history predates me, I presume it was a well intentioned privacy rule -
but partitioning according to anon/non-anon is rather pointless- the peer
can correlate by address or dns-cookies just as effectively if it wishes
to.. and as you point out this partition is really painful - it has both
performance implications and often leads to hard to explain outcomes.
(fonts interacting with preconnect were a good pain poiint to highlight).
I'd be happy to get rid of the separation and doing so in gecko would be
trivial. (the anon flag is part of the hash key, it would just need to be
removed.)



On Sun, May 7, 2017 at 2:07 AM, Anne van Kesteren <[hidden email]> wrote:

> As I understand things we pick connections to reuse based on an origin and
> a credentials flag (set/unset). This got a little bit more complicated with
> HTTP/2 as it's not just an origin A, but also any other "origin" entries in
> A's certificate, but that's not what I'm after.
>
> What I'd like to understand is the history behind using credentials as a
> key and what we can do to possibly change it. We now have some features
> that don't send credentials by default (even same-origin), such as <script
> type=module> and fetch(), and as a result you get two same-origin HTTP/2
> connections. This plays poorly with HTTP/2 push.
>
> A standards-related discussion on this is hosted here:
> https://github.com/whatwg/fetch/issues/341. (Fetch also defines when
> connections get reused (though it doesn't define the HTTP/2 certificate
> bits yet).)
>
> (As an aside, having someone from the networking team watch whatwg/fetch
> and give feedback would really help that work progress faster.
> Alternatively, if you give me some GitHub IDs to ping when I get stuck that
> could work too. Much appreciated.)
> _______________________________________________
> dev-tech-network mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-tech-network
>
>
_______________________________________________
dev-tech-network mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-network
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Credentials and connection pools

Christian Biesinger-2
Well some authentication mechanisms are per-connection, not per-request
(such as NTLM). Just make sure that this does not get co-mingled with
requests that are supposed to be anonymous.

Christian

On Sun, May 7, 2017 at 2:29 PM Patrick McManus <[hidden email]> wrote:

> The history predates me, I presume it was a well intentioned privacy rule -
> but partitioning according to anon/non-anon is rather pointless- the peer
> can correlate by address or dns-cookies just as effectively if it wishes
> to.. and as you point out this partition is really painful - it has both
> performance implications and often leads to hard to explain outcomes.
> (fonts interacting with preconnect were a good pain poiint to highlight).
> I'd be happy to get rid of the separation and doing so in gecko would be
> trivial. (the anon flag is part of the hash key, it would just need to be
> removed.)
>
>
>
> On Sun, May 7, 2017 at 2:07 AM, Anne van Kesteren <[hidden email]>
> wrote:
>
> > As I understand things we pick connections to reuse based on an origin
> and
> > a credentials flag (set/unset). This got a little bit more complicated
> with
> > HTTP/2 as it's not just an origin A, but also any other "origin" entries
> in
> > A's certificate, but that's not what I'm after.
> >
> > What I'd like to understand is the history behind using credentials as a
> > key and what we can do to possibly change it. We now have some features
> > that don't send credentials by default (even same-origin), such as
> <script
> > type=module> and fetch(), and as a result you get two same-origin HTTP/2
> > connections. This plays poorly with HTTP/2 push.
> >
> > A standards-related discussion on this is hosted here:
> > https://github.com/whatwg/fetch/issues/341. (Fetch also defines when
> > connections get reused (though it doesn't define the HTTP/2 certificate
> > bits yet).)
> >
> > (As an aside, having someone from the networking team watch whatwg/fetch
> > and give feedback would really help that work progress faster.
> > Alternatively, if you give me some GitHub IDs to ping when I get stuck
> that
> > could work too. Much appreciated.)
> > _______________________________________________
> > dev-tech-network mailing list
> > [hidden email]
> > https://lists.mozilla.org/listinfo/dev-tech-network
> >
> >
> _______________________________________________
> dev-tech-network mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-tech-network
>
_______________________________________________
dev-tech-network mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-network
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Credentials and connection pools

Patrick McManus
hi :biesi!

Its a good point, but the hash also has some credential info in it for the
case of ntlm cause you also don't want to mix user a and user b when you
are doing conn based auth. Hopefully that wouldn't need to surface up at
whatwg/w3c level.

-P


On Sun, May 7, 2017 at 2:36 PM, Christian Biesinger <[hidden email]>
wrote:

> Well some authentication mechanisms are per-connection, not per-request
> (such as NTLM). Just make sure that this does not get co-mingled with
> requests that are supposed to be anonymous.
>
> Christian
>
> On Sun, May 7, 2017 at 2:29 PM Patrick McManus <[hidden email]>
> wrote:
>
>> The history predates me, I presume it was a well intentioned privacy rule
>> -
>> but partitioning according to anon/non-anon is rather pointless- the peer
>> can correlate by address or dns-cookies just as effectively if it wishes
>> to.. and as you point out this partition is really painful - it has both
>> performance implications and often leads to hard to explain outcomes.
>> (fonts interacting with preconnect were a good pain poiint to highlight).
>> I'd be happy to get rid of the separation and doing so in gecko would be
>> trivial. (the anon flag is part of the hash key, it would just need to be
>> removed.)
>>
>>
>>
>> On Sun, May 7, 2017 at 2:07 AM, Anne van Kesteren <[hidden email]>
>> wrote:
>>
>> > As I understand things we pick connections to reuse based on an origin
>> and
>> > a credentials flag (set/unset). This got a little bit more complicated
>> with
>> > HTTP/2 as it's not just an origin A, but also any other "origin"
>> entries in
>> > A's certificate, but that's not what I'm after.
>> >
>> > What I'd like to understand is the history behind using credentials as a
>> > key and what we can do to possibly change it. We now have some features
>> > that don't send credentials by default (even same-origin), such as
>> <script
>> > type=module> and fetch(), and as a result you get two same-origin HTTP/2
>> > connections. This plays poorly with HTTP/2 push.
>> >
>> > A standards-related discussion on this is hosted here:
>> > https://github.com/whatwg/fetch/issues/341. (Fetch also defines when
>> > connections get reused (though it doesn't define the HTTP/2 certificate
>> > bits yet).)
>> >
>> > (As an aside, having someone from the networking team watch whatwg/fetch
>> > and give feedback would really help that work progress faster.
>> > Alternatively, if you give me some GitHub IDs to ping when I get stuck
>> that
>> > could work too. Much appreciated.)
>> > _______________________________________________
>> > dev-tech-network mailing list
>> > [hidden email]
>> > https://lists.mozilla.org/listinfo/dev-tech-network
>> >
>> >
>> _______________________________________________
>> dev-tech-network mailing list
>> [hidden email]
>> https://lists.mozilla.org/listinfo/dev-tech-network
>>
>
_______________________________________________
dev-tech-network mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-network
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Credentials and connection pools

Anne van Kesteren
In reply to this post by Christian Biesinger-2
On Sunday, May 7, 2017 at 8:54:54 PM UTC+2, Patrick McManus wrote:
> Its a good point, but the hash also has some credential info in it for the
> case of ntlm cause you also don't want to mix user a and user b when you
> are doing conn based auth. Hopefully that wouldn't need to surface up at
> whatwg/w3c level.

So I don't know how these connection-level authentication mechanisms work in detail, but they came up in the issue as well, and might well have been the motivator for the credentials flag. If we don't want those to be used on connections that also carry requests without credentials, how do we go about that?

Can these authentication mechanisms be negotiated after the connection is opened? Can the client easily refuse? Can the server assert it won't ever start such a negotiation?

(Having statistics on how often these mechanisms are used would also be interesting, though I suspect we can't do much about it given intranet deployments and such.)

FWIW, I suspect Fetch will need to keep some handle on how to allocate connections, just to deal with WebSocket, error handling, the upcoming token binding integration, and features like preconnect.
_______________________________________________
dev-tech-network mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-network
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Credentials and connection pools

Patrick McManus
an authenticated connection is the moral equivalent of having credentials
on every request on that conn.. so its non-sensical to have an anonymous
request on a authenticated connection. (so yes, if its anonymous it would
need to be on a non authenticated connection.. I'm not sure fetch needs to
say that - its sufficient to define an anonymous request as lacking
credentials I would think)

but that doesn't mean we need to ban the mingling of authenticated and non
authenticated on the same connection when we aren't using connection based
auth (which is approximately all the time outside some enterprise cases).




On Sun, May 7, 2017 at 3:33 PM, Anne van Kesteren <[hidden email]> wrote:

> On Sunday, May 7, 2017 at 8:54:54 PM UTC+2, Patrick McManus wrote:
> > Its a good point, but the hash also has some credential info in it for
> the
> > case of ntlm cause you also don't want to mix user a and user b when you
> > are doing conn based auth. Hopefully that wouldn't need to surface up at
> > whatwg/w3c level.
>
> So I don't know how these connection-level authentication mechanisms work
> in detail, but they came up in the issue as well, and might well have been
> the motivator for the credentials flag. If we don't want those to be used
> on connections that also carry requests without credentials, how do we go
> about that?
>
> Can these authentication mechanisms be negotiated after the connection is
> opened?


yes.. typically triggered by a subset of resources on the server


> Can the client easily refuse?


same process as other http based auth. I'm not sure I'd call that 'easy' -
but there ya go


> Can the server assert it won't ever start such a negotiation?
>

no.. (at least not that I know of)


> (Having statistics on how often these mechanisms are used would also be
> interesting, though I suspect we can't do much about it given intranet
> deployments and such.)
>
>
very enterprisey. Most of it is actually used to authenticate to proxies,
which isn't a consideration here, but there are a few cases of endpoints
doing windows auth.



> FWIW, I suspect Fetch will need to keep some handle on how to allocate
> connections, just to deal with WebSocket, error handling, the upcoming
> token binding integration, and features like preconnect.
> _______________________________________________
> dev-tech-network mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-tech-network
>
>
_______________________________________________
dev-tech-network mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-network
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Credentials and connection pools

Eric Rescorla
On Sun, May 7, 2017 at 1:12 PM, Patrick McManus <[hidden email]>
wrote:

> an authenticated connection is the moral equivalent of having credentials
> on every request on that conn.. so its non-sensical to have an anonymous
> request on a authenticated connection. (so yes, if its anonymous it would
> need to be on a non authenticated connection.. I'm not sure fetch needs to
> say that - its sufficient to define an anonymous request as lacking
> credentials I would think)
>
> but that doesn't mean we need to ban the mingling of authenticated and non
> authenticated on the same connection when we aren't using connection based
> auth (which is approximately all the time outside some enterprise cases).


Hmm... What about when you have post-handshake auth that retroactively
blesses requests that should have been anonymous?

-Ekr


>
>
>
> On Sun, May 7, 2017 at 3:33 PM, Anne van Kesteren <[hidden email]>
> wrote:
>
> > On Sunday, May 7, 2017 at 8:54:54 PM UTC+2, Patrick McManus wrote:
> > > Its a good point, but the hash also has some credential info in it for
> > the
> > > case of ntlm cause you also don't want to mix user a and user b when
> you
> > > are doing conn based auth. Hopefully that wouldn't need to surface up
> at
> > > whatwg/w3c level.
> >
> > So I don't know how these connection-level authentication mechanisms work
> > in detail, but they came up in the issue as well, and might well have
> been
> > the motivator for the credentials flag. If we don't want those to be used
> > on connections that also carry requests without credentials, how do we go
> > about that?
> >
> > Can these authentication mechanisms be negotiated after the connection is
> > opened?
>
>
> yes.. typically triggered by a subset of resources on the server
>
>
> > Can the client easily refuse?
>
>
> same process as other http based auth. I'm not sure I'd call that 'easy' -
> but there ya go
>
>
> > Can the server assert it won't ever start such a negotiation?
> >
>
> no.. (at least not that I know of)
>
>
> > (Having statistics on how often these mechanisms are used would also be
> > interesting, though I suspect we can't do much about it given intranet
> > deployments and such.)
> >
> >
> very enterprisey. Most of it is actually used to authenticate to proxies,
> which isn't a consideration here, but there are a few cases of endpoints
> doing windows auth.
>
>
>
> > FWIW, I suspect Fetch will need to keep some handle on how to allocate
> > connections, just to deal with WebSocket, error handling, the upcoming
> > token binding integration, and features like preconnect.
> > _______________________________________________
> > dev-tech-network mailing list
> > [hidden email]
> > https://lists.mozilla.org/listinfo/dev-tech-network
> >
> >
> _______________________________________________
> dev-tech-network mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-tech-network
>
_______________________________________________
dev-tech-network mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-network
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Credentials and connection pools

Patrick McManus
On Sun, May 7, 2017 at 4:44 PM, Eric Rescorla <[hidden email]> 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. 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
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-network
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Credentials and connection pools

Eric Rescorla
On Sun, May 7, 2017 at 2:06 PM, Patrick McManus <[hidden email]>
wrote:

>
> On Sun, May 7, 2017 at 4:44 PM, Eric Rescorla <[hidden email]> 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
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-network
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Credentials and connection pools

Patrick McManus
 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 <[hidden email]> wrote:

>
>
> On Sun, May 7, 2017 at 2:06 PM, Patrick McManus <[hidden email]>
> wrote:
>
>>
>> On Sun, May 7, 2017 at 4:44 PM, Eric Rescorla <[hidden email]> 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
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-network
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Credentials and connection pools

Eric Rescorla
On Sun, May 7, 2017 at 2:46 PM, Patrick McManus <[hidden email]>
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.

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?

-Ekr


> On Sun, May 7, 2017 at 5:34 PM, Eric Rescorla <[hidden email]> wrote:
>
>>
>>
>> On Sun, May 7, 2017 at 2:06 PM, Patrick McManus <[hidden email]>
>> wrote:
>>
>>>
>>> On Sun, May 7, 2017 at 4:44 PM, Eric Rescorla <[hidden email]> 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
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-network
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Credentials and connection pools

Patrick McManus
On Sun, May 7, 2017 at 5:51 PM, Eric Rescorla <[hidden email]> wrote:

>
>
> On Sun, May 7, 2017 at 2:46 PM, Patrick McManus <[hidden email]>
> 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.


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


> -Ekr
>
>
>> On Sun, May 7, 2017 at 5:34 PM, Eric Rescorla <[hidden email]> wrote:
>>
>>>
>>>
>>> On Sun, May 7, 2017 at 2:06 PM, Patrick McManus <[hidden email]>
>>> wrote:
>>>
>>>>
>>>> On Sun, May 7, 2017 at 4:44 PM, Eric Rescorla <[hidden email]> 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
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-network
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Credentials and connection pools

Eric Rescorla
On Sun, May 7, 2017 at 3:01 PM, Patrick McManus <[hidden email]>
wrote:

>
>
> On Sun, May 7, 2017 at 5:51 PM, Eric Rescorla <[hidden email]> wrote:
>
>>
>>
>> On Sun, May 7, 2017 at 2:46 PM, Patrick McManus <[hidden email]>
>> 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 <[hidden email]> wrote:
>>>
>>>>
>>>>
>>>> On Sun, May 7, 2017 at 2:06 PM, Patrick McManus <[hidden email]>
>>>> wrote:
>>>>
>>>>>
>>>>> On Sun, May 7, 2017 at 4:44 PM, Eric Rescorla <[hidden email]> 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
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-network
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Credentials and connection pools

Patrick McManus
On Sun, May 7, 2017 at 6:13 PM, Eric Rescorla <[hidden email]> wrote:

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

req N ->
              <- resp (200) N
:: N is done and gone - in caches and spread far and wide ::
req A ->
              <- HR
close conn and fail A I suppose

or are you thinking of some scenario where N and A are both outstanding
with no replies? We don't have such a scenario right now (pipelines are
dead, and you can't do this in h2, how else would it happen?), but if we
did I would agree you would need to treat it as a reset and replay them on
different conns until you figured out what the HR applied to. So whatever
the h2 extension is that makes something like this happen should take that
into account - but we've gotten a bit afield from the original question,


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

I trolling just a tad with the cookie line - cause its the 99.9% use case
here. If we had reason to think that traditional auth was broken I guess we
could design around that - but I haven't seen a case of that.
_______________________________________________
dev-tech-network mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-network
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Credentials and connection pools

Eric Rescorla
On Sun, May 7, 2017 at 3:31 PM, Patrick McManus <[hidden email]>
wrote:

>
> On Sun, May 7, 2017 at 6:13 PM, Eric Rescorla <[hidden email]> wrote:
>
>>
>> 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.
>>
>
> req N ->
>               <- resp (200) N
> :: N is done and gone - in caches and spread far and wide ::
> req A ->
>               <- HR
> close conn and fail A I suppose
>
> or are you thinking of some scenario where N and A are both outstanding
> with no replies? We don't have such a scenario right now (pipelines are
> dead, and you can't do this in h2, how else would it happen?),
>

I was thinking of pipelining, but why would you fail A, rather than
treating it as connection
termination and restarting?

-Ekr


but if we did I would agree you would need to treat it as a reset and

> replay them on different conns until you figured out what the HR applied
> to. So whatever the h2 extension is that makes something like this happen
> should take that into account - but we've gotten a bit afield from the
> original question,
>
>
>>
>> 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.
>>
>
> I trolling just a tad with the cookie line - cause its the 99.9% use case
> here. If we had reason to think that traditional auth was broken I guess we
> could design around that - but I haven't seen a case of that.
>
>
>
_______________________________________________
dev-tech-network mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-network
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Credentials and connection pools

Patrick McManus
On Sun, May 7, 2017 at 6:42 PM, Eric Rescorla <[hidden email]> wrote:

> I was thinking of pipelining, but why would you fail A, rather than
> treating it as connection
> termination and restarting?
>

pipelines are dead for all practical purposes (removed from firefox, not
available in chrome or msft iirc)..They never really worked, were not
widely deployed, and h2 is the right answer to the same question. Now that
h2 is widely available, there is no reason to entertain the pipeline
fantasy. So I really can't see where >1 outstanding transaction can
happen.. and my 'fail' comment was in that context - what good does
replaying the same transaction on a new connection get you.. what's
different (the conflicting property is part of the request)?  if you had an
ambiguity about the HR, then retry makes sense..

Tommy Pauly from Apple did a interesting TAPS presentation at IETF 98 where
he had a slide lableed multi-streaming and listed H1 pipelines under it. It
was an interesting characterization... and for the same reason h2 doesn't
cope with post handshake auth pipelines really should not either - though I
cannot recall it ever being discussed.. that might be because pipelines
weren't much of a thing in practice.

-P
_______________________________________________
dev-tech-network mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-network
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Credentials and connection pools

Anne van Kesteren
In reply to this post by Anne van Kesteren
On Sunday, May 7, 2017 at 10:12:20 PM UTC+2, Patrick McManus wrote:
> an authenticated connection is the moral equivalent of having credentials
> on every request on that conn.. so its non-sensical to have an anonymous
> request on a authenticated connection. (so yes, if its anonymous it would
> need to be on a non authenticated connection.. I'm not sure fetch needs to
> say that - its sufficient to define an anonymous request as lacking
> credentials I would think)

How is that sufficient? How does Servo derive an implementation strategy from that that's not different from that of other browsers in ways that can be observed by web sites?


> but that doesn't mean we need to ban the mingling of authenticated and non
> authenticated on the same connection when we aren't using connection based
> auth (which is approximately all the time outside some enterprise cases).

Sure, then the question becomes what the new policy would be.


Let me try a description of the new model to see if we're on the same page. The connection pool which holds all connections is global for the user agent. A connection is keyed in part on a set of (domain, port) tuples, one of which needs to match.

A connection can become authenticated. This can happen at any point for the duration of the connection, except when the connection is anonymous-request-tainted.

A connection can become anonymous-request-tainted when you send an anonymous request over it. If a connection is authenticated the client won't send an anonymous request over it and instead open a new connection.

When a connection is anonymous-request-tainted and the server tries to authenticate the connection, the client fails that process. This would be a potentially breaking change.

So basically, authenticated and anonymous-request-tainted would be mutually exclusive and also part of the connection key.

(With such a setup, there's probably not much advantage to TLS extensions surrounding connection authentication. (I was thinking that if the server could assert it would never use it, we could only coalesce then (and fail later on if the server lied). Alternatively the client could assert it would never need it.)
_______________________________________________
dev-tech-network mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-network
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Credentials and connection pools

Eric Rescorla
On Mon, May 8, 2017 at 12:36 AM, Anne van Kesteren <[hidden email]> wrote:

> On Sunday, May 7, 2017 at 10:12:20 PM UTC+2, Patrick McManus wrote:
> > an authenticated connection is the moral equivalent of having credentials
> > on every request on that conn.. so its non-sensical to have an anonymous
> > request on a authenticated connection. (so yes, if its anonymous it would
> > need to be on a non authenticated connection.. I'm not sure fetch needs
> to
> > say that - its sufficient to define an anonymous request as lacking
> > credentials I would think)
>
> How is that sufficient? How does Servo derive an implementation strategy
> from that that's not different from that of other browsers in ways that can
> be observed by web sites?
>

Way is this an imperative? I should think the requirement was merely that
it not break Web sites.



> > but that doesn't mean we need to ban the mingling of authenticated and
> non
> > authenticated on the same connection when we aren't using connection
> based
> > auth (which is approximately all the time outside some enterprise cases).
>
> Sure, then the question becomes what the new policy would be.
>
>
> Let me try a description of the new model to see if we're on the same
> page. The connection pool which holds all connections is global for the
> user agent. A connection is keyed in part on a set of (domain, port)
> tuples, one of which needs to match.
>

Nit: scheme/host/port


A connection can become authenticated. This can happen at any point for the

> duration of the connection, except when the connection is
> anonymous-request-tainted.
>
> A connection can become anonymous-request-tainted when you send an
> anonymous request over it. If a connection is authenticated the client
> won't send an anonymous request over it and instead open a new connection.
>
> When a connection is anonymous-request-tainted and the server tries to
> authenticate the connection, the client fails that process. This would be a
> potentially breaking change.
>

I know that this is what McManus was suggesting, but if you mean that fail
causes the fetch to fail, that seems unnecessary. We could just simulate
network error and retry on a different, non-tainted, connection I should
think.

So basically, authenticated and anonymous-request-tainted would be mutually
> exclusive and also part of the connection key.
>
> (With such a setup, there's probably not much advantage to TLS extensions
> surrounding connection authentication. (I was thinking that if the server
> could assert it would never use it, we could only coalesce then (and fail
> later on if the server lied). Alternatively the client could assert it
> would never need it.)
>

This seems like something that would have an incredibly long deployment
curve.

-Ekr

_______________________________________________
> dev-tech-network mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-tech-network
>
_______________________________________________
dev-tech-network mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-network
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Credentials and connection pools

Anne van Kesteren
On Mon, May 8, 2017 at 1:52 PM, Eric Rescorla <[hidden email]> wrote:
> On Mon, May 8, 2017 at 12:36 AM, Anne van Kesteren <[hidden email]> wrote:
>> How is that sufficient? How does Servo derive an implementation strategy
>> from that that's not different from that of other browsers in ways that can
>> be observed by web sites?
>
> Way is this an imperative? I should think the requirement was merely that it
> not break Web sites.

And if that requirement is to remain true, we should document what
sites can come to depend upon. And likely will depend on given how
HTTP/2 push works. Part of the reason I'm raising this is because
folks are running into issues with the current model. If we change the
model but don't make sure that all browsers adopt it, developers will
still end up running into issues.


> Nit: scheme/host/port

Oops, bit optimistic there.


>> When a connection is anonymous-request-tainted and the server tries to
>> authenticate the connection, the client fails that process. This would be a
>> potentially breaking change.
>
> I know that this is what McManus was suggesting, but if you mean that fail
> causes the fetch to fail, that seems unnecessary. We could just simulate
> network error and retry on a different, non-tainted, connection I should
> think.

We cannot always retry. E.g., with fetch() using streams the user
agent cannot reproduce the body (by design, to use less memory;
therefore also fails on most redirects and HTTP authentication).


>> (With such a setup, there's probably not much advantage to TLS extensions
>> surrounding connection authentication. (I was thinking that if the server
>> could assert it would never use it, we could only coalesce then (and fail
>> later on if the server lied). Alternatively the client could assert it would
>> never need it.)
>
> This seems like something that would have an incredibly long deployment
> curve.

Yeah, I suspected as much. Happy that we have alternatives to consider.


--
https://annevankesteren.nl/
_______________________________________________
dev-tech-network mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-network
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Credentials and connection pools

Patrick McManus
In reply to this post by Anne van Kesteren
On Mon, May 8, 2017 at 3:36 AM, Anne van Kesteren <[hidden email]> wrote:

> A connection can become anonymous-request-tainted when you send an
> anonymous request over it. If a connection is authenticated the client
> won't send an anonymous request over it and instead open a new connection.
>

In at least the common case, cookies, there is just no need for this rule
and it leads to most of the confusion we have. The connection can easily
mix cookies and no-cookies.
_______________________________________________
dev-tech-network mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-network
12
Loading...