Improvement of the ciphersuite selection#10590
Improvement of the ciphersuite selection#10590OttoHollmann wants to merge 49 commits intoopenssl:masterfrom
Conversation
…cipher list interface.
…cipher list interface.
|
This PR is waiting for the creator to make requested changes but it has not been updated for 148 days. If you have made changes or commented to the reviewer please make sure you re-request a review (see icon in the 'reviewers' section). |
|
This PR is waiting for the creator to make requested changes but it has not been updated for 179 days. If you have made changes or commented to the reviewer please make sure you re-request a review (see icon in the 'reviewers' section). |
|
This PR is waiting for the creator to make requested changes but it has not been updated for 210 days. If you have made changes or commented to the reviewer please make sure you re-request a review (see icon in the 'reviewers' section). |
|
This PR is waiting for the creator to make requested changes but it has not been updated for 241 days. If you have made changes or commented to the reviewer please make sure you re-request a review (see icon in the 'reviewers' section). |
|
This PR is waiting for the creator to make requested changes but it has not been updated for 272 days. If you have made changes or commented to the reviewer please make sure you re-request a review (see icon in the 'reviewers' section). |
|
Can we move forward please? Which changes are needed to accept this PR? I am looking forward to your response! |
|
I have to admit to being quite sceptical about this PR. Do we really need to make ciphersuite selection more complicated? It's already quite complicated and I'm not sure adding more operators and ways to do things particularly helps most users. I'm not at all convinced that version based selection is a good idea. People are already very confused by what the versions associated with ciphersuites actually mean and try to control the negotiated versions via ciphersuites. I'm also not convinced by the proposal to specify TLSv1.3 ciphersuites via the old style cipher list. We had many discussions about how to do TLSv1.3 ciphersuite configuration during the 1.1.1 development phase and many different proposals were made (and more than one implemented in the code and then backed out again). Having decided on an approach and pushing it out, I'm unconvinced that changing tack now is a good plan. |
|
Merging the version into the list of ciphers makes this very very complicated. Understanding what happens to the version flags (or OP settings) and their interaction with the cipher list is tricky and hard to understand. This shouldn't be accepted. |
|
Yes, I would agree, that the ciphersuite selection process is quite complicated - this was the main reason which prompted the idea behind this PR. I didn't know about previous discussions and attempts. But I noticed, that ciphersuites were entered using old cipher list interface in past. Because it can break some existing configuration, ciphersuites interface was created. The main goal of this PR was not introducing additional way of doing things but to introduce an unified way. I know a few people who would appreciate this an unified interface. And just a side note: I don't know any other crypto library which has two interfaces for specifying ciphers. This results into an issue with third party applications which have to implement a second interface otherwise you are unable to modify ciphersuites (e.g. nginx). I believe this makes users much more confused. We don't have to accept this PR, but I'll be very happy, if we at least come up with a unified interface before closing this PR. |
|
This PR is waiting for the creator to make requested changes but it has not been updated for 30 days. If you have made changes or commented to the reviewer please make sure you re-request a review (see icon in the 'reviewers' section). |
|
This PR is waiting for the creator to make requested changes but it has not been updated for 61 days. If you have made changes or commented to the reviewer please make sure you re-request a review (see icon in the 'reviewers' section). |
|
This PR is waiting for the creator to make requested changes but it has not been updated for 92 days. If you have made changes or commented to the reviewer please make sure you re-request a review (see icon in the 'reviewers' section). |
|
Does anyone object to this being closed? |
|
This PR is waiting for the creator to make requested changes but it has not been updated for 30 days. If you have made changes or commented to the reviewer please make sure you re-request a review (see icon in the 'reviewers' section). |
|
This PR is waiting for the creator to make requested changes but it has not been updated for 61 days. If you have made changes or commented to the reviewer please make sure you re-request a review (see icon in the 'reviewers' section). |
|
This PR is waiting for the creator to make requested changes but it has not been updated for 92 days. If you have made changes or commented to the reviewer please make sure you re-request a review (see icon in the 'reviewers' section). |
|
This PR has been closed. It was waiting for the creator to make requested changes but it has not been updated for 120 days. |
I had read some issues (#5050, #541, ...) about the current ciphersuite specification and I decided to implement some improvements:
https://github.com/OttoHollmann/openssl/tree/Improvement-of-the-ciphersuite-selection
Operator
|for specifying version of each ciphersuite/aliasThere are these versions:
SSLv3,TLSv1,TLSv1.2,TLSv1.3,ALLand multiple versions can be used at one time:CHACHA20|TLSv1.2|TLSv1.3Parameter for setting default version (
-version_mask). If no version operator|or version alias (e.g.TLSv1.2) or specific ciphersuite is set, the default version mask will be applied. If noversion_maskis provided, it will be set to all versions up to TLSv1.2 (for backwards compatibility).e.g.
TLSv1.3:AES128|ALL:ECDH+AES|TLSv1.2|TLSv1:DHwith noversion_maskwill enable:TLSv1.3- all TLSv1.3 ciphers (because this alias represent version)AES128|ALL- all ciphersuites usingAES128from all versionsECDH+AES|TLSv1.2|TLSv1-ECDH+AESfrom versions TLSv1.2 or TLS1DH-DHfrom versions except TLSv1.3 (because of default value of version mask)Allowing to set TLSv1.3 ciphersuites using cipher list interface.
If at least one valid TLSv1.3 ciphersuite is in the cipher list, or parameter
version_maskis used, all ciphers entered using ciphersuites interface will be erased (ciphersuites will be set to empty string).Add operator
^for moving cipher at the top of the list (opposite of+)Operator
*for prioritizing cipher depending on client's list. If server ciphers are prioritized and a cipher has this flag and it is at the top of the client list, it will be selected.e.g. (suppose only TLSv1.3 ciphersuites):
TLSv1.3:+TLS_CHACHA20_POLY1305_SHA256:*CHACHA20|ALLTLS_AES_256_GCM_SHA384TLS_AES_128_GCM_SHA256TLS_AES_128_CCM_8_SHA256TLS_AES_128_CCM_SHA256*TLS_CHACHA20_POLY1305_SHA256DEFAULT|TLSv1.3:^TLS_CHACHA20_POLY1305_SHA256TLS_CHACHA20_POLY1305_SHA256TLS_AES_256_GCM_SHA384TLS_AES_128_GCM_SHA256Will result into selecting
TLS_CHACHA20_POLY1305_SHA256because it's at the top of the client's list and has priority flag in the server list.This feature was modified to check first common ciphersuite in client list instead of first ciphersuites.
Equal-preference groups - group is defined by these brackets
[]and can contain ciphersuites of cipher alias (even with specified version)+^can not be used inside of group*used inside of group will affect at most all ciphers in current group+^*used outside of group will not affect ciphersuites inside group@SECLEVELand@STRENGTHcan not be used with groupse.g. command
openssl ciphers -v -version_mask ALL '[TLSv1.3:-CHACHA20]:AES256-CCM:CHACHA20:*CHACHA20'returns this (encryption column omitted):Documentation and tests are missing but will be added soon.Any feedback will be greatly appreciated.