HTTPS inspection problem

5 posts, 1 answers
  1. mrihtar
    mrihtar avatar
    2 posts
    Member since:
    Jun 2014

    Posted 06 Jun 2014 Link to this post

    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?
  2. Answer
    Eric Lawrence
    Eric Lawrence avatar
    832 posts

    Posted 09 Jun 2014 Link to this post

    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!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 to true. This will cause Fiddler to use the hostname specified inside the TLS ClientHello handshake to generate the target site's certificate.!searchin/httpfiddler/$20/httpfiddler/iJk7yctHdFg/LcSficgvg8IJ

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

    Eric Lawrence

    Check out the Telerik Platform - the only platform that combines a rich set of UI tools with powerful cloud services to develop web, hybrid and native mobile apps.

  3. mrihtar
    mrihtar avatar
    2 posts
    Member since:
    Jun 2014

    Posted 11 Jun 2014 in reply to Eric Lawrence Link to this post

    Thank you Eric for the detailed answer. The trick with adding an X-OverrideCertCN flag solved the problem:
    if (oSession.HTTPMethodIs("CONNECT") && oSession.HostnameIs("")) {
      oSession.oFlags["X-OverrideCertCN"] = "";
  4. aya
    aya avatar
    1 posts
    Member since:
    Feb 2016

    Posted 26 Mar 2016 Link to this post

    Thank you very much, "prefs set true" solved the problem when using proxifier.
  5. Varun
    Varun avatar
    1 posts
    Member since:
    Aug 2016

    Posted 25 Apr 2017 Link to this post

    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

Back to Top