FiddlerCore having issues decrypting HTTPS on Windows Server 2012 R2

[Kevin Layfield]

Our company has a .NET 3.5 project utilizing FiddlerCore that we have traditionally run on Windows Server 2008.  We recently attempted to port everything over to Server 2012 R2 but have hit a bit of a snag when our software attempts to access web pages using HTTPS.  

The error occurs in our handler for Fiddler.FiddlerApplication.OnReadResponseBuffer when trying to access oS.oRequest.pipeClient.  The pipeClient is not set to an instance of an object when we attempt to interact with it.

We were using FiddlerCore.dll version 2.4.4.8 when we tried porting the project over, but we have also tried FiddlerCore3Dot5.dll version 3.4.8.0

I have loaded up the fiddler2 desktop program on that server and I don't have any similar problems. I remember seeing a topic on this group (can't find it anymore) where someone had a very similar sounding issue on WIndows 7 where there was an issue creating a pipeClient.  I believe he mentioned that there was an incompatibility between his FiddlerCore version and his CertMaker.  I don't believe we use CertMaker.dll.  I think we use certmaker.exe.  Are you aware of any compatibility issues that I may be running into in this transition to Windows Server 2012 R2?

Thank you

[EricLaw]

I'm not sure I understand your scenario-- why are you trying to access the request connection while reading from the response connection? What are you hoping to do with the OnReadResponseBuffer method? Do you have this problem only with HTTPS, or HTTP as well? What is the HTTP method of the session in question?

In your scenario, what is the client application?

thanks!

[Kevin Layfield]

Hi Eric, thanks for the response.

We have multiple browsers dynamically being launched on the machine that all use Fiddler as a proxy.  We open a new Fiddler port for each browser.  We use the request object to check the local port value in the code to determine which browser the session belongs to.  For what it's worth, I did just try replacing the oS.oRequest.pipeClient with oS.oResponse.pipeServer and it broke when trying to access the pipeServer.  I access the OnReadResponseBuffer method to a) track the total number of bytes coming in as responses for each browser and b) separately track number of bytes associated with each response that comes back.  We only have the problem with HTTPS, HTTP works fine.  The HTTP method of the session is a CONNECT.  

The client application in this case would be Firefox 7.

I also compiled your sample app from the FiddlerCore installation and ran it on an XP machine without the problem and then on the Server 2012 machine with the problem.  On the Server 2012 machine with the problem, I get this message when I try to visit an HTTPS page:  ** LogString: !SecureClientPipeDirect failed: System.IO.IOException Authentication failed because the remote party has closed the transport stream.  on pipe to (CN=*************, O=DO_NOT_TRUST, OU=Created by http://www.fiddler2.com).  I got that message when attempting to go to https://www.google.com.  The CN wasn't a bunch of asterisks but it was real long so I just put that there.  When I tried the same thing on an XP computer that doesn't have the problem I'm experiencing, I do not receive that error message.  I don't know if this error is related to the problem I'm experiencing, but I figured I'd mention what I observed.

[EricLaw]

The SecureClientPipeDirect failed message indicates that the client doesn't trust the root certificate used by Fiddler/FiddlerCore.

When the OnReadRequestBuffer/OnReadResponseBuffer methods are called on a session with the method CONNECT, the pipeClient and pipeServer objects are not necessarily available on the Session any longer, because these connections are now "owned" by the underlying requests flowing through those CONNECT tunnels. You can use the X-ClientPort and X-ProcessInfo flags on the Session, if present, to keep track of the owning process/port, or you can assign new fields to the session (containing any identifier you like) during the OnBeforeRequest or OnBeforeResponse methods; these flags can then be read by your OnRead*Buffer callbacks.

[Kevin Layfield]

Hey Eric,

Your clue about the SecureClientPipeDirect failed message was what I needed to hear.  I made the same mistake in using the sample app as I made when trying to use our firefox installation - the root cert wasn't properly installed.  Thank you very much for the assistance.

[Kevin Layfield]

I had another question in regards to this.  We have everything working now, but we're a bit confused about the personal certificates created using the Fiddler root cert as the trusted authority.  In the past, I believe the personal certificates were generated and put in the user's Personal certificates store.  We don't see anything being put in there now, but https tests are working fine.  Did the placement of these certificates change for Windows Server 2012?  The only other thing that we've done that could potentially have had some effect on this was that in our .NET application, we changed the default location for where Fiddler searches for the makecert.exe file.  As a followup question to that, I was also wondering if once I changed that location, is that preference stored permanently somewhere?  I was looking to reset the location that Fiddler would look for makecert.exe back to the default for testing purposes, but I'm not sure how to do so.

Thanks

[EricLaw]

You can type about:config in Fiddler's QuickExec box (below the session list) to see all of the preferences that have been set for Fiddler. Note that these preferences are not used by FiddlerCore-based applications.

Makecert.exe still stores certificates it generates in the User Personal Store (whatever user is running Fiddler or FiddlerCore). Because you're running on Server 2012, it may have also prompted you to copy the root certificate only to the Machine's Trusted Store. If you have the appropriate "CleanupServerCertificates" preference set, the per-site certificates will be deleted from the Personal store each time you close Fiddler.

(In contrast to MakeCert, the Certificate Generator plugin does not store per-site certificates; it keeps them only in memory).