FIPS certification


(Drew Crawford) #1

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/


(Gelareh Taban) #2

Hi Drew,

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

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 :smiley:

Regards,
Gelareh

···

From: Drew Crawford via swift-server-dev <swift-server-dev@swift.org>
To: swift-server-dev@swift.org
Date: 02/16/2017 06:07 PM
Subject: [swift-server-dev] FIPS certification
Sent by: swift-server-dev-bounces@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-server-dev


(Gelareh Taban) #3

Hi Drew,

It seems the minutes for the last meeting have not been merged yet.
Here is the PR that has the minutes.
https://github.com/swift-server/work-group/pull/72

Regards,
Gelareh

···

From: Gelareh Taban via swift-server-dev <swift-server-dev@swift.org>
To: Drew Crawford <drew@sealedabstract.com>
Cc: swift-server-dev@swift.org
Date: 02/20/2017 02:09 PM
Subject: Re: [swift-server-dev] FIPS certification
Sent by: swift-server-dev-bounces@swift.org

Hi Drew,

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

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 :smiley:

Regards,
Gelareh

Inactive hide details for Drew Crawford via swift-server-dev ---02/16/2017
06:07:23 PM---Not to start a large bikeshed, but I wDrew 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@swift.org>
To: swift-server-dev@swift.org
Date: 02/16/2017 06:07 PM
Subject: [swift-server-dev] FIPS certification
Sent by: swift-server-dev-bounces@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-server-dev

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


(Drew Crawford) #4

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@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 :slight_smile:

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 :smiley:

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@swift.org>
To: swift-server-dev@swift.org
Date: 02/16/2017 06:07 PM
Subject: [swift-server-dev] FIPS certification
Sent by: swift-server-dev-bounces@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-server-dev


(Fastmail) #5

I have worked with several companies who have refused to use Swift on the grounds that the crypto interface isn't FIPS certified.

It doesn't have to be a good decision to cover one's ass legally.

···

Sent from my iPhone

On 21 Feb 2017, at 21:18, Drew Crawford via swift-server-dev <swift-server-dev@swift.org> wrote:

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@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 :slight_smile:

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 :smiley:

Regards,
Gelareh

<1__=8FBB0A5EDFFF57FE8f9e8a93df938690918c8FB@> 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@swift.org>
To: swift-server-dev@swift.org
Date: 02/16/2017 06:07 PM
Subject: [swift-server-dev] FIPS certification
Sent by: swift-server-dev-bounces@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-server-dev

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


(Drew Crawford) #6

who have refused to use Swift on the grounds that the crypto interface isn't FIPS certified.
My understanding is that both Perfect and Vapor use OpenSSL, which is FIPS-certified in the proper mode. Can you go into more detail about why using Swift in combination with one of those wasn't an option for these entities?

···

On February 21, 2017 at 2:36:33 PM, Swizzlr (me@swizzlr.co) wrote:


(Carl Brown) #7

It looks to me like Vapor (0.18) is now using LibreSSL, although you're right that Perfect was still using OpenSSL last I looked (2.0).

I can't speak to any particular client company or government agency (RFPs being proprietary, etc.) but I am confident that, at times, some random, non-technical person in purchasing is making decisions about which bids to disqualify based on a spreadsheet of features with column names like "FIPS compliance (native)" and "FIPS compliance (optional)". In that event, consultants and firms that want to use Swift to fulfill those contracts would have an easier time if OpenSSL was the default. I've seen too many cases where management just says to purchasing: "Find some criteria to get it down to 3 bidders, I don't want to have to read any more than 3 proposals." When that happens, the more check boxes you have on your spreadsheet line, the better for you.

I would expect that RFPs that are more concerned about actual security rather than the standardized appearance of security would have a deeper understanding of the libraries and trade-offs, and so be better equipped to deal with "we can plug in the SSL library of your choosing". Whereas I would expect the reverse not to be true.

I'm not personally thrilled about the current way large RFPs seem to be handled (especially as an individual (and former government employee) whose Social Security number has been stolen from government servers more than once), but that's the situation that we're in. And all other things being equal, I'd rather Swift be an option for more government systems that may contain my information rather than fewer of them.

