Declaration of VAR

and some other stuff

HTTP debugging proxy on Mac OS

2017-11-22 09:27:08 +0100

2017-11-22 09:27:08 +0100 | Comments

When I was on Windows, I was using Fiddler as a HTTP debugging proxy. After I moved to Mac, I started to look for an alternative.

There are ways to make Fiddler work on Mac too, but it didn’t work for me on a first try, and I didn’t want to dive deeper. Besides, I wanted to get some nice-looking and natively-performant Mac OS app.

So, I started looking. Soon enough I found these questions at Stack Exchange:

  1. Looking for HTTP debugging proxy for Mac similar to Fiddler on Windows;
  2. Are there any HTTP/HTTPS interception tools like Fiddler for mac OS X?;
  3. HTTP debugging proxy for Linux and Mac.

From those I got to know Charles, which trial version I installed immediately. Well, what can I say: it gets the job done, but it feels uncomfortably slow and weights too much for such an application. And when I discovered, that it is Java-based, I had no more questions in that regard. On top of that it costs $50 per license, which is just too expensive.

Meet Proxie

I didn’t find any good alternatives to Charles, so I started to getting upset (and preparing $50), but then on this website I discovered Proxie. Actually, there it is named as Cellist (apparently, that’s its former name).

And this is exactly the application I was looking for:

  • HTTP debugging proxy, that works with HTTPS too;
  • pretty light-weight and natively-performant;
  • nice-looking;
  • costs only $10.

Here’s a screenshot:

Very conveniently organised, you can view packets grouped by URL, view packets by types, and also you can create your own grouping filters:

It is a bit unfortunate though, that Proxie does not have a trial period, so I had to download a cracked version from a warez tracker to try it out. And only after I made sure, that it has all the functionality I needed, I deleted it and purchased the application from App Store:

Okay, now about how to use it.

Sniffing traffic

From the same Mac OS machine

When you launch Proxie, it starts to listen to your localhost’s specified port, as it is shown on the top of the application’s window. And you need to set-up this proxy in your network settings, so all of your applications would send their traffic through it.

Open Mac OS network preferences, choose the network (Wi-Fi in my case) and click Advanced:

Despite the fact that Proxie shows your network address, it’s better to use the old good 127.0.0.1 (and the port that Proxie listens to). Do it for both Web Proxy and Secure Web Proxy:

Note, that Proxie does not do it by itself. Neither does it set the proxy settings off on exit, meaning that when you’re done with HTTP debugging, you need to go there (system network preferences) again and uncheck both Web Proxy and Secure Web Proxy checkboxes.

Now you need to install the Proxie’s certificate into your system (implementing man-in-the-middle). If you won’t do that, Proxie won’t be able to properly sniff encrypted HTTPS packets.

Go to the Proxie settings, mark the decryption checkbox and export certificate:

Find the exported proxie-ca.pem, double-click it, and add it to your keychain:

Now open Keychain Access.app, find this certificate in the list, double-click it and make it trusted:

Now you can inspect your packets (including HTTPS ones) in Proxie.

But.

Not every application (especially Terminal apps) respects system proxy settings. So, if you don’t see packets from your application in Proxie, that means that your application is one of those, and you need to specify proxy settings for it manually (in its config, source code, etc).

For example, I am testing some .NET Core application in Visual Studio Code. So, in order to make it using proxy, I need to do this:

var httpClientHandler = new HttpClientHandler
{
    Proxy = new WebProxy("http://127.0.0.1:4321", false),
    UseProxy = true
};
using (var http = new HttpClient(httpClientHandler))
{
    // your HTTP request here
    //var httpResponse = await http.PostAsync(URL, content);
    //var responseBody = await httpResponse.Content.ReadAsStringAsync();
}

From iPhone

…Or any other device in your local network. This is already described in the Proxie documentation pages (Help -> About HTTP Decryption), but I’ll add my comments anyway.

So, in case of an iPhone you need to:

  1. Set-up a proxy in your iPhone Wi-Fi settings;
  2. Add a Proxie certificate to your iPhone and make it trusted.

Logically enough, there is no need to enable proxy in Mac OS network preferences.

First one is easy, go to Settings -> Wi-Fi -> Click on the blue circled i on your current network -> Configure Proxy -> Manual:

Then open this URL (sslca.io) in browser on your iPhone and install Proxie’s certificate:

And finally go to your iPhone Settings -> General -> About -> Certificate Trust Settings and enable Proxie CA:

Now you will see the traffic from your iPhone coming through Proxie on your Mac:

Awesome.

Weird enough though, that AppStore refuses to connect even with the trusted certificate, whilst other applications work just fine. But that’s okay, because it’s not the AppStore’s traffic I was after, as you can see.

When you’re done debugging, don’t forget to disable proxy settings and “untrust” the Proxie certificate (just in case).



[09.06.2018] Update: Trial version

They’ve added a free trial version: https://proxieapp.com