iOS Man-in-the-Middle Attack Techniques and Trusted Certificate Management

0x00 Overview

Man‑in‑the‑Middle (MITM) attack is an indirect intrusion where an attacker places a compromised device between two communicating endpoints to steal, modify, or forge data. This article focuses on MITM attacks on iOS and the handling of trusted certificates.

0x01 Man‑in‑the‑Middle Attack

All experiments were performed on a jail‑broken iPhone 5 running iOS 8.1.2.

1.1 MITM Attack Levels

iOS MITM attacks can be classified into three levels based on whether the attacker’s certificate is installed:

Level 1 – Attack succeeds without installing any attacker certificate.

Level 2 – Attack succeeds after installing the attacker certificate.

Level 3 – Attack fails even after the attacker certificate is installed.

Examples for each level are demonstrated using a modified OWASP iOS HTTPS MITM demo.

1.1.1 No Certificate Installed (Level 1)

The app implements only connection:didReceiveAuthenticationChallenge: in the NSURLConnection delegate. By configuring Burp Suite as an HTTP proxy on the iPhone, the request to “Fetch Secret” is intercepted and the data is displayed, proving a successful MITM.

1.1.2 Certificate Installed (Level 2)

The app is changed to implement connection:willSendRequestForAuthenticationChallenge: . With the same proxy settings, the connection is aborted and no data is returned. After installing the Burp Suite certificate on the device, the request succeeds again, confirming a successful MITM.

1.1.3 Certificate Installed but MITM Prevented (Level 3)

The app embeds a public‑key certificate and performs strict server‑certificate validation inside connection:didReceiveAuthenticationChallenge: , while the willSendRequestForAuthenticationChallenge: method is removed. Even with the Burp certificate present, the app rejects the connection and the MITM fails.

1.2.4 Recommendations

Generally, trusting all certificates on the device is sufficient, but embedding a public key for strict validation offers higher security at the cost of certificate‑update complexity. Level 3 protection is rarely seen in practice.

0x02 Trusted Certificate Management

iOS stores the real list of trusted certificates in /private/var/Keychains/TrustStore.sqlite3 , which may differ from the list shown in Settings → General → Profiles.

2.1 Hidden MITM Scenario

When the device only shows a corporate employee certificate, Burp Suite can still intercept traffic if its certificate is present in TrustStore.sqlite3 but not displayed in Profiles.

2.2 TrustStore.sqlite3

The SQLite file contains the actual trusted certificates. By manually editing this file, one can add or remove certificates without affecting the Profiles view. Deleting the Burp certificate from the file disables the MITM, while reinserting it restores the attack.

2.3 MITM on Jail‑broken Devices Without Visible Certificates

Malicious jailbreak tweaks or apps can modify TrustStore.sqlite3 to insert attacker certificates, enabling silent MITM attacks even when Profiles shows no suspicious entries. Therefore, on jail‑broken iPhones, inspecting /private/var/Keychains/TrustStore.sqlite3 is essential.

0x03 Conclusion

iOS MITM techniques and defenses are summarized in section 0x01. For ordinary apps, trusting all device certificates is adequate, but on jail‑broken devices, inspect /private/var/Keychains/TrustStore.sqlite3 for hidden certificates.