How SSL Kill Switch works on iOS 12 | Hacker News Reader

How SSL Kill Switch works on iOS 12

nabla-c0d3.github.io

54 pointstosh14 comments

I did something similar but for macOS. I used Frida, a really easy toolkit for intercepting native calls.

Information: https://github.com/kendfinger/AppleCache#methodology

Tools: https://github.com/kendfinger/AppleCache/tree/master/tools

So, if some apps skip the dynamically linked external libraries and statically bundle their own copy/implementation of SSL library along with only using Socket connections, this method wouldn't work.

I wonder what is the space cost of statically adding trimmed down SSL library. Apps are easily 100+ MB these days.

This is done by some apps today, though the motivation was typically network perf (http2 and then QUIC support). The stacks are large - on iOS it's difficult to take over a portion of networking without rebuilding a substantial amount of it, so you'll have TLS, a full http stack, plus all supporting logic for connection pooling, etc. The closest thing to an open-source, drop-in option like this is cronet, the networking core of chromium packaged as a standalone library. Last I looked it was multiple megabytes in size, which is still a substantial cost for iOS apps. They can also be quirky to use because they fight against the system's defaults in some areas and can cause other inefficiencies (typically outweighed by the network improvements).

I believe Uber talked publicly about adopting cronet, and Facebook gave a talk about mobile proxygen (though it is not open-source). If you pop open the Netflix and Youtube apps, you will likely see the same.

Some apps generate a side effect from the callback being run so if you prevent the callback from happening then the app breaks. This is similar to the problem he has with patching the boring ssl callback so the libraries callback doesn't get called. The libraries callback was generating side effects that needed to happen.

It's worth noting that this article is from 2019. There hasn't been another article about iOS 13 support yet.

there also was no introduction of yet another networking library rewrite, so I would assume the iOS12 solution continues to work with iOS13

SSLKillSwitch2 seems to use the same technique for iOS 13

https://github.com/nabla-c0d3/ssl-kill-switch2/pull/72/files

Pretty sure this will work on iOS 13 too

https://codeshare.frida.re/@machoreverser/ios12-ssl-bypass/

Here's another Frida snippet that'll extract the TLS keys so traffic can be decrypted (magic number in the code might need changing for iOS 13 though)

https://codeshare.frida.re/@andydavies/ios-tls-keylogger/

Why is Apple using BoringSSL on their OS?

seems to be an ok choice. It's maintained by a very capable team that has a strong security focus, it's in use on the largest mobile platform (Android) and the motivations and focus behind its maintenance align well with Apple's.

What would you have chosen? And why?

It seems like they use it after iOS 11[1],

Maybe they want to prevent another possible goto fail[2] bug?

[1] https://twitter.com/steipete/status/979725476364242944

[2] https://gotofail.com/

We switched to BoringSSL at Cloudflare (from OpenSSL) about 3 years ago.

A few reasons why can be found here: https://blog.cloudflare.com/make-ssl-boring-again/.

There was the Heartbleed vulnerability which affected just about everything that used OpenSSL, which was a lot of things. There were some efforts to fork this codebase and simplify it. BoringSSL is one of those, LibreSSL another.

Summary I recall from looking into LibreSSL website some time ago: OpenSSL has a lot of cruft and does weird things like implements its own memory allocator. Most of this is because it supports an extremely wide variety of platforms (I think things like VAX and Amiga). This makes tools that try to detect things like buffer overflows not work properly, which is what Heartbleed was.

There have been many minor versions of OpenSSL released to update security vulnerabilities since Heartbleed.

Why are those platforms still supported?

Reply on news.ycombinator.com