SSLyze 2.0.0 Released

I just released SSLyze 2.0.0, my Python library for scanning the SSL/TLS configuration of a server.

This release adds support for the final version of TLS 1.3, and also introduces a lot of behind-the-scene improvements that I am going to describe in this article.


  • Dropped support for Python 2 and older versions of Python 3; only Python 3.6 and 3.7 are supported.
  • Added support for the final/official release of TLS 1.3 (RFC 8446).
  • Added beta support for TLS 1.3 early data (0-RTT) testing; see --early_data and EarlyDataScanCommand.
  • Significantly improved the documentation for the Python API.
  • SSLyze can now be installed via Docker.
  • Bug fixes.
  • Switched to a more modern Python tool chain (pipenv, pytest, pyinvoke).
  • Removed legacy Python 2/3 code and ported the code base to Python 3 only.

A modern Python toolchain

A lot of the changes I’ve implemented for this release had to do with using new/better Python tools that have been released since I initially started working on SSLyze eight years ago:

  • Type checker: I added type annotations to the whole code base using the typing module; strict type checking is then enforced in CI with mypy.
  • Build system: I re-implemented the build and tasks (testing, etc.) system using Invoke. SSLyze’s C module for accessing OpenSSL requires compiling various libraries (Zlib, OpenSSL, etc.) and the previous implementation was using custom Python code. With Invoke, the whole C module can be built using one command, on all supported platforms (Linux, Windows, etc.).
  • Test runner: I switched to pytest as the test runner; it provides more options and a lot more details when a test fails, and is overall superior to the standard library’s unittest module. Even the unittest’s documentation mentions pytest as a better solution. The next step will be to migrate the actual code within SSLyze’s test suite from unittest to pytest (which provides an API for tests that’s a lot cleaner).
  • Dependencies management: I switched to Pipenv for dependency and virtual environment management. It replaces pip and virtualenv, and makes things a lot simpler. Additionally, GitHub’s Dependency graph feature supports Pipenv, and can automatically detect dependencies that have known vulnerabilities; pretty cool!

Modernizing the toolchain will make it a lot easier to maintain and extend SSLyze, and makes the code base a lot more approachable to developers who may be interested in contributing.

OpenSSL: double the fun

Following the discovery of the Heartbleed vulnerability in 2014, the OpenSSL team decided to start aggressively dropping support for TLS features or protocols that are insecure and should not be used. This is obviously a very good thing for the Internet, but it also makes the job of scanning servers for TLS issues more difficult.

For example, SSLyze relies on OpenSSL to try to perform SSL 2.0 handshakes in order to find servers that support this legacy protocol. Once OpenSSL stopped supporting SSL 2.0 (which, again, is a good thing), any future release of OpenSSL could no longer be used by SSLyze.

The solution I ended up implementing is to package not one but two (!!) versions of OpenSSL within SSLyze (more specifically within nassl, its C module for accessing OpenSSL):

  • A “legacy” version of OpenSSL, 1.0.1e. This is the last OpenSSL release that supports all the insecure features and protocols, and the version SSLyze uses to scan for things like Heartbleed, SSL 2.0, CCS injection, etc.
  • A “modern” version of OpenSSL, 1.1.1. This version was released only a few days ago, and is the version SSLyze uses to scan for modern TLS features, such as TLS 1.3 and early data.

This approach ensures that moving forward, SSLyze can scan for both legacy TLS issues, and new features and protocols.

More details

For more details, head to the project’s page or the Python documentation.

October 06, 2018

Security and Privacy Changes in iOS 12

This year and for the first time, I actually went to the Apple WWDC conference, in San Jose. The conference was quite interesting, and gave me the opportunity to meet some of the members of the Apple security team.

Here are some notes about the security and privacy changes brought by iOS 12 that I thought were interesting.

Automatic strong passwords

The “Automatic Strong Passwords and Security Code AutoFill” session describes various enhancements made to the iOS built-in password management functionality.

Automated password generation

Starting with iOS 11, developers can “label” the username and password field in their app’s login screen:

