[swift-server-dev] FIPS certification

Tue Feb 21 14:18:35 CST 2017

Hi Gelareh,

Our current goal is to create an interface such that, if desired, (with minimal work) it is possible to plug in LibreSSL instead of OpenSSL.

3 - This is a topic that was not discussed, but I would not think that it would be on by default.

IMO the question becomes: if the default is not to run in FIPS mode, why is the default backend a FIPS-compliant one?  If there is a consensus that LibreSSL has better security, performance, and response time, while OpenSSL has better compliance, it seems logical to me that LibreSSL would be the default, with OpenSSL/FIPS available as an option to users concerned about compliance, rather than OpenSSL non-FIPS as default, which neither address compliance concerns nor performance/security concerns.

0 - Yes, there are already use cases which require compliance. Server applications, in enterprise or government settings, do require higher compliance levels. We would like to have a solution where enterprise and non-enterprise communities do not diverge since we can definitely benefit from what each sector brings.

Do you represent such a usecase?  Can you tell us about your requirements?

My concern here is that we are creating the appearance that decisions are being made for the benefit of unknown parties with unknown compliance requirements.  I think it would be appropriate if those affected by this issue posted to the list, and explained what their requirements are.  140-1 or 140-2 (or 3 or 4)?  Is this coming from inside counsel or is it regulatory?  Is the party going to take an active role in benefiting the Swift ecosystem?  Is the party unable to afford the four figures to license an actually *good* library such as wolfSSL / MatrixSSL that we could provide a plugin mechanism for?  We cannot know the answers to these questions because the part(ies) are not here.

In the spirit of citing actual use cases: We have a technical requirement not to use OpenSSL (libssl), because from their track record we conclude that the TLAs have binders full of exploits, and because it is impractical to use low-level crypto APIs such as OpenSSL correctly [0].  LibreSSL is a bit better and perhaps the exploits fit in a single binder, but as the API is essentially identical it is still impractical to use correctly, so this isn't enough of a delta for us.  In our internet-facing TLS stack, we need a high-level approach along the lines of s2n.  We are actually running on that in production today, and switching over to even a libssl/LibreSSL stack would be viewed poorly relative to our current practice.  So under that hypothetical I would expect our practice to continue.

2 - Having the flexibility to plug in different security libraries such as OpenSSL and LibreSSL I believe makes our present scenario workable and practical. Of course if we get to the point where we see that is not doable, or that this is not acceptable and there is enough community support, this needs to be addressed. 

I would like to see a backend mechanism flexible enough to get our s2n work upstream (as well as hooks for e.g. wolfSSL backends etc.)  However, s2n is not at all API-compatible with OpenSSL, so considering a plugin model that is designed around OpenSSL-alikes it wouldn't be a possibility.  I think this is not accidental: the breadth of the OpenSSL API [0] and other broad low-level APIs [1] is very quite harmful to security in practice, and so by designing a plugin mechanism with an OpenSSL-alike in mind we are ensuring that users with security as their priority need to camp under a different tent.  IMO that is not in the interests of supporting everyone's requirements.

MongoKitten also does some of its own MD5 checksum hashing. It should really get this from a standard lib - so the “Server APIs” for security shouldn’t just limit itself to TLS but also crypto functionality. 

I did not make this meeting to hear the full argument, but my concern here is that exposing low-level crypto APIs to mere mortals is harmful [0].  To take an example from MongoKitten, they appear to be using MD5 to hash passwords [3], which, if I understand correctly, has been deprecated upstream in mongodb in part due to concerns around MD5 [2].

There's actually a second code smell here: for some reason this password is treated with a fast hashing function, instead of a key-derivation function.  Perhaps the appropriate security guarantees are made elsewhere in the authentication protocol?  But if the hash is merely obfuscatory, why obfuscate at all?

Presumably the answer to these riddles is upstream in mongodb and that project's design choices, entirely out of MongoKitten's hands.  But from a Swift APIsurface POV, we have a responsibility to clear the standard API of footguns, rather than to hand them out.  I think the record shows that wide availability of low-level crypto APIs leads to designs that are at least questionable, if not actual vulnerabilities, and that many common algorithms (MD2-5) are definitively harmful for us to ship.

It would be better to expose high-level APIs to userspace (e.g. like keyczar or NaCl), and encourage working with crypto at that level of abstraction. Or, if that isn't necessary, to ship nothing. But users unlucky enough to need to choose and securely compose underlying crypto primitives should be capable of BYO, as MongoKitten did here.  This is not just me saying this, e.g. [0] [4] [5] [6] [7] etc.
7 - NSS has GPL license which is a problem.

