How to detect invalid flow in FilterDataProvider?

Question

Created Jan ’22

Replies 5

Boosts 0

Views 1.3k

Participants 2

We have a Content Filter implementation that caches NEFilterSocketFlow instances seen from handleNewFlow(), we do this so that we can update the flow verdict at a later time. For example we allow it to start with but later decide to block it.

However, when we do this we often see errors reported in Console like this when we call the update() function.

Failed to find flow 7ABC4FC7-7031-4C5B-BA4B-F198B4DE344D to update its verdict

But the update() method does not return anything, so we can't know that the flow is no longer valid.

Is there any way to verify a flow is still valid before trying to update the verdict?

Boost

Answer 1

Systems Engineer OP

Apple

Jan ’22

Is there any way to verify a flow is still valid before trying to update the verdict?

Unfortunately no. Could you cache general information about the flow instead so that if you need to revoke a flow later on that you can match it via the flow meta information instead of caching the entire flow? For example, caching flow meta information and then later in one of the provider's lifecycle methods match and revoke the flow?

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

0

Answer 2

muddymurphydog OP

Jan ’22

Matt, Thanks for the response.

For example, caching flow meta information and then later in one of the provider's lifecycle methods match and revoke the flow?

Once we have given an allow verdict, we don't receive further lifecycle callbacks.

The only way I can see to do that would be instead of returning an allow verdict we would need to return a NEFilterNewFlowVerdict.filterDataVerdict(withFilterInbound, filterOutbound) to allow a little data through at a time and decide in handleInboundData() or handleOutboundData() to block or repeat letting a small amount through.

I worry this could be a lot more overhead and add unwanted CPU load.

A secondary question, which might help with "housekeeping" of flows, if we provide a block verdict to a flow is that flow guaranteed to be closed? We could drop it from our cache if we're sure it won't useable again.

Thanks, Dave

0

Answer 3

Systems Engineer OP

Apple

Jan ’22

A secondary question, which might help with "housekeeping" of flows, if we provide a block verdict to a flow is that flow guaranteed to be closed?

It depends on where the dropVerdict comes in at. For example, if it comes in at handleNewFlow, then yes, the flow will be dropped before opened. If it comes in during the connection lifecycle methods, for example handleInboundDataFromFlow and handleOutboundDataFromFlow then the connection will be opened and then dropped.

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

0

Answer 4

muddymurphydog OP

Mar ’22

It depends on where the dropVerdict comes in at. For example, if it comes in at handleNewFlow, then yes, the flow will be dropped before opened. If it comes in during the connection lifecycle methods, for example handleInboundDataFromFlow and handleOutboundDataFromFlow then the connection will be opened and then dropped.

Would this also be true of a call to updateFlow:withVerdict:forDirection: outside of the normal lifecycle methods?

0

Answer 5

Systems Engineer OP

Apple

Mar ’22

updateFlow:withVerdict:forDirection: is used in handleNewFlow to update a previously cached verdict to a new verdict. For the headers, "This function is called by the provider to update the verdict for a flow outside the context of any NEFilterDataProvider callback."

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

0