let userTextField = UITextField()
userTextField.textContentType = .username

let passwordTextField = UITextField()
passwordTextField.textContentType = .password

This allows iOS to automatically login the user with the credentials they previously saved in their iCloud account, if the app has been properly associated with its web domains.

With iOS 12, a strong password can automatically be generated and stored when creating a new account in an app or in Safari. This functionality can be enabled by using the .username and the iOS 12 .newPassword content types in your “Create Account” screen:

let userTextField = UITextField()
userTextField.textContentType = .username

let newPasswordTextField = UITextField()
newPasswordTextField.textContentType = .newPassword

let confirmNewPasswordTextField = UITextField()
confirmNewPasswordTextField.textContentType = .newPassword

iOS 12 will then prompt the user to automatically generate a strong password during the account creation flow.

Any password that was automatically generated will contain upper-case, digits, hyphen, and lower-case characters. If your backend has limitations in the characters it allows in passwords, you can define a custom password rule in your app via the UITextInputPasswordRules API:

let newPasswordTextField = UITextField()


let rulesDescriptor = "allowed: upper, lower, digit; required: [$];" 
newPasswordTextField.passwordRules = UITextInputPasswordRules(descriptor: rulesDescriptor)

Apple has also released an online tool to help with writing password rules.

Similar labels can be used in a web page that Safari can leverage:


Automated 2FA SMS codes input

iOS 12 also introduces a content type for the text field that will receive 2 factor authentication codes received via SMS:

let securityCodeTextField = UITextField()
securityCodeTextField.textContentType = .oneTimeCode

Enabling this content type allows iOS to automatically fill in a 2FA code previously received via SMS (with a user prompt), which is pretty cool:


Federated authentication

iOS 12 introduces a new ASWebAuthenticationSession API for automatically handling an OAuth login flow.

Given an OAuth URL (ie. where to start the authentication flow), the API will:

  • Direct the user to the OAuth provider’s authentication page.
  • Have the user then log into their account on the provider’s page. As the API uses the same cookie store as Safari, the user may already be logged into their account; if that’s the case, the user will be prompted to confirm that they want to re-use their existing session in Safari, making the flow really quick.
  • Allow the user to review the OAuth permissions requested by your app, and grant access via the OAuth authorization prompt.
  • Return the user to your app and provide the callback URL, which contains the user’s authentication token if the flow was successful.

It was stated during the WWDC presentation that ASWebAuthenticationSession is now the “go-to way to implement federated authentication and it replaces SFAuthenticationSession”, which was deprecated in iOS 12.

Credential Provider Extension

All the password management improvements described above apply to the built-in password manager in iOS and Safari, the “iCloud KeyChain”. However, third-party password manager applications (such as LastPass, 1Password, etc.) can also get integrated into the password flows on iOS, via a new extension point called “Credential Provider Extension”.

Credential Provider Extension

This extension point and the corresponding APIs are all part of the new AuthenticationServices framework available on iOS 12. This framework allows providing a UI for user to choose their password when authenticating into an app, storing a newly-created password, etc.

The framework is described in details in the “Implementing AutoFill Credential Provider Extensions” presentation.

Secure object de-serialization

At WWDC this year, a whole presentation was dedicated to secure object serialization and de-serialization: “Data You Can Trust”.

When an application has some logic to receive arbitrary data (for example over the Internet) and to then de-serialize the data into an object, care must be taken when implementing this logic. Specifically, if the raw data can choose any arbitrary class as the the object it gets de-serialized to, this can lead to remote code execution. This type of vulnerability affects almost every language and framework, for example Apache and Java, Ruby on Rails, or Python’s pickle module.

In iOS applications, object (de-)serialization is usually implemented using:

  • The NSCoding protocol, which allows the developer to implement the serialization logic for their own classes.
  • The NSKeyedArchiver class which takes an object that implements NSCoding and serializes it into a specific file format called an archive, which can then be stored for example on the file system. The NSKeyedUnarchiver class can then be used to de-serialize the object.

