EnMasseProject / enmasse

EnMasse - Self-service messaging on Kubernetes and OpenShift
https://enmasseproject.github.io
Apache License 2.0
190 stars 87 forks source link

How to enhance the cipher security for amqps #4321

Open aaron0609 opened 4 years ago

aaron0609 commented 4 years ago

Hi there,

As we deployed Enmasse in K8S and provide amqps connection for external devices on HuaweiCloud, a security check was made by the service provider, and here they detected the insecure cipher suites:

CVE-2016-2183, TLS/SSL Birthday attacks on 64-bit block ciphers (SWEET32) Protocol: TCP Port: 5671 Negotiated with the following insecure cipher suites: TLS 1.2 ciphers: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA

Is there a way to configure the TLS 1.2 ciphers in enmasse?

lulf commented 4 years ago

@aaron0609 TLS 1.2 or newer is required in EnMasse version 0.31.0 and newer. We will also make this configurable at some point, but hopefully that should cover your use case.

k-wall commented 4 years ago

@lulf I think the question is about the ability to turn off of insecure ciphers within a protocol version (TLS 1.2 in this case).

lulf commented 4 years ago

Ah, I misinterpreted it as being about requiring 1.2. Then no, we don’t have support for that yet, but it’s something we should look at I think.

k-wall commented 4 years ago

Having just talked to @rgodfrey I understand the (slight) difficultly in implementing a whitelist/blacklist is that that the Broker (Java) uses different cipher suite naming to that of the Dispatch Router (config is in terms of the OpenSSL names). This would make expose common controls for brokered and standard awkward as it would mean we'd have to map from one domain to another.

aaron0609 commented 4 years ago

I think it's all right for me to wait for next release, cause now I think that may be not safe if having a feature for common users to configure ciphers as what I'm looking for at the beginning. This should be a standard hard-coded settings in enmasse, which would be better. What do you think on this?

k-wall commented 4 years ago

I notice that for Java, there is a io.netty.handler.ssl.CipherSuiteConverter which is capable of converting between OpenSSL names and Java ones (=IANA names?). We could add cipher suite white and black lists to the infra config that are in term of the IANA cipher suite names. For the router, the controller would need to convert these IANA names into a OpenSSL names and use these to form an appropriate OpenSSL cipher suite configuration string. For the brokered address space, Artemis has an enabledCipherSuites setting only so implementing the blacklist would require some pre-processing which would need to be organised by the broker init container.

I don't see a Go equivalent of CipherSuiteConverter. @lulf @rgodfrey