Open Radar

 
Summary:
When implementing a content filter, the handleNewFlow method of NEFilterControlProvider provides an instance of either NEFilterBrowserFlow or NESocketFilterFlow.

With NEFilterBrowserFlow, the remote hostname can be extracted from the 'url' property.

NEFilterSocketFlow, on the other hand, provides a 'remoteEndpoint' property, which should be a NWHostEndpoint, from which a hostname can be obtained. Instead, the value of 'remoteEndpoint' is an unknown subclass of NWEndpoint.

In fact, trying to print out the 'dynamicType' property of this instance will re-spring the device and potentially send it into an endless re-spring loop, as the content filter is loaded on startup.

Steps to Reproduce:
1. Implement content filtering
2. Configure NEFilterManager by setting 'filterSockets = true'
3. Inside the NEFilterControlProvider or NEFilterDataProvider implementation, override the handleNewFlow method and wait for it to intercept a flow which is an instance of NEFilterSocketFlow.
4. Try casting the 'remoteEndpoint' property to NWHostEndpoint (it will be nil)
5. Try printing out the 'dynamicType' property of 'remoteEndpoint' (it will re-spring the device)

Expected Results:
Expected type of NEFilterSocketFlow.remoteEndpoint is NWHostEndpoint

Actual Results:
Type of NEFilterSocketFlow.remoteEndpoint is an unknown subclass of NWEndpoint from which the hostname cannot be obtained.

This renders the content filtering API virtually useless, except when filtering strictly browser traffic and not app traffic.

UPDATE: 
After inspecting the crash log, it seems like remoteEndpoint is a null pointer.