This approach is vulnerable to the issue described above, referred to as an “object substitution attack” in the Apple documentation: the data gets de-serialized to a different object than what was expected by the developer.

To prevent such attacks, the following APIs were introduced in iOS 6:

  • [NSKeyedArchiver decodeObjectOfClass:forKey:], which allows the developer to pick the class the data will get de-serialized to before it occurs, thereby preventing object substitution attacks.
  • The NSSecureCoding protocol which extends the NSCoding protocol by adding the class method supportsSecureCoding:, in order to ensure that the developer is using the safe -decodeObjectOfClass:forKey: method to handle object serialization and de-serialization in their classes.

The “Data You Can Trust” presentation this year heavily emphasized NSSecureCoding and -decodeObjectOfClass:forKey::

Secure Coding

What has changed with iOS 12 is that [NSKeyedArchiver init] constructor is now deprecated; this was done to get developers to switch to the [NSKeyedArchiver initRequiringSecureCoding:] constructor instead, which has been made public on iOS 12 (but seems to be retro-actively available in the iOS 11 SDK). This constructor creates an NSKeyedArchiver that can only serialize classes that conform to the NSSecureCoding protocol, ie. objects that are safe to serialize and de-serialize.

The Network framework

The Network framework, introduced somewhere around iOS 9 or 10 has become a public API on iOS 12.

It is a modern implementation of a low-level networking/socket API. As stated in the documentation, it is meant to replace all the other low-level networking APIs available on iOS: BSD sockets, SecureTransport and CFNetwork:

“Use this framework when you need direct access to protocols like TLS, TCP, and UDP for your custom application protocols. Continue to use NSURLSession, which is built upon this framework, for loading HTTP- and URL-based resources.”


More details about the Network framework are available in the “Introducing Network.framework: A modern alternative to Sockets” presentation.

Developers should expect the legacy network APIs (SecureTransport, etc.) to eventually get deprecated by Apple. Right now and as mentioned in the presentation, they are “discouraged APIs”.

The Network framework also comes with its own set of symbols for handling TLS connections, such as certificates, identities, and trust objects. They mirror the legacy SecureTransport symbols and can be used interchangeably. For example, a SecCertificateRef, which represents an X.509 certificate, is a sec_certificate_t in the Network framework. The sec_certificate_create() function can be used to turn a SecCertificateRef into a sec_certificate_t.

Lastly, App Transport Security is not enabled for connections using the Network framework, but will be “soon” according to Apple engineers.

Other changes

Deprecation of UIWebView

Starting with iOS 12, the UIWebView API is now officially deprecated. Developers that need web view functionality in their application should switch to the WKWebView API, which is a massive improvement over UIWebView in every aspect (security, performance, ease of use, etc.).

Unified Random Number Generation in Swift 4.2

Swift 4.2 introduces an API for generating random number, described in the “Random Unification” proposal.

Previously, generating random numbers in Swift was done by importing C functions that are insecure in most cases (such as arc4random()).

Enforcement of Certificate Transparency

Apple will be enforcing Certificate Transparency at the end of 2018 across all TLS connections on iOS. This does not require any changes in your application as the work to deploy CT has been carried out by the Certificate Authorities. More details are available in the “Certificate Transparency policy” article.

The CT enforcement will be deployed “with a software update later this year”.

Enforcement of App Transport Security

With iOS 9, Apple introduced App Transport Security (ATS), a security feature which by default requires all of an app’s connections to be encrypted using SSL/TLS. When ATS was first announced, it was going to be mandatory for any app going through the App Store Review process, starting on January 1st 2017. Apple later cancelled the deadline, and no further announcements about requiring ATS have been made.

However, at WWDC this year, I learned that Apple has started reaching out to specific apps through the App Store review process, in order to ask for justifications and/or require the applications’ ATS policy to be stricter, especially having NSAllowsArbitraryLoads (the exemption that fully disables ATS) set to NO.


So what should I do?

If you are a developer, here is a summary of the changes to implement in your application, based on all the iOS 12 features described in this article.

