|
|
| (30 intermediate revisions by 6 users not shown) |
| Line 1: |
Line 1: |
| = Fedora Crypto Consolidation - Background = | | == History == |
|
| |
|
| Wouldn't it be neat if you could obtain a digital certificate from a CA using Firefox, and then immediately turn around and use it to ssh to another machine? Wouldn't you like to be able to turn off SSL2 in a central control panel, and be guaranteed that all apps on your desktop would obey that decision? Wouldn't it be cool if every app noticed that you inserted a smart card, and immediately took advantage of it for crypto operations like signing email or setting up IPSec connections? When customers asked if Fedora or its derivatives were FIPS 140 validated, wouldn't it be great to answer an unqualified "Yes"?
| | Over the years there were attempts to consolidate cryptographic libraries in Fedora. The previous crypto consolidation effort is no longer pursued by the Fedora project. This page is retained as historical record, and to provide a simple guideline in selecting a crypto back-end when choice exists. |
| | [https://fedoraproject.org/wiki/FedoraCryptoConsolidationBackup Proceed to the historical record of the Crypto Consolidation Project]. |
|
| |
|
| Of course it would!
| | == Selecting a crypto library for Fedora == |
|
| |
|
| We have an opportunity to address the above issues and to exhibit leadership in the area of open source security by embarking on an effort to consolidate and rationalize the cryptography in Fedora. This document discusses some of the issues with our current situation, and presents a roadmap for making the above wishful thinking into reality.
| | For applications which may provide multiple cryptographic back-ends, our recommendation is to utilize the back-end preferred by the upstream project/developer, as long as it does integrate with the Fedora system, that is, following [https://docs.fedoraproject.org/en-US/packaging-guidelines/CryptoPolicies/ Crypto Policies], [[Features/SharedSystemCertificates]] and |
| | [https://docs.fedoraproject.org/en-US/packaging-guidelines/Pkcs11Support/ PKCS#11 support]. |
|
| |
|
| = Present situation =
| | The Fedora base image effort for docker and other containers, tries to ship only OpenSSL, so for applications targeting the minimal base image, OpenSSL is the recommended library. |
|
| |
|
| Cryptographic services within the Linux platform are provided by many
| | If still in doubt on which library to chose there are comparisons of TLS and crypto libraries available to assist in deciding. |
| different packages. These packages attempt to do the same, or similar tasks but
| | * [https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations Wikipedia TLS lib comparison] |
| are incompatible with one another. Having multiple options causes confusion for
| | * [https://en.wikipedia.org/wiki/Comparison_of_cryptography_libraries Wikipedia low-level crypto lib comparison] |
| ISV developers and complicates legal tasks such as security and export compliance
| | * [https://curl.haxx.se/docs/ssl-compared.html Comparison for curl] |
| filings.
| |
| Operating systems from other vendors such as Microsoft and Apple were either
| |
| designed around a single cryptographic framework or transitioned to one a number
| |
| of years ago.
| |
|
| |
|
| The following sections describe the present situation in more detail. | | == Selecting a crypto library for Red Hat Enterprise Linux == |
| | When considering integration with Red Hat Enterprise Linux, it is recommended to utilize a library from the base crypto backends, as they are guaranteed to pass all relevant crypto certifications (i.e., FIPS-140-2). The base crypto backends are (in no particular order): |
|
| |
|
| == Current libraries ==
| | * [https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS NSS] |
| | * [https://www.gnutls.org GnuTLS] |
| | * [https://www.openssl.org OpenSSL] |
| | * [https://gnupg.org/software/libgcrypt/index.html libgcrypt] |
|
| |
|
| Fedora ships with numerous cryptographic libraries, including:
| | Although nettle is available as a cryptographic back-end in Red Hat Enterprise Linux, it is not recommended to use directly, as it is considered an internal GnuTLS API and [https://access.redhat.com/articles/rhel-abi-compatibility there is no API or ABI stability guarantee]. |
| # [http://developer.mozilla.org/en/docs/NSS NSS]
| |
| # OpenSSL
| |
| # libgcrypt
| |
| # GnuTLS
| |
| # Kernel
| |
| # libcrypt.so (from glibc)
| |
| # libssh2
| |
| # nettle
| |
| # python-crypto
| |
| # BeeCrypt
| |
|
| |
|
| Further, there is cryptography in the release that does '''not''' rely on any of these well-known packages.
| | * [https://access.redhat.com/articles/3655361 Link to RHEL8 crypto components] |
| | * [https://access.redhat.com/solutions/307523 Link to RHEL FIPS140-2 certificates] |
|
| |
|
| Examples:
| | === Selecting crypto backend for other languages === |
| # The Samba source tree includes Heimdal, which includes implementations of AES, DES3, etc.
| |
| # The MIT krb5-devel package includes libdes425.so.
| |
|
| |
|
| This level of complexity has a number of costs that we need to manage, including code maintenance, and support.
| | For other language bindings, we recommend utilizing wrappers over the base crypto libraries. Some examples: |
|
| |
|
| Today, since there is no generally agreed upon central crypto library, developers building new apps use the crypto library they have heard most about, or already know. This is a reasonable thing to do, but contributes to the fragmentation of the overall system.
| | <!-- * Java: [http://openjdk.java.net/ the openjdk platform] wraps over NSS --> |
| | * Python: the [https://cryptography.io/ python-cryptography package] wraps over OpenSSL |
|
| |
|
| Most apps end up using their own key/credential stores and lack integration with other apps that might benefit from a shared approach.
| |
|
| |
|
| Apps tend to present their own security UI and manage their own preferences and settings. This means UI between apps is inconsistent, which drives up training, IS training costs, etc. There is no way to “Turn off SSL2 for all apps” in Fedora, or any way to “Use the corporate OCSP server for all apps” with a single click.
| | [[Category:Encryption]] |
| | |
| == FIPS 140 ==
| |
| Products that perform cryptographic operations must be formally validated against the FIPS 140 specifications in order to be sold to the US Government. In addition, some businesses use FIPS 140 as a measure of quality of a given technology.
| |
| | |
| NSS has been awarded FIPS 140 certificates many times.
| |
| | |
| FIPS validation is also expensive and time consuming. The time it takes to get validations have also been steadily increasing. Multiplying the cost of these validations over even a handful of toolkits would be prohibitive.
| |
| | |
| Red Hat sponsored validation of NSS, OpenSSL, Kernel, libgcrypt, and OpenSSH in Red Hat Enterprise Linux 5 and 6.
| |
| | |
| == Other Operating Systems ==
| |
| | |
| Other operating systems already have some degree of crypto consolidation that meets many of our high level goals.
| |
| | |
| === Apple Mac OS X ===
| |
| | |
| Apple's cryptographic framework uses CDSA interfaces, wrapped by more Mac-like interfaces. They use OpenSSL for TLS, and NSS for S/MIME.
| |
| | |
| OSX apps inherit not only fixes and enhancements in core cryptography, but also fixes and enhancements in UI. Apple has shown how Microsoft Word can take advantage of new smart card technologies and UI simply by upgrading the OS.
| |
| | |
| The Macintosh has had a centralized keychain for storing application passwords since at least 1994.
| |
| | |
| === Microsoft Windows XP, Vista ===
| |
| | |
| Microsoft has probably gone the furthest in achieving the vision of having a single, well-integrated library that all applications can take advantage. Their Cryptographic API (CAPI) is part of core OS, providing cryptography, key management, smartcard support, common UI, etc.
| |
| | |
| = Feature Descriptions =
| |
| | |
| This section lists the features required to simplify and rationalize the cryptography in Fedora.
| |
| | |
| == Medium Term Goals ==
| |
| | |
| The libraries that should be preferred instead of arbitrary other crypto stacks are (in the order of the preference):
| |
| # NSS
| |
| # GNUTLS (with nettle as crypto backend, but nettle never used directly by applications)
| |
| # OpenSSL
| |
| # libgcrypt
| |
| | |
| == Future Goals ==
| |
| The future high-level goals should be simple to express (even if the work required is not small):
| |
| # There will be one set of FIPS-validated libraries that all apps in Fedora use for all user-space cryptographic operations
| |
| # Kernel crypto will be separate, but will require integration with user-space crypto keys and preferences. The kernel will need to use a user's private keys (possibly on a smartcard) to set up an IPSec session, for example.
| |
| # There will be one keystore per OS user, shared between applications.
| |
| # There will be a system-wide keystore that will allow admins to set up global support for trusted root certificates (such as the corporate root).
| |
| # Apps will share common configuration settings. If you turn off SSL2, it is off for all apps.
| |
| # There will be one UI framework for error messages, certificate management, key-ring management, password entry, etc.
| |
| # There will be a simple way of entering into "FIPS mode" where only FIPS 140 specified and mandated cryptography is possible. This feature will be primarily used by U.S. Government customers, and some financial industry customers.
| |
| | |
| == Shared databases (key and cert) ==
| |
| | |
| Applications need to share certificate and key stores for performing crypto operations. They also need to share certificate stores (including smartcards) for trust.
| |
| | |
| Examples include:
| |
| # Get a cert using Firefox, use it in SSH
| |
| # Plug in a smartcard, use it to decrypt your hard drive and to sign email
| |
| # Use it to login to your corporate VPN
| |
| # Use your cert to login to a web server
| |
| # Mark your corporate root as trusted, and all apps then trust that root.
| |
| | |
| == Shared configurations ==
| |
| Some configurations should apply to all apps on the system (at least by default). For example:
| |
| # Turning specific cipher suites on/off
| |
| # Turning on/off RSA, MD5, etc.
| |
| # Turning OCSP on/off
| |
| # Setting the OCSP proxy server
| |
| # Setting behavior when the current time is past the nextUpdate time in a CRL (run anyway, disallow connections, etc.)
| |
| | |
| Applications should be able to inherit these global settings.
| |
| | |
| These settings should have GUI and CLI interfaces. They should also be in a flat file that can be edited by hand if needed.
| |
| | |
| Planning for this is still in progress.
| |
| | |
| == Common UI framework ==
| |
| The OS needs to provide a common high-quality user interface for crypto-related tasks (including certificate/token management and prompting about bad SSL certificates) that all applications will use. This will be consistent with OSX and Windows and will reduce development complexity, user training, and support costs. Improvements to the UI can be shipped as a single update, and the improvements will be visible in all applications.
| |
| | |
| Currently, each application is left to to provide its own UI. Firefox and Thunderbird are using [http://www.mozilla.org/projects/security/pki/psm/ Mozilla PSM] ([http://mxr.mozilla.org/mozilla-central/source/security/manager/ source]), a relatively complete and mature package that includes the certificate manager and "Add Security Exception" dialogs. In other applications, the crypto UI tends not to receive the same level of attention and is inferior or nonexistent.
| |
| | |
| One option would be to standardize on PSM. This would go nicely with the choice of NSS.
| |
| | |
| Microsoft Vista has an important feature that is closely related to their Cardspace technology. When the user visits a web site that asks for a Cardspace card, the UI changes such that the card selector takes over the UI. Microsoft has made it impossible for normal userspace apps to replicate this behavior. Today, this type of feature isn't possible using X-Windows. There are efforts to create such a trusted path, and we'll need to evaluate them.
| |
| | |
| = Plan Forward =
| |
| == Technology selection ==
| |
| To accomplish the goals of this effort, we will be using the NSS crypto libraries. NSS has been awarded FIPS 140 certificates four times, It is used in client applications like Firefox and Thunderbird, and in server applications such as Fedora Directory Server.
| |
| | |
| Beyond FIPS 140 validation, we're going to rely on NSS for smart card support, hardware security modules (HSM) support for SSL acceleration and key protection, S/MIME, and OCSP support. Those feature either are less mature in the other toolkits, or don't exist. That's not to say that those toolkits are bad, only that they don't meet the needs of this effort.
| |
| | |
| Other toolkits such as OpenSSL and GnuTLS have some of these features, but none matches the all the requirements of this project (see CryptoConsolidationEval for more info).
| |
| | |
| == Packages to NSS-enable ==
| |
| # Apache: Done ([http://directory.fedoraproject.org/wiki/Mod_nss mod_nss] )
| |
| # PAM pkcs11: Done ([http://www.opensc-project.org/pipermail/opensc-devel/2007-June/010005.html pam_pkcs11 0.6] )
| |
| # stunnel
| |
| # CURL: Done
| |
| # wget
| |
| # python bindings: Done [http://fedoraproject.org/wiki/Features/PythonNSS python-nss]
| |
| # RPM
| |
| # OpenLDAP client SDK and server (done for Fedora 14 and later)
| |
| # Samba
| |
| # MIT Kerberos (in process)
| |
| # NetworkManager
| |
| # OpenOffice
| |
| # postfix
| |
| # tog-pegasus
| |
| | |
| A complete list of packages and the current state of NSS enabling can be found on the [[CryptoConsolidationScorecard]].
| |
| | |
| == Conversion Tools ==
| |
| | |
| One method of porting an application to NSS is to do a direct conversion of openSSL calls to NSS calls manually. One example of this is the conversion of the Apache module mod_ssl to [http://directory.fedoraproject.org/wiki/Mod_nss mod_nss]. Another example is libcurl which recently accepted a compile-time option to use NSS. This library already had an abstraction layer that supported openSSL and gnuTLS so adding another option was straightforward.
| |
| | |
| This direct conversion method requires a certain level of familiarity with both the openSSL API and more importantly, familiarity with NSS. The two APIs are similar but take very different approaches to some key areas such as certificate and key management and Certificate Revocation Lists (CRLs). Without knowing how these work in NSS can make a direct port difficult.
| |
| | |
| To address the shortcomings of the direct conversion method we've started work on a source-code level compatibility library, [[nss_compat_ossl]]. This library implements portions of the openSSL API using NSS. The purpose is to limit changes within the target application. It is not expected that no changes will be required in the target application. You can find more information on this library at [[nss_compat_ossl]]. The use of the compatibility library has the added advantage of creating a simplier module for upstream suppliers to accept. Not every upstream project would have the same needs a distribution, and may have valid reasons for continuing to want to use other crypto libraries.
| |
| | |
| == NSS Changes ==
| |
| | |
| NSS is currently adding 2 new major features: [http://wiki.mozilla.org/NSS:Roadmap#libpkix:_an_RFC_3280_Compliant_Certificate_Path_Validation_Library PKIX processing] and
| |
| [http://wiki.mozilla.org/NSS:Roadmap#SQLite-Based_Multiaccess_Certificate_and_Key_Databases shared database support] .
| |
| | |
| Once PKIX is complete, all NSS applications will be able to process modern PKI changes based on bridge CA's. These PKIs have been running inside academia and governments for 6-7 years now and are starting to spread into industry. Proprietary OS's have been able to handle PKIX chains for quite a while, but up until now, only very specialized open source applications have been able to use such chains.
| |
| | |
| Shared database support is a major component in impementing a common world where all your certificates are available to every application. It illustrates the power of using a single toolkit.
| |
| | |
| Conversion to NSS will automatically add these features to those applications that convert.
| |
| | |
| =Links=
| |
| Here are some links to related pages:
| |
| # [[CryptoConsolidationEval|Crypto Consolidation Evaluation]]
| |
| # [[CryptoConsolidationScorecard|Crypto Consolidation Scorecard]] to keep track work in progress
| |
| # [[rhbug:333741|Fedora tracking bug]]
| |
| # [http://old-en.opensuse.org/SharedCertStore SharedCertStore discussion on OpenSuse wiki]
| |
| # [http://lists.debian.org/debian-devel/2011/04/msg01062.html Debian-Devel discussion on Crypto Consolidation]
| |