NSS's license is the MPL, not the GPL.  Again it is not clear what party is affected by this, but to cite our usecase, MPL would not be a problem.  NSS is not ideal to us for various reasons, but none of them are licensing.

Drew

[0] https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2009/july/if-youre-typing-the-letters-a-e-s-into-your-code-youre-doing-it-wrong/

[1] http://faq.sealedabstract.com/dont_use_common_crypto/

[2] https://jira.mongodb.org/browse/SERVER-6977

[3] https://github.com/OpenKitten/MongoKitten/blob/63321389439cb3749a3f2648ce2817931408ae0d/Sources/MongoKitten/Auth/Database%2BAuthentication.swift#L176

[4] https://rdist.root.org/2009/06/10/when-crypto-attacks-slides-posted/

[5] http://spar.isi.jhu.edu/~mgreen/CryptoAPIs.pdf

[6] https://courses.csail.mit.edu/6.857/2014/files/18-das-gopal-king-venkatraman-IV-equals-zero-security.pdf

[7] https://github.com/golang/go/issues/5597

On February 20, 2017 at 2:07:40 PM, Gelareh Taban (gtaban at us.ibm.com) wrote:

Hi Drew,

Sorry for the delayed response. I was off for a couple of days enjoying our 30C winter in Austin :-)

Thanks for picking up on the 140 typo - I guess my eyes were error correcting it! I will fix it.