Short term

  • Add support for Password Autofill to your application. The “Enabling Password AutoFill on a Text Input View” article gives a good summary of the changes you need to implement in your app.
  • If your application’s ATS policy still sets NSAllowsArbitraryLoads to YES, modify your policy by adding the required exemptions and domains, in order to be able to set NSAllowsArbitraryLoads to NO. More details on how to achieve this are available in my ATS guide. Sooner or later, your application will get blocked if it enables NSAllowsArbitraryLoads.

Medium term

  • If your application is using NSCoding for object serialization, switch to NSSecureCoding in order to prevent object substitution attacks.
  • If you application is using the now-deprecatedUIWebView API, switch to WKWebView.

Long term

  • If your application is using a low-level network API (such as BSD sockets, SecureTransport or CFNetwork) switch to the Network framework.

Note: I also published this article on Data Theorem’s technical blog.

June 14, 2018

Introducing the Trust Stores Observatory

For anyone interested in SSL/TLS, certificates, and trust, it has always been surprisingly difficult to get the list of root certificates trusted on each of the major platforms (Mozilla, Microsoft, etc.).

The only tool that I am aware of is the Certification Authority Trust Tracker (CATT), which I have been using for many years in order to retrieve the root stores to be used in SSLyze, the SSL scanning tool I work on. However and as useful as it has been, CATT has to be run manually every time, and is not easy to extend or troubleshoot as it relies on several scripts written in Bash or Perl.

Because it shouldn’t be this hard to retrieve and monitor the content of the main platforms’ root stores, I have been working on a new project called the Trust Stores Observatory; it provides the following features:

  • An easy way to download the most up-to-date root certificate stores, via a permanent link:
  • The ability to record any changes made to the root stores, by committing such changes to Git. This way we can keep the history of the root stores and for example keep track of when a new root certificate was added.
  • The ability to review and compare the content of the different root stores, by storing the content of each store in a YAML file.

Supported platforms

The Trust Stores Observatory currently supports the following platforms:

How it works

The project is implemented using Python 3.6. Each root store is stored in a YAML file in the project’s repository; the YAML file contains the subject name and the fingerprint of every trusted and blocked root certificate.

Once a week, a Travis cron is automatically run in order to retrieve the latest version of each root store, and to commit any changes to the observatory’s repository.

What’s next?

  • Support for additional platforms and root stores (Java, Ubuntu, etc.).
  • Support for also retrieving the list of EV OIDs.
  • Better handling of special restrictions (name constraints, notBefore, etc.) as several platforms have implemented custom restrictions for some CA certificates.

Check it out

Head to the project’s page for more information and feel free to reach out if you have questions or feedback!

January 16, 2018

Scanning for the ROBOT Vulnerability at Scale

I just released SSLyze 1.3.0, which adds support for scanning for the ROBOT vulnerability that was disclosed last week.

Using SSLyze’s Python API, it is possible to easily and quickly scan a lot of servers for the vulnerability. From my own testing and depending on the network conditions, it takes about 5 seconds to scan 20 servers. SSLyze also has the ability to scan servers that use StartTLS-based protocols (such as SMTP, XMPP, etc.), which the test script released along with ROBOT does not support.

The following script (tested on Python 3.6) demonstrates how it can be done:

Enjoy and happy scanning!

December 17, 2017

Mobile TLS Interception Presentation at BlueHat

Earlier today, Thomas Sileo and myself presented at the Microsoft BlueHat conference in Redmond.

The title of the talk was “Where, how, and why is SSL traffic on mobile getting intercepted? A look at ten million real-world SSL incidents”. This is a research project we’ve been working for a couple years; we’ve analyzed pinning failure reports that mobile developers who use TrustKit in their apps have shared with us.

So far, we’ve received about 10 million reports coming from devices all around the world, and we’ve discussed some of the results of our analysis in this presentation.

The slides are now available for download here.

November 08, 2017

SSLyze for Python 3 Released

I just released SSLyze v1.1.0, which finally adds support for Python 3! This means that both the command line tool and the Python API can be called using Python 3.3+. Python 2.7 is still supported, for now.

