System-wide crypto policy
Summary
Unify the crypto policies used by different applications and libraries. That is allow setting a consistent security level for crypto on all applications in a Fedora system. The implementation approach will be to initially modify SSL libraries to respect the policy and gradually adding more libraries and applications.
Owner
- Name: Nikos Mavrogiannopoulos
- Email: nmav@redhat.com
- Release notes owner:
Current status
Detailed Description
The idea is to have some predefined security levels such as LEGACY, DEFAULT and FUTURE. These will be the security levels that the administrator of the system will be able to configure by modifying /usr/lib/crypto-profiles/config /etc/crypto-profiles/config
and being applied after executing update-crypto-profiles. (Note: it would be better to have a daemon that watches those files and runs update-crypto-profiles automatically)
After that the administrator should be assured that any application that uses the system settings will follow a policy that adheres to the configured profile.
Ideally setting a profile should be setting:
- the acceptable TLS/SSL (and DTLS) versions
- the acceptable ciphersuites and the preferred order
- acceptable parameters in certificates and key exchange, i.e.:
- the minimum acceptable size of parameters (DH,ECDH,RSA,DSA,ECDSA)
- the acceptable elliptic curves (ECDH,ECDSA)
- the acceptable signature hash functions
- other TLS options such as:
- safe renegotiation
An idea of how this will be implemented is to have each Fedora application's configuration file or compilation option will set a system default option. That is for example for applications that use GnuTLS or OpenSSL a priority string or cipher named "SYSTEM". Then the shipped library will make sure that once the "SYSTEM" option is encountered the preconfigured system settings will be applied. When an application doesn't specify any default settings the system settings should apply.
The preconfigured settings for each SSL library will be auto-generated from the default profile in /etc/crypto-profiles/generated/$(libname)/config
Benefit to Fedora
With this change a Fedora system will have a consistent way of setting a default security profile for all applications.
Scope
There are changes required in GnuTLS, OpenSSL and NSS libraries. On a second phase non-SSL crypto libraries could use these settings.
- Proposal owners:
- In GNUTLS the "@SYSTEM" priority string will be used to specify the system ciphers. Any applications using gnutls_set_default_priority() will also use the system ciphers.
- In OpenSSL the cipher string "PROFILE=SYSTEM" will be used to specify the system ciphers. Any applications not explicitly specifying ciphers will use the system ciphers.
- NSS, doesn't support yet similar configuration. Adding support is work in progress.
After that a mechanism to specify crypto policies for Fedora has to be devised, as well as the extraction to each libraries' settings.
- Other developers:
Packages that use SSL crypto libraries should, after the previous change is complete, replace the default cipher strings with the ones described above. In F21 the number of packages converted will be a selected small set to prevent an overwhelming flow of bugs in case of breakage, and in F22 more packages will be converted. After F21 bugs will be reported to packages using the crypto libraries (detected possibly using repoquery).
A developer could test whether the system crypto policy is being applied using the following steps:
- Test ordinary operation
- Change /etc/crypto-policies/config to FUTURE
- run update-crypto-policies
- Test whether the connection to a public server works (e.g., www.amazon.com). It should have failed as the FUTURE level disallows SHA-1 which is used by most servers today.
- Release engineering:
This feature does not require coordination with release engineering.
- Policies and guidelines:
After the change is complete the packaging guidelines, should mention abouve replacing the default cipher strings with "SYSTEM". This of course need not affect programs that do not have a mechanism for setting ciphers/modes that is already in wide use (e.g., browsers). It mostly targets applications that use some reasonable (or unreasonable) defaults and the user/administrator has little control of them. The high level descriptions of the selected levels follows.
LEGACY: A level that will ensure maximum compatibility with legacy systems. It should provide at least 64-bit security and include RC4 and MD5 (for signatures) MACs: MD5, SHA1+ Curves: All supported Signature algorithms: must use SHA-1 hash or better (Note: signature algorithms restrictions shouldn't apply to self-signatures) Ciphers: AES-GCM, AES-CBC, CAMELLIA-GCM, CAMELLIA-CBC, 3DES-CBC, RC4 Key exchange: ECDHE, RSA, DHE DH params size: 767+ RSA params size: 767+ Protocols: All supported (SSL3.0+)
DEFAULT: A reasonable default for today's standards. For F21 it should provide 80-bit security and no broken ciphers like RC4. MACs: SHA1+ Curves: All supported Signature algorithms: must use SHA-1 hash or better Ciphers: AES-GCM, AES-CBC, CAMELLIA-GCM, CAMELLIA-CBC, 3DES-CBC (Note that AES256 should be prioritized after AES128 to conserve resources). Key exchange: ECDHE, RSA, DHE DH params size: 1023+ RSA params size: 1023+ Protocols: All supported (SSL3.0+)
FUTURE: A level that will provide security on a conservative level that is believed to withstand any near-term future attacks. That will be an 128-bit security level, without including protocols with known attacks available (e.g. SSL 3.0). This level may prevent communication with commonly used systems that provide weaker security levels (e.g., systems that use SHA-1 as signature algorithm). MACs: SHA1+ Curves: of size 256+ or better Signature algorithms: must use SHA-256 hash or better Ciphers: AES-GCM, AES-CBC, CAMELLIA-GCM, CAMELLIA-CBC (Note that AES256 should be prioritized after AES128 to conserve resources). Key exchange: ECDHE, RSA, DHE DH params size: 3071+ RSA params size: 3071+ Protocols: TLS1.1+
Upgrade/compatibility impact
There should be no upgrade/compatibility issues. Programs that use their own strings will continue to work as before, although they will not adhere to system's policy.
How To Test
By trying the different security levels and evaluating whether connecting to specific SSL server using applications that use distinct libraries, and then verifying whether the results are the expected. It will require writing a test application that uses all 3 libraries for that purpose.
User Experience
It may be that setting a high security level could prevent applications that connected to servers below that level to connect. Thus, care must be taken when selecting the default level.
Dependencies
There are many packages that depend on the mentioned crypto libraries. Bugs will be filled to the major ones for the F21 release, and the plan is have all relevant packages to use the default settings by F22.
Contingency Plan
- Contingency mechanism:
The backup plan if anything goes wrong is to delay for f22. If the infrastructure is in place but doesn't work for any reason, then the packages shouldn't use the system settings and should be reverted to the original settings.
- Contingency deadline: beta freeze
- Blocks release? No
Documentation
My notes are above in the description.