<font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">We've effectively got four choices on
how to do the underlying implementation of the security APIs:</font>
<ol>
<li value=1><font size=2 face="sans-serif">Use OpenSSL/LibreSSL everywhere<br>
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</font>
<li value=2><font size=2 face="sans-serif">Use the Apple security libraries
everywhere<br>
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</font>
<li value=3><font size=2 face="sans-serif">Use a hybrid of Apple security
libraries on macOS/iOS and OpenSSL/LibreSSL elsewhere<br>
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.</font>
<li value=4><font size=2 face="sans-serif">Create a pure-Swift implementation<br>
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. </font></ol>
<br><font size=2 face="sans-serif">For me, this points to option #3 as
the most viable solution - and therefore the first that we should investigate.</font>
<br>
<br>
<br><font size=2 face="sans-serif">Chris<br>
</font>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">Bill Abt via swift-server-dev
<swift-server-dev@swift.org></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">Swift Server Dev <swift-server-dev@swift.org></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">07/11/2016 18:48</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">Re: [swift-server-dev]
Crypto Library</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Sent by:
</font><font size=1 face="sans-serif">swift-server-dev-bounces@swift.org</font>
<br>
<hr noshade>
<br>
<br>
<br><font size=3>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 </font><a href="https://github.com/IBM-Swift/BlueCryptor"><font size=3 color=blue><u>https://github.com/IBM-Swift/BlueCryptor</u></font></a><font size=3>.
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 </font><a href="https://github.com/IBM-Swift/BlueSSLService"><font size=3 color=blue><u>https://github.com/IBM-Swift/BlueSSLService</u></font></a><font size=3>.
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.</font>
<br>
<br><font size=3>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.</font>
<br>
<br><font size=3>On Nov 7, 2016, at 10:31 AM, Zach Drayer via swift-server-dev
<</font><a href="mailto:swift-server-dev@swift.org"><font size=3 color=blue><u>swift-server-dev@swift.org</u></font></a><font size=3>>
wrote:</font>
<br>
<br>
<br><font size=3>On Nov 7, 2016, at 2:45 PM, Helge Heß via swift-server-dev
<</font><a href="mailto:swift-server-dev@swift.org"><font size=3 color=blue><u>swift-server-dev@swift.org</u></font></a><font size=3>>
wrote:</font>
<br>
<br><font size=3>On 07 Nov 2016, at 13:48, Zach Drayer <</font><a href=mailto:zachary.drayer@gmail.com><font size=3 color=blue><u>zachary.drayer@gmail.com</u></font></a><font size=3>>
wrote:</font>
<br><font size=3>On Nov 7, 2016, at 11:20 AM, Helge Heß via swift-server-dev
<</font><a href="mailto:swift-server-dev@swift.org"><font size=3 color=blue><u>swift-server-dev@swift.org</u></font></a><font size=3>>
wrote:</font>
<br><font size=3>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 :-)</font>
<br>
<br><font size=3>Instead: while in C, Security.framework, and CommonCrypto.framework
from are both fully open source, and battle-hardened.</font>
<br><font size=3><br>
Do they provide a clean Linux story too? (.framework in the name kinda
suggests they don’t :-)<br>
<br>
Do they work with non-blocking I/O? The API read/write/handshake API suggests
that they may not?<br>
<br>
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.</font>
<br>
<br><font size=3>Good question. My assumption was “yes, of course”, but,
it looks like that isn’t correct in the way I expected it to be.</font>
<br>
<br><font size=3>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 </font><a href=https://developer.apple.com/security/><font size=3 color=blue><u>https://developer.apple.com/security/</u></font></a><font size=3>
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).</font>
<br>
<br><font size=3>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).</font>
<br><font size=3><br>
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 …<br>
<br>
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.</font>
<br>
<br><font size=3>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 (</font><a href="https://github.com/g0tmi1k/debian-ssh"><font size=3 color=blue><u>https://github.com/g0tmi1k/debian-ssh</u></font></a><font size=3>).</font>
<br>
<br><font size=3>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?</font>
<br>
<br><font size=3>Anyway, (to me) the more interesting questions that we
can talk about are over API:<br>
- what constructs are needed (bignum? secure random? hmac? checksumming?
key derivation? wrapping a socket in a big TLS hug?)</font>
<br><font size=3><br>
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.<br>
<br>
For the hashes that I needed so far (just MD5 and SHA1) I use CryptoSwift.</font>
<br>
<br><font size=3>These seem like excellent use cases to consider, thank
you for bringing them up! Reading through </font><a href="https://swift.org/server-apis/"><font size=3 color=blue><u>https://swift.org/server-apis/</u></font></a><font size=3>,
the section on "Security and Encryption”, definitely indicates that
this is the right place to talk about these needs.</font>
<br>
<br><font size=3>-z</font>
<br>
<br><font size=3>_______________________________________________<br>
swift-server-dev mailing list</font><font size=3 color=blue><u><br>
</u></font><a href="mailto:swift-server-dev@swift.org"><font size=3 color=blue><u>swift-server-dev@swift.org</u></font></a><font size=3><br>
</font><a href="https://lists.swift.org/mailman/listinfo/swift-server-dev"><font size=3>https://lists.swift.org/mailman/listinfo/swift-server-dev</font></a>
<br><tt><font size=2>_______________________________________________<br>
swift-server-dev mailing list<br>
swift-server-dev@swift.org<br>
</font></tt><a href="https://lists.swift.org/mailman/listinfo/swift-server-dev"><tt><font size=2>https://lists.swift.org/mailman/listinfo/swift-server-dev</font></tt></a><tt><font size=2><br>
</font></tt>
<br>
<br>