Head to the project’s page for more information.

Full Changelog

  • Added support for Python 3.3+ on Linux and MacOS. Windows will be supported later.
  • Added support for scanning for cipher suites on servers that require client authentication.
  • Certificate transparency SCTs via OCSP Stapling will be now displayed when running a CertificateInfoScanCommand.
  • Removed custom code for parsing X509 certificates, which was the source of numerous bugs and crashes when running a CertificateInfoScanCommand:
    • Certificates returned by the SSLyze Python API are now parsed using the cryptography library, making further processing a lot easier and cleaner.
    • Certificates returned in the XML and JSON output when using --certinfo are no longer parsed. XML/JSON consumers should instead parse the PEM-formatted certificate available in the output using their language/framework’s X509 libraries.
    • The --print_full_certificate option when using --certinfo is no longer available.
  • Bug fixes for the Heartbleed check.
  • Added unit tests for SSL 2.0, SSL 3.0, Heartbleed and OpenSSL CCS injection checks.

The Python API can do a lot more than this (such as scanning StartTLS endpoints, connecting through a proxy, or enabling client authentication); head to the project’s page or the documentation for more information.

April 22, 2017

SSLyze v1.0.0 Released

I just released a new version of SSLyze, my Python tool/library which can analyze the SSL configuration of a server by connecting to it and detect various issues (bad certificates, dangerous cipher suites, lack of session resumption, etc.).

After almost 20 releases over the past 6 years, SSLyze is now at version 1.0.0. This is a major release as I have completed a significant refactoring of SSLyze’s internals,in order to clean its Python API. The API should be considered stable and is now fully documented!

Using SSLyze as a Python module makes it easy to implement SSL/TLS scanning as part of continuous security testing platform, and detect any misconfiguration across a range of public and/or internal endpoints.

Sample Code

This sample code scans the endpoint to detect the list of SSL 3.0 cipher suites it accepts, whether it supports secure renegotiation, and will also review the server’s certificate:

Getting Started

The Python API can do a lot more than this (such as scanning StartTLS endpoints, connecting through a proxy, or enabling client authentication); head to the project’s page or the documentation for more information.

February 08, 2017

SSL Kill Switch and the iOS 10 Network Stack

After the release of the latest iOS 10 jailbreak, I started getting reports that SSL Kill Switch, my iOS tool to disable SSL pinning in Apps, was not working at all on this version of iOS.

This was very surprising since the tool directly patches the OS’ low-level TLS stack (called SecureTransport) which is used by all the higher-level network APIs on iOS/macOS (CFNetwork, NSURLSession, etc.) to setup a TLS/HTTPS connection with a server. The functions SSL Kill Switch patches are part of SecureTransport’s public API and therefore do not really change across iOS versions, making it unlikely that the tool would just stop working on a new release of iOS.

After doing some investigation, I discovered that the network stack on iOS 10 has changed significantly compared to iOS 9, and I will describe in this post what has changed, why it affected SSL Kill Switch, and how I fixed it.

If you’re looking for the latest SSL Kill Switch binary compatible with iOS 10, go to the Releases tab of the project’s page.

Getting Started

To try to understand why SSL Kill Switch stopped working on iOS 10, I used Xcode and a simple App that opens an HTTPS connection using the NSURLSession API and implements SSL pinning (specifically, the TrustKit Demo App). And as reported, SSL Kill Switch was not able to disable TLS validation when running the App on iOS 10 and trying to use the Burp proxy to intercept the HTTPS connection.

