Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix default ciphers in the configurations #274

Merged
merged 1 commit into from
Nov 21, 2023
Merged

Conversation

marcemmers
Copy link
Contributor

No description provided.

Signed-off-by: Marc Emmers <[email protected]>
@@ -222,7 +222,7 @@
"mutability": "ReadOnly"
}
],
"default": "TLS_AES_256_GCM_SHA384,TLS_AES_128_GCM_SHA256",
"default": "TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256",
Copy link
Contributor

@Dominik-K Dominik-K Nov 21, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should also add the TLS_CHACHA20_POLY1305_SHA256 here. Because it should be implemented according to TLS 1.3 RFC.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cc: @hikinggrass (as you've added this file)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we only added what the spec mentions what shall be supported here (A00.FR.318 says that a CSMS SHALL support at least):

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384

And A00.FR.319 mentions that a charging station shall support at least either

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
and
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

or

TLS_RSA_WITH_AES_128_GCM_SHA256
and
TLS_RSA_WITH_AES_256_GCM_SHA384)

But we are free to add better ciphers here if available 😄

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would suggest keeping the default to the bare minimum required from OCPP perspective to provide the best interoperability on all charging stations. Maybe it is good to suggest in a adoption guide or something that users could add TLS_CHACHA20_POLY1305_SHA256 if they want.

Comment on lines 209 to 219
"SupportedCiphers12": {
"variable_name": "SupportedCiphers12",
"attributes": {
"Actual": "ECDHE-ECDSA-AES128-GCM-SHA256,ECDHE-ECDSA-AES256,GCM-SHA384,AES128-GCM-SHA256,AES256-GCM-SHA384,TLS_AES_256_GCM_SHA384,TLS_AES_128_GCM_SHA256"
"Actual": "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-GCM-SHA384"
}
},
"SupportedCiphers13": {
"variable_name": "SupportedCiphers13",
"attributes": {
"Actual": "TLS_AES_256_GCM_SHA384,TLS_AES_128_GCM_SHA256"
"Actual": "TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256"
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest we remove these configs here. There should be only one single source of truth, also for config-defaults.

If you really need to change this, then you should definitely know and understand why you're doing this anyway. Then you'll also figure out how to set this config.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure but that seems out of scope for this fix, so I would prefer to leave this change in this PR.

@Dominik-K
Copy link
Contributor

Regarding the ordering of the cipher-suites, I suggest to follow Go(lang)'s standards. Especially this hint might be useful for lower end hardware:

In Go 1.16, we started actively preferring ChaCha20Poly1305 cipher suites over AES-GCM on the server when we detect that either the client or the server lacks hardware support for AES-GCM. This is because AES-GCM is hard to implement efficiently and securely without dedicated hardware support (such as the AES-NI and CLMUL instruction sets).

@marcemmers
Copy link
Contributor Author

Regarding the ordering of the cipher-suites, I suggest to follow Go(lang)'s standards. Especially this hint might be useful for lower end hardware:

In Go 1.16, we started actively preferring ChaCha20Poly1305 cipher suites over AES-GCM on the server when we detect that either the client or the server lacks hardware support for AES-GCM. This is because AES-GCM is hard to implement efficiently and securely without dedicated hardware support (such as the AES-NI and CLMUL instruction sets).

In line with my earlier comment on keeping the ciphers to only the ones in the OCPP spec, I do agree that it might be better to order them as suggested there. The only change then would be moving AES128 before the AES256 counterparts. ECDHE is already preferred over RSA in these configs.

@hikinggrass hikinggrass merged commit 34bd0a1 into main Nov 21, 2023
3 checks passed
@hikinggrass hikinggrass deleted the me-fix-default-ciphers branch November 21, 2023 17:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants