Porting OpenSSL C code to CommonCrypto

Hello AppleEye,

If your code is already working with OpenSSL, why not keep using that? It isn't very big and won't bulk up your app too much. Many apps already include OpenSSL as a static library for doing receipt validation. Apple actually recommends that.

Basically, need to take the OpenSSL API calls like:

SSL_library_init()

,

SSL_connect()

,

SSL_accept()

,

SSL_CTX_use_certificate()

,

CRYPTO_set_id_callback()

, etc., and find CommonCrypto equivilents.

The best resoruce I've found so far:

https://developer.apple.com/reference/security/secure_transport

Secure Transport is Apple’s lowest-level TLS API. It’s not clear to me whether you should use that or a higher-level abstraction, like CFSocketStream (accessible via both the NSStream and CFStream APIs). Secure Transport is super flexible but that flexibility comes at the cost of it being a rather complex API. CFSocketStream follows the standard stream model, where you can open a connection and then read and write data.

My general recommendation is that you use CFSocketStream unless you have a specific reason to require this low-level control. I looked through the list of OpenSSL functions you mentioned and there doesn’t seem to be anything that screams “I need Secure Transport” there (the only one I’m not sure about is

CRYPTO_set_id_callback

You can take a look at the TLSTool sample code for an example of how to set this up.

I was hoping to find some sort of C drop-in OpenSSL to CommonCrypto translation library but it doesn't exist.

This is not surprising. OpenSSL is a complex API with lots of bells and whistle, so creating a compatibility shim from it to any other API would be very hard. Moreover, OpenSSL is not exactly pleasant to use, so if you’re going to go to the trouble of creating a compatibility layer it makes a lot more sense to add an abstraction layer that meets your specific requirements and then implement that layer for the specific platform TLS APIs you care about.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Many apps already include OpenSSL as a static library for doing receipt validation. Apple actually recommends that.

Four things:

• Apple does not recommend OpenSSL for receipt validation. If you look through the Receipt Validation Programming Guide you’ll find that OpenSSL is only mentioned on this page, which makes it pretty clear that this is one example of many possible ways to do local receipt validation.

• This receipt validation example goes out of its way to not use standard platform APIs for obfuscation reasons. The Protect Your Validation Check section says “Inline the code for cryptographic checks instead of using the APIs provided by the system.” This might make sense for receipt validation but makes no sense for TLS.

• The interesting use of OpenSSL within that code is for CMS checking, something that’s not well supported by all Apple platforms [1]. In contrast, there’s strong TLS APIs on all Apple platforms.

• There are negatives to using OpenSSL for your TLS code, namely, that your TLS won’t work like the system’s built-in TLS. There’s two parts to this:

  • Integration — The built-in TLS will use built-in security features, like the keychain and the standard system trust store. You can retrofit these to OpenSSL but it’s extra work.

  • The Future™ — The built-in TLS evolves to include both new features and better security. You don’t get those if you statically link OpenSSL.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

[1] macOS does have

<Security/CMSDecoder.h>

<Security/CMSEncoder.h>

Thanks guys.

Quinn, what is the best informational C resource for this?

Is this it? https://developer.apple.com/reference/security/secure_transport

I've searched Hooli pretty well but find litle references and zero samples so far.

Some SSL usage samples would be great.

A good 3rd party book covering the SSL side CommonCrypto?

Thanks,

what is the best informational C resource for this?

You’re not going to find a lot of documentation about Secure Transport. It’s a very low-level API and we generally encourage folks to use our higher-level TLS APIs.

In terms of sample code the only official Apple sample I’m aware of is SSLSample. This is in the Retired Documents Library because it hasn’t been updated in years. It definitely won’t work out of the box (because the Secure Transport API on iOS is slightly different than the original Secure Transport API on the version of macOS that this was written for) but you should be able to use it to get a general understanding of how things fit together.

In my experience Secure Transport isn’t too hard to use once you have a good understanding of how TLS works. So I recommend you start by reading up on the ins and outs of TLS.

The one complex part of the Secure Transport API is the I/O functions, which I discusse in this post.

A good 3rd party book covering the SSL side CommonCrypto?

This question doesn’t make sense. CommonCrypto is an API for performing various low-level security algorithms, and thus not really related to TLS at all.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

The WWDC 2013 session "Using Receipts to Protect Your Digital Sales" makes many references to OpenSSL. It also recommends static linking. If Apple wants to make specific recommendations for receipt validation, developers would love to hear it. Until that time, many people just choose the path of least resistance - Receigen, which depends on OpenSSL. If I needed more advanced TLS in the Mac App Store, that would be strong incentive to leverage a cross-platform, OpenSSL solution. Apple can feel free to provide other incentives if it so desires.