HTTPS inspection problem

[mrihtar]

I am a longtime user of Fiddler (version 2) proxy and it really is an amazing product. One of it's best features is the ability to decode and inspect HTTPS traffic, including automatic generation of proper certificates. Usually this works without problems, but I've stumbled upon a problem, which is not clear to me.

I am trying to "convince" some java program, which connects to it's server via https, to use Fiddler2 as a proxy (on Windows 7 x64, java 1.6.0_45 64-bit). Java program itself just won't connect through proxy, regardless of what I do or set up via Java control panel. I cannot modify the java source code (not available) or add command line parameters to java because it's started inside a parent .exe program. The only thing I could come up was to use a "proxifier" (ProxyCap), which redirects all traffic from any program (system wide) to a configured Fiddler2 proxy.

If I now test the existing configuration with my own java program (proxified) issuing https requests, I can see the decoded https traffic in Fiddler2 (first tunnel set up, then decoded traffic). If I run the original java program, I can see it sets up the tunnel to the destination IP, but then nothing happens. In request headers I see CONNECT <IP>:443 and in response I see "200 Connection Established".

Is Fiddler2 behaving differently to the application itself as the original https server would? Could an application (java program) stop because the parameters exchanged during the handshake are not the "correct" ones? Or is Fiddler connecting to the remote https server in a "wrong" way and it disconnects it? How can I get more information about what's happening?

[Eric Lawrence]

Hi, Matjaz--

It's very strange that there's literally no way for you to set the proxy, because this means that the Java program in question could never be sold for use in an enterprise, as most use proxy servers.

However, you can likely get this working anyway. There are two issues:

1> You have to get Java to trust Fiddler's root certificate.
2> You have to ensure Fiddler is returning the right certificate.

Step #1 is straightforward and it sounds like perhaps you've already done this as you don't have any problem with the application you wrote yourself?

For Step #2, the problem is that Fiddler is deciding what certificate to return based on the target of the CONNECT request. However, because you've "proxified" the application, the CONNECT request contains the IP address of the target server rather than the expected hostname. When Fiddler dutifully returns a certificate for the target IP address, the client application (which doesn't know that it was proxified) rejects that certificate because the SubjectCN=<ipAddress> doesn't match the expected SubjectCN=<hostname> that the client expects.

Fortunately, this problem arose often with older Android devices and so Fiddler offers two ways to workaround the issue.

One way is to force Fiddler to connect to the server, then return a certificate that matches the subject CN from the server; see https://groups.google.com/forum/#!searchin/httpfiddler/android$20SNI/httpfiddler/hvsDR14j1Lg/wDVxZFlS5PgJ for info on the X-UseCertCNFromServer flag.

The other way is to set the SubjectCN based on the TLS ClientHello SNI extension which is sent if the client supports it. To use that approach, set the preference fiddler.network.https.SetCNFromSNI to true. This will cause Fiddler to use the hostname specified inside the TLS ClientHello handshake to generate the target site's certificate. https://groups.google.com/forum/#!searchin/httpfiddler/fiddler.network.https.SetCNFromSNI$20/httpfiddler/iJk7yctHdFg/LcSficgvg8IJ

With any luck, one of these two approaches will work for you.

Regards,
Eric Lawrence
Telerik

 

 

[mrihtar]

Thank you Eric for the detailed answer. The trick with adding an X-OverrideCertCN flag solved the problem:

if (oSession.HTTPMethodIs("CONNECT") && oSession.HostnameIs("74.125.71.84")) {
  oSession.oFlags["X-OverrideCertCN"] = "hostnameToUseInCertificate.com";
}

[aya]

Thank you very much, "prefs set fiddler.network.https.SetCNFromSNI true" solved the problem when using proxifier.

[Varun]

One of the possibile I like to add for Proxifier

 

Proxifier -> Profile -> Name Resolution

Check "Resolve hostname through proxy"

Check "Resolive only the following" and add list of domains here