From Fedora Project Wiki
(Deferred: https://pagure.io/fesco/issue/1906#comment-517141)
(Clarify the impact of enabling DEFAULT:FEDORA32 or LEGACY policy.)
 
(6 intermediate revisions by 3 users not shown)
Line 3: Line 3:


== Summary ==
== Summary ==
We update the current system-wide crypto policy to further disable legacy cryptographic protocols (TLS 1.0 and TLS 1.1) and weak Diffie-Hellman key exchange sizes (1024 bit)
We update the current system-wide crypto policy to further disable legacy cryptographic protocols (TLS 1.0 and TLS 1.1), weak Diffie-Hellman key exchange sizes (1024 bit), and use of the SHA-1 hash in signatures.


== Owner ==
== Owner ==
Line 10: Line 10:
This should link to your home wiki page so we know who you are.  
This should link to your home wiki page so we know who you are.  
-->
-->
* Name: [[User:tmraz| Tomáš Mráz]]
* Name: [[User:tmraz|Tomáš Mráz]]
<!-- 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: <tmraz@redhat.com>
* Email: <tmraz@redhat.com>
* Release notes ticket:
<!--- 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 23: Line 22:


== Current status ==
== Current status ==
* Targeted release: [[Releases/29 | Fedora 29 ]]  
[[Category:ChangeAcceptedF33]]
[[Category:SystemWideChange]]
* Targeted release: [[Releases/33 | Fedora 33 ]]
* Last updated: <!-- this is an automatic macro — you don't need to change this line -->  {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}  
* Last updated: <!-- this is an automatic macro — you don't need to change this line -->  {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}  
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page  
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page  
Line 33: Line 34:
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
-->
-->
* Tracker bug: -to be assigned-
* FESCo issue: [https://pagure.io/fesco/issue/2362 #2362]
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1821875 #1821875]
* Release notes tracker: [https://pagure.io/fedora-docs/release-notes/issue/470 #470]


== Detailed Description ==
== Detailed Description ==
Line 44: Line 47:
  * 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
* Disable SHA1 support for use in signatures (X.509 certificates, TLS, IPSEC handshakes)




Line 60: Line 64:
   MACs: All HMAC with SHA1 or better + all modern MACs (poly1305 etc)
   MACs: All HMAC with SHA1 or better + all modern MACs (poly1305 etc)
   Curves: all prime >= 255 bits (including bernstein curves)
   Curves: all prime >= 255 bits (including bernstein curves)
   Signature algorithms: with SHA-1 hash or better (not DSA)
   Signature algorithms: with SHA-256 hash or better (not DSA)
   Ciphers: >= 128-bit key, >= 128-bit block (aes, camellia, chacha20, including aes-cbc)
   Ciphers: >= 128-bit key, >= 128-bit block (aes, chacha20, including aes-cbc)
   key exchange: ECDHE, RSA, DHE
   key exchange: ECDHE, RSA, DHE
   DH params size: >= 2048
   DH params size: >= 2048
Line 69: Line 73:
  FUTURE
  FUTURE
   MACs: All HMAC with SHA256 or better + all modern MACs (poly1305 etc)
   MACs: All HMAC with SHA256 or better + all modern MACs (poly1305 etc)
   Curves: all prime >= 384 bits (including bernstein curves)
   Curves: all prime >= 255 bits (including bernstein curves)
   Signature algorithms: SHA-384 hash or better (not DSA)
   Signature algorithms: SHA-256 hash or better (not DSA)
   Ciphers: >= 256-bit key, >= 128-bit block, only Authenticated Encryption (AE) ciphers
   Ciphers: >= 256-bit key, >= 128-bit block, only Authenticated Encryption (AE) ciphers
   key exchange: ECDHE, DHE
   key exchange: ECDHE, DHE
Line 80: Line 84:
== Benefit to Fedora ==
== 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.  
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.
 
Also please note that Firefox is also moving to similar default crypto settings with the current releases (Firefox 74) [https://hacks.mozilla.org/2020/02/its-the-boot-for-tls-1-0-and-tls-1-1/].


== Scope ==
== Scope ==
Line 88: Line 94:
* Other developers:  
* Other developers:  
  * Crypto policies are updated to the settings above
  * Crypto policies are updated to the settings above
* [https://bugzilla.redhat.com/show_bug.cgi?id=1487607 OpenSSL is updated to allow setting policies for TLS versions]


* Release engineering: Copied from F28 change - no impact  [https://pagure.io/releng/issue/7235 #7235] (a check of an impact with Release Engineering is needed) <!-- REQUIRED FOR SYSTEM WIDE AS WELL AS FOR SELF CONTAINED CHANGES -->
* Release engineering: Copied from F28 change - no impact  [https://pagure.io/releng/issue/7235 #7235] (a check of an impact with Release Engineering is needed)


** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List of deliverables]]:
** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List of deliverables]]:
Line 103: Line 108:


== Upgrade/compatibility impact ==
== 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.
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 Fedora 32 policy level:
 
update-crypto-policies --set DEFAULT:FEDORA32
 
If that doesn't work, you may also try the LEGACY policy level:
 
  update-crypto-policies --set LEGACY
  update-crypto-policies --set LEGACY


You should not enable DEFAULT:FEDORA32 or the LEGACY policy levels unless you need to communicate with systems that do not support the contemporary cryptographic algorithms and protocols. However even with these policy levels enabled the libraries and applications on Fedora will not use weak cryptographic algorithms or protocol versions if the other party supports contemporary strong ones.


== How To Test ==
== How To Test ==
Line 142: Line 153:


== Release Notes ==
== Release Notes ==
[[Category:ChangePageIncomplete]]
[[Category:SystemWideChange]]

Latest revision as of 09:04, 29 October 2020

Strong crypto settings: phase 2

Summary

We update the current system-wide crypto policy to further disable legacy cryptographic protocols (TLS 1.0 and TLS 1.1), weak Diffie-Hellman key exchange sizes (1024 bit), and use of the SHA-1 hash in signatures.

Owner

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:

* 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
* Disable SHA1 support for use in signatures (X.509 certificates, TLS, IPSEC handshakes)


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-256 hash or better (not DSA)
 Ciphers: >= 128-bit key, >= 128-bit block (aes, chacha20, including aes-cbc)
 key exchange: ECDHE, RSA, DHE
 DH params size: >= 2048
 RSA params size: >= 2048
 TLS protocols: TLS >= 1.2
FUTURE
 MACs: All HMAC with SHA256 or better + all modern MACs (poly1305 etc)
 Curves: all prime >= 255 bits (including bernstein curves)
 Signature algorithms: SHA-256 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.

Also please note that Firefox is also moving to similar default crypto settings with the current releases (Firefox 74) [1].

Scope

  • Proposal owners:

The policies include in crypto-policies package need to be updated.

  • Other developers:
* Crypto policies are updated to the settings above
  • Release engineering: Copied from F28 change - no impact #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 Fedora 32 policy level:

update-crypto-policies --set DEFAULT:FEDORA32

If that doesn't work, you may also try the LEGACY policy level:

update-crypto-policies --set LEGACY

You should not enable DEFAULT:FEDORA32 or the LEGACY policy levels unless you need to communicate with systems that do not support the contemporary cryptographic algorithms and protocols. However even with these policy levels enabled the libraries and applications on Fedora will not use weak cryptographic algorithms or protocol versions if the other party supports contemporary strong ones.

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.

  • Contingency deadline: beta freeze
  • Blocks release? No

Documentation

None


Release Notes