3

I tried to analyze the https traffic of apps on my MacBook and iPhone with Charles with SSL proxy (I use HTTP proxy for IOS and installed and trusted Charles certificate). I managed to decrypt most HTTPS traffic, however, when I discovered that I cannot connect to App Store on my iPhone when I was on the proxy, I realized none of apple's traffic (AppStore, iCloud, etc) are decrypted by Charles (Charles was able of detecting those traffic by showing the domain name, but it said the client SSL handshake failed, same on macOS as well as IOS).

My speculation is that instead of relying on the system certificates, Apple uses a different, more restricted set of certificates to verify their own services (system level). I also heard about a technology called SSL pinning, which can achieve this feature.

I am not sure whether this is the case, if it is, how can we bypass this restriction?

lewisxy
  • 31
  • 1
  • I've noticed the same behaviour, Charles says handshake filed for *.icloud.com and *.apple.com. But another hosts are OK. @lewisxy did you find a way to bypass Apple security for their own services? – C0DEF52 Jan 09 '20 at 12:21
  • 1
    @C0DEF52 You can have a look about [this](https://github.com/nabla-c0d3/ssl-kill-switch2/) project. It is designed for IOS, but should also work for MacOS. The idea is to "inject" a modified version of SSL library into the process (similar to `LD_PRELOAD` techniques used in Linux). However, I did not make it work on my MacBook (running macOS 10.14.6) yet. – lewisxy Jan 10 '20 at 23:13

0 Answers0