Hi
I have the following situation:
1. A Universal App running in Windows 10 that contains a WebView and SocketListener that listens on port 9000.
2. An HTML5 game that is launched inside the WebView which then does a loopback connection to port 9000 on the same PC to the SocketListener that is listening for the traffic.
3. The SocketListener forwards requests to a server on the back-end and does some man-in-the-middle caching of things, and then responds to the requesting WebView.
In other words, the requesting WebView and the responding SocketListener / Proxy are both inside the SAME application.
Fiddler DOES see the comms leaving the Webview (the initial request anyway), but for some unknown reason it never receives a response from my custom proxy listening and responding on port 9000. It just times out.
I have done the following:
1. Set an exemption for the relevant universal app and confirmed the exemption with the relevant command line tools in Win10.
2. Flushed the Fiddler certificates and re-installed them as per your instructions here:
https://textplain.wordpress.com/2015/10/30/reset-fiddlers-https-certificates/
3. Tried every variant of "localhost" I can come up with including: "localhost.", "fiddler.ipv4", "fiddler.localhost", "machinename" etc. etc.
But to be honest I don't even think this is the issue anyway because Fiddler DOES see the requests from the WebView and log them, it just won't forward them.
4. Checked firewall settings.
I've been trying to sort this out for hours now but I just don't know what else to try here.
I actually had this working a few weeks ago, but now it's stopped working again, and for the life of me I cannot understand why.
I've been through all the online help and suggestions, tried multiple things I've read in various forum posts and articles, and still cannot get it to work.
The thing is, my problem is not the usual "Fiddler doesn't see Localhost traffic". It DOES see localhost traffic, it just seems to be refusing to forward that traffic to port 9000, also on localhost and refuses to talk to that custom proxy of mine listening on port 9000.
Any suggestions ? I'm at a complete loss to understand why this refuses to work.
Allan
4 Answers, 1 is accepted
Rank 1
I should also mention that:
1. If I close Fiddler or stop capturing in Fiddler, my app immediately works and comms between my WebView and my internal proxy on port 9000 works perfectly.
2. The WebView in question is an MS Edge WebView embedded in a Universal App in VS2015.
3. The initial GET request URL sent by the WebView is actually a standard "HTTP" request, not even HTTPS. I just cleared the certificates and recreated them to be sure they weren't affecting anything.
Is it the case that your custom SocketListener does not get any traffic from Fiddler? Or the SocketListener gets the traffic going through Fiddler but then Fiddler never gets the SocketListener responses?
Regards,
Tsviatko Yovtchev
Telerik
Rank 1
Hi
The SocketListener does not receive any traffic from Fiddler at all.
Fiddler receives and logs the intial GET requests from the WebView embedded in the same app, but does not forward that packet to the SocketListener or receive any more packets from the WebView after that (which makes sense in context).
Our security team have also looked at this now to see if there is anything blocking or getting in the way but we have been unable to establish what is going on yet.
At this point my 2 theories are:
1. This is actually a Universal App / WinRT issue where the sandboxing of comms in new Win10 apps means that this kind of traffic cannot be intercepted, at all, ever, because somehow windows is actively preventing comms into that sandbox.
It's a bit odd that comms is allowed to leave the sandbox if that's the case though, so I'm not convinced.
It's almost as if the app is inside a sandbox that has it's own little network stack that does not interact properly with the standard Windows network stack.
2. While working with the security team we picked up some interesting things regarding the way that "localhost" is being resolved on my dev box. It looks as if IPV6 is getting involved and it's resolving localhost to an IPV6 address rather than an IPV4 address.
We manipulated the hosts file and my security expert did various other weird and wonderful things to the network stack on the machine in an attempt to force it to resolve "localhost" to an IPV4 standard address, but nothing we tried solved the Fiddler problem.
As it stands, I still have no solution for this problem and still cannot use Fiddler to inspect packets leaving a Win10 Universal App and looping back into that same app.
Thanks
Allan
IPV6 should not be the problem. Your setup is not that common and hard to reproduce, though. We will do some more research in a similar environment. Please, keep us posted on any further development.
Regards,
Tsviatko Yovtchev
Telerik