[swift-server-dev] Crypto Library

Tue Nov 8 09:45:50 CST 2016

Whilst there's legitimate debate on the use of C vs. Swift for HTTP 
parsing, I think the situation for the security libraries in general is 
more clear.

We've effectively got four choices on how to do the underlying 
implementation of the security APIs:
Use OpenSSL/LibreSSL everywhere
The challenge his is iOS devices, where there is no support for 
OpenSSL/LibreSSL. There's likely also an argument that using 
OpenSSL/LibreSSL will be a regressive move for macOS users vs. the Apple 
libraries that have been optimized for the platform. Additionally there 
may be a granularity issue - we'd the Apple libraries are deliberately 
broken into three libraries and we'd need to reflect that from 
OpenSSL/LibreSSL. I think that means we at least have to have a "hybrid" 
model of using the Apple libraries on macOS/iOS, and OpenSSL/LibreSSL 
elsewhere
Use the Apple security libraries everywhere
This three libraries are a significant body of work, and based on the 
effort required to port libdispatch to Linux, I would estimate that a 
considerable amount of porting work. There would then be secondary 
challenges on how we respond to security vulnerabilities on the new 
platforms, and the effort and cost of trying to get FIPS compliance for 
the new libraries on each platforms
Use a hybrid of Apple security libraries on macOS/iOS and OpenSSL/LibreSSL 
elsewhere
This leverages existing "defacto standard" libraries on each platform, 
where things like FIPS compliance certification already exists, and teams 
already have a track record of responding to security vulnerabilities. 
There is a challenge though on how we isolate/abstract the user away from 
the differences between the libraries - particularly for things like 
certificate handling and configuration.
Create a pure-Swift implementation
The implementation of OpenSSL is ~350K lines of code, which is a sizeable 
amount of function to implement, and most importantly, to get right and do 
rigorous security vulnerability testing for. Once done, we will then have 
to react rapidly to any reported vulnerabilities and do the full set of 
work and cost to get FIPS compliance certification. 

For me, this points to option #3 as the most viable solution - and 
therefore the first that we should investigate.

Chris

From:   Bill Abt via swift-server-dev <swift-server-dev at swift.org>
To:     Swift Server Dev <swift-server-dev at swift.org>
Date:   07/11/2016 18:48
Subject:        Re: [swift-server-dev] Crypto Library
Sent by:        swift-server-dev-bounces at swift.org

We experimented with various different approaches when doing the lower 
levels of Kitura.  Ultimately, we chose to use CommonCrypto on macOS and 
libcrypto (from OpenSSL) on Linux for the crypto portion.  You can see the 
implementation (which works on both macOS and Linux) at 
https://github.com/IBM-Swift/BlueCryptor.  As far as the securing sockets, 
we chose to go with Apple Secure Transport on macOS and OpenSSL on Linux. 
This implementation can be found at 
https://github.com/IBM-Swift/BlueSSLService.  The BlueCryptor package can 
be used by virtually Swift application.  The BlueSSLService, however, is 
an add-on to and dependent on BlueSocket, the underlying network layer for 
Kitura.

In my opinion, using the Security framework on macOS is fine but to get 
the “beast” running on Linux may be very, very problematic.  The 
underlying codebase is massive and there are bits and pieces that are 
missing and would have to be re-implemented.  Another factor that led us 
to not use the Security framework was relatively sparse documentation. 
CommonCrypto is a much smaller subset as is Secure Transport and the 
mapping between them and librcrypto and OpenSSL is much cleaner and 
straight forward.  Plus, as others have pointed out, an implementation 
taking this approach doesn’t have to worry so much about FIPS 
certification since the underlying platform implementation are already 
certified.

On Nov 7, 2016, at 10:31 AM, Zach Drayer via swift-server-dev <
swift-server-dev at swift.org> wrote:

On Nov 7, 2016, at 2:45 PM, Helge Heß via swift-server-dev <
swift-server-dev at swift.org> wrote:

On 07 Nov 2016, at 13:48, Zach Drayer <zachary.drayer at gmail.com> wrote:
On Nov 7, 2016, at 11:20 AM, Helge Heß via swift-server-dev <
swift-server-dev at swift.org> wrote:
P.S.: As a sidenote, can’t someone (hm hm, who would come to mind?) 
sponsor the CryptoSwift guy to do a java.security like Security standard 
framework (which includes TLS)? That would be pretty cool :-)

Instead: while in C, Security.framework, and CommonCrypto.framework from 
 are both fully open source, and battle-hardened.

Do they provide a clean Linux story too? (.framework in the name kinda 
suggests they don’t :-)

Do they work with non-blocking I/O? The API read/write/handshake API 
suggests that they may not?

Looks like the approach people currently use is either Security.framework 
on Darwin and Open/LibreSSL on other platforms, or using OpenSSL on both. 
Some even forking OpenSSL.

Good question. My assumption was “yes, of course”, but, it looks like that 
isn’t correct in the way I expected it to be.

CommonCrypto looks like it makes some assumptions about Darwin (e.g. 
importing TargetConditionals or Availability.h) but looking one level 
deeper, we find `corecrypto` at the bottom of 
https://developer.apple.com/security/ that is also open source, is what 
underlies CommonCrypto + Security, and, has the necessary `#if`s to build 
on Linux (even if it is lacking a Makefile at the moment).

This is one of (rare) the cases where practicality and strongly deferring 
to the thing that already exists seem to be the safe option (and not only 
in opinion).

This is all true, but then someone also thought it makes sense to have 
Security.framework despite OpenSSL being available. Or java.security. Or 
Windows SChannel/security. Just saying …

The thing which makes a pure-Swift thing attractive is that it would be 
cross platform and readily available. The C libs are really diverse 
between the platforms and forking OpenSSL into an embedded module is not 
exactly 1337 either.

No disagreement that there are a number of benefits to living in a pure 
Swift world, but as mentioned earlier: this may not be possible yet. There 
is little point in providing a security/crypto library that can’t be 
trusted — and with cryptography, the requirement for trust extends far 
beyond “does it compile?, or even “do all the tests pass?”. We don’t want 
another heartbleed, or a predictable PRNG (
https://github.com/g0tmi1k/debian-ssh).

But, I don’t know. Maybe the solution isn’t corecrypto, but is 
LibreSSL/OpenSSL, or, something else. Maybe adding compiler support for 
Crypto tasks is already done (or easy enough to do) and my argument is 
moot. Thats why we’re having this discussion, right?

Anyway, (to me) the more interesting questions that we can talk about are 
over API:
- what constructs are needed (bignum? secure random? hmac? checksumming? 
key derivation? wrapping a socket in a big TLS hug?)

The thing I need and which is a little awkward to get is async TLS, both 
client and server. I started working on an OpenSSL BIO and see whether I 
can get that running on top of GCD, looks like it should be possible.

For the hashes that I needed so far (just MD5 and SHA1) I use CryptoSwift.

These seem like excellent use cases to consider, thank you for bringing 
them up! Reading through https://swift.org/server-apis/, the section on 
"Security and Encryption”, definitely indicates that this is the right 
place to talk about these needs.

-z

_______________________________________________
swift-server-dev mailing list
swift-server-dev at swift.org
https://lists.swift.org/mailman/listinfo/swift-server-dev
_______________________________________________
swift-server-dev mailing list
swift-server-dev at swift.org
https://lists.swift.org/mailman/listinfo/swift-server-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20161108/e4040bb6/attachment.html>