-Carl

···

--
Carl Brown
Swift@IBM
W: Carl.Brown1@IBM.com
H: CarlB@pobox.com

Sent from my iPad

On Feb 21, 2017, at 3:00 PM, Drew Crawford via swift-server-dev <swift-server-dev@swift.org> wrote:

On February 21, 2017 at 2:36:33 PM, Swizzlr (me@swizzlr.co) wrote:

who have refused to use Swift on the grounds that the crypto interface isn't FIPS certified.

My understanding is that both Perfect and Vapor use OpenSSL, which is FIPS-certified in the proper mode. Can you go into more detail about why using Swift in combination with one of those wasn't an option for these entities?

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


(Gelareh Taban) #8

I believe Vapor statically link in LibreSSL and based on last meeting Logan
said their decision was based on:
1 - simpler instruction for compiling code (since they were statically
linking)
2 - better reputation for performance and security.

However the conclusion the group came to was that:
- Plug-n-play supports flexibility for OpenSSL and LibreSSL
- OpenSSL is still more prevalent and comes out of the box with Ubuntu and
most other Linux distros.
- Having a compliance tick mark helps Swift adoption in the larger
ecosystem, esp if similar guarantees can be made on both macOS and Linux
platforms.
- It is possible that in the future, if Swift decides on adding security
libraries to its tool chain, other plans can be made.

Regards,
Gelareh

···

From: Drew Crawford <drew@sealedabstract.com>
To: Swizzlr <me@swizzlr.co>
Cc: Gelareh Taban/Austin/IBM@IBMUS, swift-server-dev@swift.org
Date: 02/21/2017 03:00 PM
Subject: Re: [swift-server-dev] FIPS certification

On February 21, 2017 at 2:36:33 PM, Swizzlr (me@swizzlr.co) wrote:

      who have refused to use Swift on the grounds that the crypto
      interface isn't FIPS certified.

My understanding is that both Perfect and Vapor use OpenSSL, which is
FIPS-certified in the proper mode. Can you go into more detail about why
using Swift in combination with one of those wasn't an option for these
entities?


(Drew Crawford) #9

at times, some random, non-technical person in purchasing is making decisions about which bids to disqualify based on a spreadsheet of features with column names like "FIPS compliance (native)" and "FIPS compliance (optional)". In that event, consultants and firms that want to use Swift to fulfill those contracts would have an easier time if OpenSSL was the default.
per Gelareh's comment, FIPS mode would not be the default:

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.
My argument is essentially: if the usage is so low that FIPS compliance will not be the default, and if OpenSSL is chosen for FIPS compliance, OpenSSL should not be the default either. Do you believe that there exists a large class of RFPs for which A) someone knows to enable FIPS mode, and B) someone does not know to choose OpenSSL? I believe that is an empty set.

···

On February 21, 2017 at 3:50:00 PM, Carl Brown (carlb@pobox.com) wrote:


(Drew Crawford) #10

- Having a compliance tick mark helps Swift adoption in the larger ecosystem, esp if similar guarantees can be made on both macOS and Linux platforms.
I may be misreading something, but I think this guarantee is not even made.

Per [0], the validation is issued for various configurations with names like "Ubuntu 10.04 running on Intel Pentium T4200 (gcc Compiler Version 4.1.3)" which is, as far as I'm aware, not a supported configuration for Swift. Which of the validated configurations do we intend to support?

Second, my understanding is that the FIPS-validated OpenSSL is not even packaged by e.g. Ubuntu, in part due to the backdoor concerns I raised earlier [1]. Do we intend to package the FIPS module ourselves and distribute to the supported platforms? Or what exactly is a user's path to running a FIPS-validated module? Because `apt-get install openssl`does not tick the box.

[0] http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#1747

[1] https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/95001

Drew

···

On February 21, 2017 at 3:59:13 PM, Gelareh Taban (gtaban@us.ibm.com) wrote: