(proper link) |
|||
(7 intermediate revisions by 2 users not shown) | |||
Line 19: | Line 19: | ||
<!-- 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 --> | ||
= OpenSSH Crypto Policy = | = OpenSSH Crypto Policy (Client) = | ||
== Summary == | == Summary == | ||
OpenSSH will follow system-wide crypto policies already followed by other cryptographic tools. It will allow to use different security levels defined system-wide. | OpenSSH client will follow system-wide crypto policies already followed by other cryptographic libraries and tools. It will allow to use different security levels defined system-wide. | ||
<!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release. --> | <!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release. --> | ||
Line 54: | Line 54: | ||
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: | * Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1385506 #1385506] | ||
== Detailed Description == | == Detailed Description == | ||
Currently, the set of cryptographic algorithms used in OpenSSH is defined by upstream and Fedora just inherits what upstream considers secure. If there are special requirements for the security, manual modifications of the configuration files is required, which also prevents package manager to update the configuration file with future updates and possibly | Currently, the set of cryptographic algorithms used in OpenSSH is defined by upstream and Fedora just inherits what upstream considers secure. If there are special requirements for the security, manual modifications of the configuration files is required, which also prevents package manager to update the configuration file with future updates and can possibly leave enabled insecure algorithms. | ||
Since Fedora 25 we have possibility to include configuration files from the main <code>ssh_config</code>, which allowed us to include crypto policies in the OpenSSH (client | Since Fedora 25 we have possibility to include configuration files from the main <code>ssh_config</code>, which allowed us to include crypto policies in the OpenSSH (client). | ||
For more information about Crypto Policy, see the appropriate wiki page [[Changes/CryptoPolicy]] describing the concept in whole. | For more information about Crypto Policy, see the appropriate wiki page [[Changes/CryptoPolicy]] describing the concept in whole. | ||
Line 68: | Line 68: | ||
== Benefit to Fedora == | == Benefit to Fedora == | ||
OpenSSH will follow system-wide crypto policy generated by [https://git.fedorahosted.org/cgit/crypto-profiles.git/tree/update-crypto-policies.8.txt update-crypto-policies(8)] to ensure uniform security in the whole system. | OpenSSH will follow system-wide crypto policy generated by [https://git.fedorahosted.org/cgit/crypto-profiles.git/tree/update-crypto-policies.8.txt update-crypto-policies(8)] to ensure uniform security levels in the whole system. | ||
The client side configuration has always priority in the negotiation of cryptographic algorithms in the SSH session, which makes users sure they are using secure algorithms in their [http://www.openssh.com/images/openssh.gif communiques are secret]. | |||
<!-- What is the benefit to the platform? If this is a major capability update, what has changed? If this is a new functionality, what capabilities does it bring? Why will Fedora become a better distribution or project because of this proposal?--> | <!-- What is the benefit to the platform? If this is a major capability update, what has changed? If this is a new functionality, what capabilities does it bring? Why will Fedora become a better distribution or project because of this proposal?--> | ||
== Scope == | == Scope == | ||
* Proposal owners: Default OpenSSH configuration will include the generated policy file containing the definition of system-wide enabled algorithms. The include must be before any other options so user changes would not unintentionally get used instead of system-wide policy. | * Proposal owners: Default OpenSSH configuration will include the generated policy file containing the definition of system-wide enabled algorithms. The include must be before any other options so user changes would not unintentionally get used instead of system-wide policy. The policy preview is already available in the [https://github.com/nmav/fedora-crypto-policies/pull/8 pull request on github] | ||
<!-- What work do the feature owners have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | <!-- What work do the feature owners have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | ||
Line 92: | Line 94: | ||
== Upgrade/compatibility impact == | == Upgrade/compatibility impact == | ||
The default configuration files will be updated to include policy files and the default list of Ciphers, Key Exchange algorithms will be updated according to system-wide default (the changes are minor). If you previously modified your configuration files (<code>/etc/ssh/ssh_config</code>), they will not be overwritten and you will need to merge them from <code>.rpmnew</code> file. | The default configuration files will be updated to include policy files and the default list of Ciphers, Key Exchange algorithms and MACs will be updated according to system-wide default (the changes are minor). If you previously modified your configuration files (<code>/etc/ssh/ssh_config</code>), they will not be overwritten and you will need to merge them from <code>.rpmnew</code> file. | ||
You can always overwrite the system-wide policy using user-specific configuration files in <code>~/.ssh/config</code> or on command line. | You can always overwrite the system-wide policy using user-specific configuration files in <code>~/.ssh/config</code> or on the command line. | ||
<!-- What happens to systems that have had a previous versions of Fedora installed and are updated to the version containing this change? Will anything require manual configuration or data migration? Will any existing functionality be no longer supported? --> | <!-- What happens to systems that have had a previous versions of Fedora installed and are updated to the version containing this change? Will anything require manual configuration or data migration? Will any existing functionality be no longer supported? --> | ||
Line 103: | Line 105: | ||
== How To Test == | == How To Test == | ||
* All the SSH use cases should work after the update without any significant change, for example using QA:Testcase_OpenSSH | * All the SSH use cases should work after the update without any significant change, for example using [[QA:Testcase_OpenSSH]] | ||
** In the verbose log (with <code>-vv</code> switches) or in the output of <code>ssh -G test | grep "kex\|ciphers\|macs"</code>, you should see a long list with many algorithms | ** In the verbose log (with <code>-vv</code> switches) or in the output of <code>ssh -G test | grep "kex\|ciphers\|macs"</code>, you should see a long list with many algorithms | ||
*** There are Key exchange algorithms using SHA1: <code>diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1</code> | *** There are Key exchange algorithms using SHA1: <code>diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1</code> | ||
*** There are MACs algorithms using SHA1: <code>hmac-sha1</code> | *** There are MACs algorithms using SHA1: <code>hmac-sha1</code> | ||
* Set higher security level: | * Set higher security level: | ||
** Run <code>update-crypto-policies --set FUTURE</code> | |||
** Run <code>update-crypto-policies</code> | * Test the functionality again, for example using [[QA:Testcase_OpenSSH]] | ||
* Test the functionality again, for example using QA:Testcase_OpenSSH | |||
** In the verbose log (with <code>-vv</code> switches) or in the output of <code>ssh -G test | grep "kex\|ciphers\|macs"</code>, you should see shorter list with stronger algorithms | ** In the verbose log (with <code>-vv</code> switches) or in the output of <code>ssh -G test | grep "kex\|ciphers\|macs"</code>, you should see shorter list with stronger algorithms | ||
*** There should not be any <code>sha1</code> hash functions | *** There should not be any <code>sha1</code> hash functions | ||
Line 116: | Line 117: | ||
*** There should not be any 64 bits MACs, such as <code>umac-64-etm@openssh.com,umac-64@openssh.com,hmac-md5</code> | *** There should not be any 64 bits MACs, such as <code>umac-64-etm@openssh.com,umac-64@openssh.com,hmac-md5</code> | ||
* Reset the security level to the DEFAULT | * Reset the security level to the DEFAULT | ||
** Run <code>update-crypto-policies --set DEFAULT</code> | |||
** Run <code>update-crypto-policies</code> | |||
In case you | In case you do not see any difference after the policy should have been updated, make sure your <code>/etc/ssh/ssh_config.d/05-redhat.conf</code> file contains, close to the start of the file, a line | ||
<pre>Include /etc/crypto-policies/back-ends/openssh.txt</pre> | <pre>Include /etc/crypto-policies/back-ends/openssh.txt</pre> | ||
and the file <code>/etc/ssh/ssh_config</code> contains a line | |||
<pre>Include /etc/ssh/ssh_config.d/*.conf</pre> | |||
<!-- This does not need to be a full-fledged document. Describe the dimensions of tests that this change implementation is expected to pass when it is done. If it needs to be tested with different hardware or software configurations, indicate them. The more specific you can be, the better the community testing can be. | <!-- This does not need to be a full-fledged document. Describe the dimensions of tests that this change implementation is expected to pass when it is done. If it needs to be tested with different hardware or software configurations, indicate them. The more specific you can be, the better the community testing can be. | ||
Line 162: | Line 167: | ||
== Documentation == | == Documentation == | ||
Upstream documentation | Upstream documentation is available in the upstream repository for [https://github.com/nmav/fedora-crypto-policies/blob/master/update-crypto-policies.8.txt update-crypto-policies(8)]. | ||
<!-- Is there upstream documentation on this change, or notes you have written yourself? Link to that material here so other interested developers can get involved. --> | <!-- Is there upstream documentation on this change, or notes you have written yourself? Link to that material here so other interested developers can get involved. --> | ||
Line 176: | Line 181: | ||
--> | --> | ||
[[Category: | [[Category:ChangeAcceptedF26]] | ||
<!-- When your change proposal page is completed and ready for review and announcement --> | <!-- When your change proposal page is completed and ready for review and announcement --> | ||
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --> | <!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --> |
Latest revision as of 08:46, 17 October 2016
OpenSSH Crypto Policy (Client)
Summary
OpenSSH client will follow system-wide crypto policies already followed by other cryptographic libraries and tools. It will allow to use different security levels defined system-wide.
Owner
- Name: Jakub Jelen
- Email: jjelen@redhat.com
- Release notes owner:
Current status
Detailed Description
Currently, the set of cryptographic algorithms used in OpenSSH is defined by upstream and Fedora just inherits what upstream considers secure. If there are special requirements for the security, manual modifications of the configuration files is required, which also prevents package manager to update the configuration file with future updates and can possibly leave enabled insecure algorithms.
Since Fedora 25 we have possibility to include configuration files from the main ssh_config
, which allowed us to include crypto policies in the OpenSSH (client).
For more information about Crypto Policy, see the appropriate wiki page Changes/CryptoPolicy describing the concept in whole.
Benefit to Fedora
OpenSSH will follow system-wide crypto policy generated by update-crypto-policies(8) to ensure uniform security levels in the whole system.
The client side configuration has always priority in the negotiation of cryptographic algorithms in the SSH session, which makes users sure they are using secure algorithms in their communiques are secret.
Scope
- Proposal owners: Default OpenSSH configuration will include the generated policy file containing the definition of system-wide enabled algorithms. The include must be before any other options so user changes would not unintentionally get used instead of system-wide policy. The policy preview is already available in the pull request on github
- Other developers: N/A (not a System Wide Change)
- Release engineering: N/A (not a System Wide Change)
- List of deliverables: N/A (not a System Wide Change)
- Policies and guidelines: N/A (not a System Wide Change)
- Trademark approval: N/A (not needed for this Change)
Upgrade/compatibility impact
The default configuration files will be updated to include policy files and the default list of Ciphers, Key Exchange algorithms and MACs will be updated according to system-wide default (the changes are minor). If you previously modified your configuration files (/etc/ssh/ssh_config
), they will not be overwritten and you will need to merge them from .rpmnew
file.
You can always overwrite the system-wide policy using user-specific configuration files in ~/.ssh/config
or on the command line.
How To Test
- All the SSH use cases should work after the update without any significant change, for example using QA:Testcase_OpenSSH
- In the verbose log (with
-vv
switches) or in the output ofssh -G test | grep "kex\|ciphers\|macs"
, you should see a long list with many algorithms- There are Key exchange algorithms using SHA1:
diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1
- There are MACs algorithms using SHA1:
hmac-sha1
- There are Key exchange algorithms using SHA1:
- In the verbose log (with
- Set higher security level:
- Run
update-crypto-policies --set FUTURE
- Run
- Test the functionality again, for example using QA:Testcase_OpenSSH
- In the verbose log (with
-vv
switches) or in the output ofssh -G test | grep "kex\|ciphers\|macs"
, you should see shorter list with stronger algorithms- There should not be any
sha1
hash functions - There should not be
3des-cbc
cipher - There should not be any 64 bits MACs, such as
umac-64-etm@openssh.com,umac-64@openssh.com,hmac-md5
- There should not be any
- In the verbose log (with
- Reset the security level to the DEFAULT
- Run
update-crypto-policies --set DEFAULT
- Run
In case you do not see any difference after the policy should have been updated, make sure your /etc/ssh/ssh_config.d/05-redhat.conf
file contains, close to the start of the file, a line
Include /etc/crypto-policies/back-ends/openssh.txt
and the file /etc/ssh/ssh_config
contains a line
Include /etc/ssh/ssh_config.d/*.conf
N/A (not a System Wide Change)
User Experience
N/A (not a System Wide Change)
Dependencies
N/A (not a System Wide Change)
Contingency Plan
- Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
- Contingency deadline: N/A (not a System Wide Change)
- Blocks release? N/A (not a System Wide Change), Yes/No
- Blocks product? product
Documentation
Upstream documentation is available in the upstream repository for update-crypto-policies(8).
N/A (not a System Wide Change)