Making an SSL Auditing Proxy with a Mac and Burp

What You Need


Many mobile apps don't properly implement SSL/TLS. In this project the Mac computer is used to perform a man-in-the-middle attack using Wi-Fi and Bluetooth as shown in the diagram below. Any app on the mobile device can easily be tested to see if it can detect the attack.

Task 1: Sharing the Mac's Internet Connection

On the Mac, connect to a Wi-Fi network.

In the top right of the Mac desktop, click the magnifying glass. In the search box, type terminal

Double-click Terminal, as shown below.

In the Terminal window, execute this command:

You see a list of all the network interfaces on your machine, as shown below. Your list will probably be shorter than the one below, but it will depend on how many networking apps you have installed on your Mac. Notice that you don't have any interfaces named "bridge".

On the top left of the Mac desktop, click the Apple, "System Preferences".

In System Preferences, click Bluetooth.

If Bluetooth is off, turn it on, as shown below.

In System Preferences, at the upper left, click the little rectangular icon made of dots, as outlined in green in the image above.

In System Preferences, click Sharing.

On the left side, click the words (not the check box) "Internet Sharing".

On the right side, in the "Share your connection from" list, select Wi-Fi.

In the "To computer using" list, check "Bluetooth PAN", as shown below.

On the left side, click the check box next to "Internet Sharing". In the "Are you sure...?" box, click Start.

In the Terminal window, execute this command:

A new network interface appears in the list with a name starting with "bridge". This is the interface the mobile device will use.

In my case the name was bridge0, as shown below.

Make a note of your bridge interface name. You will need it later, when you configure the "pf" firewall.


The Sharing panel makes it look like you could share any type of network connection over any other sort of connection, but that's not true. There are nasty bugs here, and strange changes Apple makes in updates that surprise people.

When I used OS X 10.9, I was able to share an iPhone USB connection to computers using Wi-Fi, but that option was removed in OS X 10.10.

If you try some other combination than Wi-Fi to Bluetooth, you may have problems.

Testing the Shared Internet Connection

On your mobile device, turn off Wi-Fi and Cellular data. The images below show how to do that on an iPad:

On the mobile device, turn on Bluetooth. Click the name of your Mac computer.

On your Mac, a box pops up. Click Pair.

The portable device should now show that it is "Connected" to the Mac, as shown below.

On your portable device, open a Web browser and go to a website, such as

The page should load, although it may be slow.

At this point, the Mac is in the middle--all Internet traffic from the mobile device passes through it. All that remains is to configure Burp and pf on the Mac to intercept and examine that traffic.

Task 2: Install Java

Burp requires Java, so you must make sure Java is installed.

On the Mac, open a Web browser and go to

Click "Do I have Java?", as shown below.

On the next page, click the "Verify Java Version" button.

If you see a "Java blocked for this website" message, as shown below, click that message, and click Trust. Then click Run.

You should see the "Congratulations!" message shown below. If you don't, follow the instructions on the page to download and install Java.

Task 3: Start a Burp Transparent Proxy

At the upper right of the Mac desktop, click the magnifying glass icon, as shown below.

In the search box, type burpsuite. If Burp is already on your Mac, it will be found, as shown below.

If you don't have Burp, open a Web browser, go to

and download the free version. Then repeat the search.

In the search box, double-click burpsuite_free.

If a box appears saying "Are you sure...", as shown below, click Open.


If error messages appear, saying you cannot run software from unknown sources, open "System Preferences", click "Security & Privacy", and configure your Mac to Allow apps downloaded from Anywhere, as shown below.

In Burp, click the Proxy tab. Click the Intercept sub-tab.

If the Intercept button reads "Intercept is on", click it, so the message reads "Intercept is off", as shown below.

Click the Options sub-tab. At the top, in the "Proxy Listeners" section, see if there are any entries on the box shown to the right.

If there are, click each entry to highlight it, and then click Remove to remove them all, as shown below.

In Burp, Aat the top, in the "Proxy Listeners" section, click the Add button.

On the Binding tab, enter a "Bind to port" of 8080

Click the "All interfaces" button, as shown below.

Click the "Request handling" tab.

Click the "Support invisible proxying" box, as shown below.

At the lower right of the box, click OK. A box pops up, asking "Are you sure...?". Click Yes.

Burp should now show a Listener on "*:8080" with the Invisible box checked, as shown below.

On the line showing "*:8080", click the Running check box twice to check it, as shown below.

Task 4: Forward Traffic to the Proxy with pf

Burp is now ready to gather traffic on port 8080 and forward it to the Internet. However, the mobile device doesn't know it should be sending traffic to the proxy server, so Burp won't ever see it.

It is possible to configure the mobile device to use a proxy, but not all apps will respect that setting. Some apps will just send traffic past the proxy, defeating our goal of auditing the network traffic. A much better way to audit apps is to use the Mac firewall "pf" to send all traffic from the Bluetooth adapter through the proxy, so the mobile device won't know it's using a proxy.

To use the "pf" firewall, we need to create two files: "pf.rules" and "pf.conf". For our purposes these files can be very simple.

In the Terminal window, execute these commands.



The "pwd" command shows the current working directory. Make a note of it--you will need it later.

In my case, the directory was /Users/sambowne

Your directory will be different.

In the Terminal window, execute this command:

nano pf.rules
The "nano" text editor opens. In nano, type this line, as shown below. If your interface was named something other than "bridge0", edit this line to use the correct interface name.

This rule redirects all TCP traffic from the Bluetooth connection to Burp, at

rdr pass on bridge0 inet proto tcp from any to any port 1:65535 -> port 8080

Press Ctrl+X, Y, Enter to save the file.

In the Terminal window, execute this command:

nano pf.conf
The "nano" text editor opens. In nano, type the two lines shown below.

In the second line, change /Users/sambowne to the correct directory you found above.

This configuration file tells pf where to find the rules file.

rdr-anchor "forwarding"
load anchor "forwarding" from "/Users/sambowne/pf.rules"

Press Ctrl+X, Y, Enter to save the file.

The next step is to test the files.

In the Terminal window, execute this command:

sudo pfctl -vnf pf.conf
Enter your password when you are prompted to.

If your files are correct, you'll see a "Loading anchor forwarding..." message, followed by the line beginning with "rdr pass on bridge", as shown below.

If there are errors in your files, you'll see error messages here. If that happens, use nano to edit the files and correct the errors.

When your files pass this test without errors, execute this command to start pf:

sudo pfctl -evf pf.conf
You should see several messages but no errors, as shown below.

Task 5: Testing the Proxy

On your mobile device, in the Web browser, go to

The page should load, as shown below.

On your Mac, in Burp, click the "HTTP History" sub-tab.

You should see traffic to, as shown below.

Burp is now intercepting and examining your mobile device's Internet traffic. There's no way for your mobile device to detect this man-in-the-middle attack for the HTTP protocol, which is one of the reasons it's an insecure protocol. However, Burp won't be able to get away with that with a properly-implemented HTTPS protocol.

On your mobile device, in the browser, go to --this is a secure page.

You should see a "Cannot Verify Server Identity" message, as shown below.

Click Details.

A "Certificate" box opens, showing that this certificate was "Issued by PortSwigger CA", as shown below.

PortSwigger is the company that made Burp, and Burp is creating fake certificates for every website and signing them. The browser on your mobile device is correctly notifying you that PortSwigger is not a trusted CA, indicating that a possible man-in-the-middle attack is in progress,


Dev tip: Port forwarding/redirecting (internally) on OS X Mavericks

Posted 6-9-15 by Sam Bowne