The points you raise here are definitely ones we have tried to address in the working group meetings so far (see https://github.com/swift-server/work-group/tree/master/meetings/security).

The various shortcoming of OpenSSL regarding security and performance were acknowledged but we think there is still good arguments to be made for going with it and in particular an architecture that can take advantage of OpenSSL code (which has compliance) and LibreSSL code (which improves security, performance and response time). Our main concerns were:
- Use case for a server setting
- Flexibility to plug and play library (OpenSSL APIs are largely a superset of the APIs in LibreSSL)
- Apache Licensing
- Prevalence and support on a large number of platforms

I think a lot of the points you raise can be addressed by our plug-n-play architecture that we are interested in. LibreSSL has cleaned up a lot of the extra code and bad defaults, and has improved performance of OpenSSL. This was done whilst reusing a lot of APIs of OpenSSL. Our current goal is to create an interface such that, if desired, (with minimal work) it is possible to plug in LibreSSL instead of OpenSSL.

With these in mind, I will try to answer your questions:
0 - Yes, there are already use cases which require compliance. Server applications, in enterprise or government settings, do require higher compliance levels. We would like to have a solution where enterprise and non-enterprise communities do not diverge since we can definitely benefit from what each sector brings.
1 - Validation is really done for a compliance point of view. It does address certain engineering methodologies, but it does not necessarily detect bugs. That is unarguable.
2 - Having the flexibility to plug in different security libraries such as OpenSSL and LibreSSL I believe makes our present scenario workable and practical. Of course if we get to the point where we see that is not doable, or that this is not acceptable and there is enough community support, this needs to be addressed. I am with you.
3 - This is a topic that was not discussed, but I would not think that it would be on by default. You are right that a large number of users this is not even a consideration. However for it to be even considered for a lot of enterprise and government settings, this option must exist.
4 - You are correct, but this is not on by default, this would impact only use cases which require FIPS.
5 - As far as know, there are no plans for that right now.
6 - Good question. I think our current architecture can to some extent address this, but we should talk about this.
7 - NSS has GPL license which is a problem.

I would really like to have Swift go along a good path for the community and not just a subsection of the community. I am personally really glad you wrote this because I share a lot of your concerns. To have Swift be successful in the server space, we need to make sure that it can handle the server use cases. Hence, the solution that we have come up with right now. If you have alternate ideas or extension, please share!

I am about to send an email our about the next server security meeting group which I sincerely hope you will join 😃

Regards,
Gelareh

 Drew Crawford via swift-server-dev ---02/16/2017 06:07:23 PM---Not to start a large bikeshed, but I was surprised by the following statement in the README: A final

From: Drew Crawford via swift-server-dev <swift-server-dev at swift.org>
To: swift-server-dev at swift.org
Date: 02/16/2017 06:07 PM
Subject: [swift-server-dev] FIPS certification
Sent by: swift-server-dev-bounces at swift.org

Not to start a large bikeshed, but I was surprised by the following statement in the README:
A final motivation in using native libraries is that vendors often go through security certification processes for their own modules and therefore users can get this certification for free. In particular, many use cases that involve government or enterprise data or users, require FIPS 104 compliance or validation. FIPS is a US Government (NIST) cryptographic standard and is a requirement by most government agencies and many enterprises. The process of getting certified is hard, expensive and time consuming and is only done by vendors and large organizations.
This is, as I understand it, the sole argument presented for choosing OpenSSL in the Linux implementation.
First, a clarifying question: are the references to "FIPS 104" in this document actually "FIPS 140"? [0] I am not aware of a "FIPS 104", and google suggests it is a typo [1].

To provide some (possibly biased) background knowledge for the discussion:

* Until recently, the FIPS 140 standard mandated conforming cryptographic libraries make available the DUAL_EC_DRBG cipher with certain unexplained magic numbers.
* The New York Times reports that DUAL_EC_DRBG is actually an NSA backdoor based on information they received from Edward Snowden. [2]
* While NIST did not remove this algorithm from FIPS 140 until 2014, the backdoor was widely suspected among security experts as early as 2007. [3]
* Reuters reports that the NSA paid $10m to a security firm to ensure this backdoored algorithm was the default on various products. [4]
* Separately, OpenSSL's implementation and testing of this algorithm is so poor that it did not even work, accidentally "prevent[ing] all use of the Dual EC DRBG algorithm" [5]
* The "hard, expensive, and time consuming" FIPS validation process never discovered this bug. Upstream says "Not only the original validation (#1747) but many subsequent validations and platforms have successfully passed the [FIPS] algorithm tests several hundred times now. That's a lot of fail... Frankly the FIPS 140-2 validation testing isn't very useful for catching 'real world' problems." [5]
* Because of the enormous expense of re-verifying a one-line patch, OpenSSL did not fix this bug, in part because the FIPS "process forbids modifications of any kind (even to address severe vulnerabilities) without the substantial time and expense of formal retesting and review" [5]
* Stephen Marquess, OpenSSL maintainer, who implemented some of the FIPS code in question, is "on record as stating that FIPS 140-2 validated software is necessarily less secure than its equivalent unvalidated implementation" [7]

With that background, some questions:

0. Can we name any specific Swift users with FIPS requirements? Are those users incapable of taking the their own steps to address their requirements?
1. Regardless of what enterprises require, does anyone believe that FIPS 140 or NIST standards in general actually improve security, or is less than actively harmful? That argument is conspicuously absent from a security proposal.
2. If there were some "certification X" that was required by enterprises but was known to introduce security vulnerabilities for long periods, how bad would things have to be before we told those enterprises to take a hike, and how is that hypothetical distinct from the present situation?
3. Will Swift use OpenSSL in "FIPS mode" (FIPS_mode_set) ? By default? As an option? At all? What percentage of users do we expect to actually use the FIPS module? I am of the impression the vast majority of even OpenSSL users do not use FIPS.
4. Have we considered the performance impact of FIPS? According to various benchmarks [6], OpenSSL in FIPS mode is several orders of magnitude slower than otherwise across effectively all workloads.
5. Is Swift or related projects themselves seeking FIPS certification? What is Swift's policy with respect to exposing "mandated" algorithms to userspace if they are widely expected to contain backdoors or vulnerabilities?
6. What is Swift's policy with respect to responding to vulnerabilities in dependent FIPS-certified modules, when that code cannot be changed without losing the FIPS certification?
7. Why is OpenSSL preferred to other FIPS-validated libraries such as NSS?

Thanks in advance for what is hopefully a productive discussion,

Drew

[0] http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf
[1] http://www.vm.ibm.com/related/tcpip/pm93363.html
[2] https://bits.blogs.nytimes.com/2013/09/10/government-announces-steps-to-restore-confidence-on-encryption-standards/?src=twrhp&_r=0
[3] https://www.schneier.com/blog/archives/2007/11/the_strange_sto.html
[4] http://www.reuters.com/article/us-usa-security-rsa-idUSBRE9BJ1C220131220
[5] http://marc.info/?l=openssl-announce&m=138747119822324&w=2
[6] https://wiki.openwrt.org/doc/howto/benchmark.openssl
[7] http://veridicalsystems.com/blog/secure-or-compliant-pick-one/_______________________________________________
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/20170221/58afaab0/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1__=8FBB0A5EDFFF57FE8f9e8a93df938690918c8FB@
Type: application/octet-stream
Size: 105 bytes
Desc: not available
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20170221/58afaab0/attachment.obj>