I now needed to figure out what had changed in iOS 10’s network stack, and started by grabbing the dyld shared cache from my iOS 10 device (it’s in /System/Library/Caches/ and opening it in this awesome disassembler called Hopper. Looking at the CFNetwork framework, I started checking TLS methods and symbols, to find the lowest-level TLS function that would be called during a TLS handshake:

Jumping around in various system frameworks and libraries, I eventually settled for the tls_handshake_set_callbacks function in libsystem_coretls.dylib. This function is used to setup callbacks for specific events happening during the TLS handshake; one thing that helped throughout the process is that libsystem_coretls.dylib used to be open-source (athough the iOS implementation might be different).

To try to understand the differences between the iOS 9 and iOS 10 network stacks, I then set a breakpoint on this function in Xcode, in order to be able to look at the stack trace, so I could see the execution flow from the high level NSURLSession network call initiated by my test App, all the way down to this low-level TLS function.

br set -n tls_handshake_set_callbacks
Breakpoint 3: where = libsystem_coretls.dylib`tls_handshake_set_callbacks, address = 0x000000010895928c

This would allow me to understand how the network stack differs on different versions of iOS.

iOS 9 Stack Trace

When the breakpoint is hit, Xcode displays the following stack trace on iOS 9 and 8:

The stack trace looks like this, from top to bottom:

  • tls_handshake_set_callbacks in libsystem_coretls.dylib
  • SSLCreateContextWithRecordFuncs in Security (specifically SecureTransport)
  • SSLCreateContext in Security (specifically SecureTransport)
  • SocketStream::securitySetInfo_NoLock in CFNetwork
  • [Higher level calls]

As expected, we can see SecureTransport functions (SSLCreateContextWithRecordFuncs and SSLCreateContext) being called during the TLS handshake. This is where the previous version of SSL Kill Switch would step in, by patching specific SecureTransport functions to disable TLS validation. Interestingly and as we can see, some of the actual code for the TLS logic is indeed in the libsystem_coretls.dylib library, which is called by SecureTransport. I previously thought that the TLS implementation was all part of SecureTransport.

iOS 10 Stack Trace

On iOS 10, the stack trace for the same breakpoint looks quite different:

More specifically, from top to bottom:

  • tls_handshake_set_callbacks in libsystem_coretls.dylib
  • nw_protocol_coretls_add_input_handler in libnetwork.dylib
  • [More libnetwork.dylib and dispatch calls…]
  • tcp_connection_set_tls in libnetwork.dylib
  • TCPIOConnection::_tlsEnable in CFNetwork
  • [Higher level calls]

As we can see, there are no SecureTransport functions called during the TLS handshake! Instead, some new functions within libnetwork.dylib are used, which then call libsystem_coretls.dylib, similarly to SecureTransport on iOS 9.


Apple has significantly changed the network stack on iOS 10:

  • On iOS 9, an HTTPS connection iniitiated via NSURLSession involves CFNetwork’s SocketStream, SecureTransport and libsystem_coretls.dylib.
  • On iOS 10, the same connection involves CFNetwork’s TCPIOConnection, libnetwork.dylib and libsystem_coretls.dylib

Without access to the source code, it is hard to tell how big of a change this is: is it some kind of refactoring / cleaning up that mainly affects the libraries’ interfaces and flows, or are the implementations also very different?

Also, libnetwork.dylib already existed on iOS 9, but did not have a lot of the functions that are used in iOS 10 for network connections (they are called nw_xxx). For instance, when trying to set a breakpoint for nw_protocol_coretls_add_input_handler on iOS 9, we can see that the function does not exist:

br set -n nw_protocol_coretls_add_input_handler
WARNING:  Unable to resolve breakpoint to any actual locations.

Because SecureTransport is no longer used by higher level APIs (such as CFNetwork or NSURLSession) on iOS 10, patching SecureTransport functions like SSL Kill Switch does has no effect on an App’s TLS connections. This expains why the tool completely stopped working.

I wonder if these changes mean that Apple will eventually deprecate SecureTransport and expose the iOS 10 network/TLS stack as a public API?

Fixing SSL Kill Switch on iOS 10

Now armed with a better understanding of the iOS 10 network stack, I started investigating how TLS validation was done in TCPIOConnectionand libnetwork.dylib, in order to find a way to disable the system’s default TLS validation and any code that customizes it (which is how SSL pinning is done).

When I did it for SecureTransport a few years ago for the previous versions of SSL Kill Switch, the customization mechanism for TLS validation was well-documented as SecureTransport is a public API, and therefore easy to understand.

However, TCPIOConnection, libnetwork.dylib and libsystem_coretls.dylib are all undocumented, private APIs, making this process a lot more time-consuming. Luckily, while playing around with some of the TLS functions in these libraries, I quickly stumbled upon an unexpected solution.

The tls_helper_create_peer_trust in libcoretls_cfhelpers.dylib seemed interesting, as it is used to retrieve the server’s SecTrustRef during the TLS handshake. In the Cocoa world, a SecTrustRef is an object that represents the server’s certificate chain and the policy to use to validate it; it is the main object to use when doing TLS validation. The open-source implementation of the function also made it a lot easier to confirm how it works and what it does:

OSStatus tls_helper_create_peer_trust(tls_handshake_t hdsk, bool server, SecTrustRef *trustRef);

The tls_helper_create_peer_trust function generates the server’s SecTrustRef from a tls_handshake_t object (which represents an ongoing TLS handshake) and puts it in the supplied trustRef argument. The trustRef object can then be used by the caller to do TLS validation and verify the server’s identity.

As a random experimentation, I patched this function (using Cydia Substrate) to make it not do anything:

static OSStatus replaced_tls_helper_create_peer_trust(void *hdsk, bool server, SecTrustRef *trustRef)
    return errSecSuccess;

With the patch applied, the trustRef does not contain anything at the end of the call to tls_helper_create_peer_trust.

I was expecting this change to completely crash the App during the TLS handshake, as whatever code that is doing the TLS validation (probably inside CFNetwork) would get a NULL trust object as the server’s identity (which can never happen), and wouldn’t be able to process further. However, instead of crashing, it completely disabled all TLS validation and pinning, which is exactly what I was trying to do!

It is still unclear to me why this actually works; it seems like the validation logic or callback somehow is ignored when the server’s SecTrustRef is NULL. This is obviously not a vulnerability, as I am injecting code in the App to trigger this behavior, but it is a bit surprising to me. If I ever have the time, I will dig further into this to try to understand what’s going on.

In the meantime enjoy the iOS 10 release!

February 05, 2017
ios, ssl

TrustKit Android Released

A couple days ago, a cowoker and I released TrustKit for Android: an open source library that makes it easy to deploy SSL public key pinning and reporting in any Android App.

This follows the release of TrustKit iOS two years ago, which has now been deployed in many iOS Apps, in order to make their network connections more secure. We hope that TrustKit Android will help developers get more visibliity in their App’s network behavior through TrustKit’s reporting mechanism, and more security via SSL pinning.


TrustKit Android works by extending the Android N Network Security Configuration in two ways:

  • It provides support for the <pin-set> (for SSL pinning) and <debug-overrides> functionality of the Network Security Configuration to earlier versions of Android, down to API level 17. This allows Apps that support versions of Android earlier than N to implement SSL pinning in a way that is future-proof.
  • It adds the ability to send reports when pinning validation failed for a specific connection. Reports have a format that is similar to the report-uri feature of HTTP Public Key Pinning and TrustKit iOS.

For better compatibility, TrustKit will also run on API levels 15 and 16 but its functionality will be disabled.

Getting Started

Check out the the project’s page on GitHub or jump straight into the documentation.

January 25, 2017
android, ssl

iOS 10 Security Changes Slide Deck

I hosted an online Tech Talk on October 19th about the security & privacy changes introduced in iOS 10. I talked about both user-facing and developer-facing changes that I thought were interesting. The last section also provides some guidelines on how to be ready for the App Transport Security requirements that Apple will start enforcing on January 2017.

You can download the slide deck here.

As I was preparing the presentation, I discovered that the Apple documentation about App Transport Security has changed significantly over the last couple months. For example, ATS exemptions for third-party domains (such as NSThirdPartyExceptionAllowsInsecureHTTPLoads) have been removed from the documentation, implying that developers can just use the regular exemptions even for third-party domains.

Hence, the slide deck contains the most up-to-date information about iOS 10 and ATS, but I will update the previous blogs posts with these additional changes.

September 19, 2016