(made fallback method explicit) |
(renamed) |
||
| (3 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name. This keeps all change proposals in the same namespace --> | <!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name. This keeps all change proposals in the same namespace --> | ||
= Strong crypto settings = | = Strong crypto settings: phase 1 = | ||
== Summary == | == Summary == | ||
| Line 13: | Line 13: | ||
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. --> | <!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. --> | ||
* Email: <nmav@redhat.com> | * Email: <nmav@redhat.com> | ||
* Release notes | * Release notes ticket: [https://pagure.io/fedora-docs/release-notes/issue/84 #84] | ||
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo) | <!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo) | ||
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address> | * FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address> | ||
| Line 41: | Line 41: | ||
While in the past we did not disable algorithms in a consistent way (different applications utilized different policies), today we have a system-wide policy followed by a large part of Fedora components. That allows us to move consistently and deprecate algorithms system-wide. For rationale see RFC 7457 for a more complete list of attacks taking advantage of legacy crypto algorithms. | While in the past we did not disable algorithms in a consistent way (different applications utilized different policies), today we have a system-wide policy followed by a large part of Fedora components. That allows us to move consistently and deprecate algorithms system-wide. For rationale see RFC 7457 for a more complete list of attacks taking advantage of legacy crypto algorithms. | ||
The | The changes for default policy are: | ||
* Require RSA of 2048 bits and more in the default settings | |||
* Disable DSA by default | |||
Originally the following changes were also proposed but postponed | |||
* Keep only TLS 1.2 (and TLS 1.3 when available) as enabled protocols and move the TLS 1.x, x<=1 to legacy level. | * Keep only TLS 1.2 (and TLS 1.3 when available) as enabled protocols and move the TLS 1.x, x<=1 to legacy level. | ||
* Require finite field parameters (RSA, Diffie-Hellman) of 2048 and more in the default settings | * Require finite field parameters (RSA, Diffie-Hellman) of 2048 and more in the default settings | ||
That is a policy of: | That is a policy of: | ||
| Line 53: | Line 57: | ||
Ciphers: all available > 112-bit key, >= 128-bit block (no rc4, but with 3DES) | Ciphers: all available > 112-bit key, >= 128-bit block (no rc4, but with 3DES) | ||
key exchange: ECDHE, RSA, DHE | key exchange: ECDHE, RSA, DHE | ||
DH params size: >= | DH params size: >=1023 | ||
RSA params size: >= | RSA params size: >=1023 | ||
TLS protocols: TLS >= 1.0 | TLS protocols: TLS >= 1.0 | ||
| Line 63: | Line 67: | ||
Ciphers: >= 128-bit key, >= 128-bit block (aes, camellia, chacha20, including aes-cbc) | Ciphers: >= 128-bit key, >= 128-bit block (aes, camellia, chacha20, including aes-cbc) | ||
key exchange: ECDHE, RSA, DHE | key exchange: ECDHE, RSA, DHE | ||
DH params size: >= | DH params size: >= 1023 | ||
RSA params size: >= 2048 | RSA params size: >= 2048 | ||
TLS protocols: TLS >= 1. | TLS protocols: TLS >= 1.0 | ||
FUTURE | FUTURE | ||
| Line 129: | Line 133: | ||
* Contingency mechanism: (What to do? Who will do it?) | * Contingency mechanism: (What to do? Who will do it?) | ||
If we notice significant user experience degradation, e.g., due to many custom servers utilizing legacy protocols, we should consider postponing that change. The change owner will take care of this. | If we notice significant user experience degradation, e.g., due to many custom servers utilizing legacy protocols, we should consider postponing or reducing the number of updates in that change. The change owner will take care of this. | ||
If the openssl changes to support a system-wide policy do not merge on upstream in time, the change will be postponed. The change owner will take care of this. | If the openssl changes to support a system-wide policy do not merge on upstream in time, the change will be postponed. The change owner will take care of this. | ||
Latest revision as of 13:04, 6 March 2018
Strong crypto settings: phase 1
Summary
This change is about updating the current system-wide crypto policy to disable legacy and unused cryptographic protocols.
Owner
- Name: Nikos Mavrogiannopoulos
- Email: <nmav@redhat.com>
- Release notes ticket: #84
Current status
Detailed Description
Fedora includes several cryptographic components who's security doesn't remain constant over time. Algorithms such as (cryptographic) hashing and encryption typically have a lifetime after which they are considered either too risky to use or plain insecure. That would mean we need to phase out such algorithms from the default settings, or completely disable if they could cause irreparable issue.
While in the past we did not disable algorithms in a consistent way (different applications utilized different policies), today we have a system-wide policy followed by a large part of Fedora components. That allows us to move consistently and deprecate algorithms system-wide. For rationale see RFC 7457 for a more complete list of attacks taking advantage of legacy crypto algorithms.
The changes for default policy are:
* Require RSA of 2048 bits and more in the default settings * Disable DSA by default
Originally the following changes were also proposed but postponed
* Keep only TLS 1.2 (and TLS 1.3 when available) as enabled protocols and move the TLS 1.x, x<=1 to legacy level. * Require finite field parameters (RSA, Diffie-Hellman) of 2048 and more in the default settings
That is a policy of:
LEGACY MACs: All HMAC with SHA1 or better + all modern MACs (poly1305 etc) Curves: all prime >= 255 bits (including bernstein curves) Signature algorithms: SHA-1 hash or better (not RIPEMD) Ciphers: all available > 112-bit key, >= 128-bit block (no rc4, but with 3DES) key exchange: ECDHE, RSA, DHE DH params size: >=1023 RSA params size: >=1023 TLS protocols: TLS >= 1.0
DEFAULT MACs: All HMAC with SHA1 or better + all modern MACs (poly1305 etc) Curves: all prime >= 255 bits (including bernstein curves) Signature algorithms: with SHA-1 hash or better (not DSA) Ciphers: >= 128-bit key, >= 128-bit block (aes, camellia, chacha20, including aes-cbc) key exchange: ECDHE, RSA, DHE DH params size: >= 1023 RSA params size: >= 2048 TLS protocols: TLS >= 1.0
FUTURE MACs: All HMAC with SHA256 or better + all modern MACs (poly1305 etc) Curves: all prime >= 384 bits (including bernstein curves) Signature algorithms: SHA-384 hash or better (not DSA) Ciphers: >= 256-bit key, >= 128-bit block, only Authenticated Encryption (AE) ciphers key exchange: ECDHE, DHE DH params size: >= 3072 RSA params size: >= 3072 TLS protocols: TLS >= 1.2
Benefit to Fedora
With this change we protect users from relying on enabled-by-default weak cryptography, as well as reduce our maintenance cost for future attacks that rely on weak crypto for exploitation.
Scope
- Proposal owners:
The policies include in crypto-policies package need to be updated.
- Other developers:
* Crypto policies are updated to the settings above * OpenSSL is updated to allow setting policies for TLS versions
- Release engineering: #7235 (a check of an impact with Release Engineering is needed)
* Crypto policies are updated to the settings above * OpenSSL, NSS, GnuTLS and all applications covered under the Fedora Crypto Policies follow the new crypto settings.
- Policies and guidelines:
No changes to packaging or other guidelines is needed.
- Trademark approval: N/A (not needed for this Change)
Upgrade/compatibility impact
It may be that the new settings break software that connects to servers which utilize weak algorithms. Compatibility can be obtained by switching the system to legacy mode as follows.
update-crypto-policies --set LEGACY
How To Test
Applications which follow the system-wide policy (e.g., curl,wget) should be tested:
* whether they can connect to legacy (TLS1.0, TLS1.1) servers when system is in legacy mode * whether the previous connection breaks when system is in default mode * whether the system can connect to TLS 1.2 servers when in default, legacy or future mode.
User Experience
Given the existing deployment of TLS 1.2 on the internet, there should not be significant user experience degradation, although that's a speculation.
Dependencies
* nss * gnutls * openssl * crypto-policies
Contingency Plan
- Contingency mechanism: (What to do? Who will do it?)
If we notice significant user experience degradation, e.g., due to many custom servers utilizing legacy protocols, we should consider postponing or reducing the number of updates in that change. The change owner will take care of this.
If the openssl changes to support a system-wide policy do not merge on upstream in time, the change will be postponed. The change owner will take care of this.
- Contingency deadline: beta freeze
- Blocks release? No
Documentation
None