Is it possible to configure cipher suites used by RabbitMQ Management Plugin? - rabbitmq

I have an instance of RabbitMQ 3.7.7-management image running. It has the rabbitmq-management plugin enabled and configured to use HTTPS as per the documentation:
management.listener.port = 15671
management.listener.ssl = true
management.listener.ssl_opts.cacertfile = /path/to/cacert.pem
management.listener.ssl_opts.certfile = /path/to/cert.pem
management.listener.ssl_opts.keyfile = /path/to/key.pem
management.listener.ssl_opts.fail_if_no_peer_cert = false
management.listener.ssl_opts.versions.1 = tlsv1.2
When I evaluate the TLS setup with testssl.sh testing tool, a test for SWEET32 vulnerability fails:
Testing vulnerabilities
...
SWEET32 (CVE-2016-2183, CVE-2016-6329) VULNERABLE, uses 64 bit block ciphers
...
OpenVAS framework also complains:
Vulnerability Detection Result
'Vulnerable' cipher suites accepted by this service via the TLSv1.2 protocol:
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (SWEET32)
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (SWEET32)
TLS_RSA_WITH_3DES_EDE_CBC_SHA (SWEET32)
Solution type: Mitigation
The configuration of this services should be changed so that it does not accept the listed cipher suites anymore.
Is it possible to configure what cipher suites will be used by the RabbitMQ Management Plugin? For RabbitMQ it is possible, but looking at rabbitmq_management.schema it seems that for the Management Plugin it's impossible. Or is there a different way to fix the vulnerability?

You will have to use the advanced.config file to do so. I'm assuming that you have already created /etc/rabbitmq/rabbitmq.conf with the settings you show. Create the /etc/rabbitmq/advanced.config file with these contents and re-start RabbitMQ:
[
{rabbitmq_management, [
{listener, [
{ssl_opts, [
{ciphers, [
%% CIPHERS GO HERE
]}
]}
]}
]}
].
The setting should be merged into what is specified in rabbitmq.conf. You can check the generated config files in /var/lib/rabbitmq/...
If this does not work, please follow up on the mailing list.
NOTE: the RabbitMQ team monitors the rabbitmq-users mailing list and only sometimes answers questions on StackOverflow.

Related

Jetty SSL problem after upgrade - unknown protocol

I upgraded Jetty 9.3.6 to Jetty 9.4.27 and I have a problem with SSL connection.
When I run curl on some supported operation I get
error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol (error 35) whereas when I run the same command on the server running Jetty 9.3.6 it is all working fine.
I configured jetty's newer version in the same way as was the older one (including keystore path and enabling https support). Do you have a clue what could have gone wrong during upgrade or what I could have missed?
Thanks a lot for your support.
Jetty 9.3.x and 9.4.x have different Cipher Suite exclusions.
Jetty 9.3.6.v20151106 looks like this ...
https://github.com/eclipse/jetty.project/blob/jetty-9.3.6.v20151106/jetty-util/src/main/java/org/eclipse/jetty/util/ssl/SslContextFactory.java#L248-L260
addExcludeProtocols("SSL", "SSLv2", "SSLv2Hello", "SSLv3");
setExcludeCipherSuites(
"SSL_RSA_WITH_DES_CBC_SHA",
"SSL_DHE_RSA_WITH_DES_CBC_SHA",
"SSL_DHE_DSS_WITH_DES_CBC_SHA",
"SSL_RSA_EXPORT_WITH_RC4_40_MD5",
"SSL_RSA_EXPORT_WITH_DES40_CBC_SHA",
"SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA",
"SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA");
Jetty 9.4.29.v20200521 looks like this ...
https://github.com/eclipse/jetty.project/blob/jetty-9.4.29.v20200521/jetty-util/src/main/java/org/eclipse/jetty/util/ssl/SslContextFactory.java#L119-L138
/**
* Default Excluded Protocols List
*/
private static final String[] DEFAULT_EXCLUDED_PROTOCOLS = {"SSL", "SSLv2", "SSLv2Hello", "SSLv3"};
/**
* Default Excluded Cipher Suite List
*/
private static final String[] DEFAULT_EXCLUDED_CIPHER_SUITES = {
// Exclude weak / insecure ciphers
"^.*_(MD5|SHA|SHA1)$",
// Exclude ciphers that don't support forward secrecy
"^TLS_RSA_.*$",
// The following exclusions are present to cleanup known bad cipher
// suites that may be accidentally included via include patterns.
// The default enabled cipher list in Java will not include these
// (but they are available in the supported list).
"^SSL_.*$",
"^.*_NULL_.*$",
"^.*_anon_.*$"
};
You'll want to evaluate why you need known vulnerable cipher suites to function.
Also, if you are using an IBM JVM all bets are off, because the IBM uses non-standard Cipher Suite names (unlike all other JVMs that use the RFC Registered Cipher Suite names).

Cowboy Webserver using HTTP2 and TLS getting ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY in Chrome

I'm using: Erlang OTP 21 and Cowboy 2.4
Code:
cowboy:start_tls(
my_listener,
[
{port, Web_Server_Port},
{certfile, Cert_File},
{keyfile, Key_File}
],
#{env => #{dispatch => dispatcher()}}
)
I'm using this to start the web server, which work fine on HTTP1.1,but now Chrome is using HTTP2 and that can't be disabled.
So now I'm receiving:
ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY
I also experience a similar problem Firefox with HTTP2 enable:
Error code: NS_ERROR_NET_INADEQUATE_SECURITY
but on Firefox I can disable HTTP2. It work fine when HTTP2 is disabled.
I have verified my certificate is good and I get the green lock under HTTP1.1
I have read that HTTP2 is stricter with the ciphers that are used and the order they appear.
Fixing ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY SSL error in Chrome
https://www.jeffgeerling.com/blog/2016/fixing-errspdyinadequatetransportsecurity-ssl-error-chrome
But not sure if that is the problem.
I'm not sure of what ciphers to use also not exactly sure how to indicate their use in cowboy. I have tried adding a cipher option in the options, but this doesn't correct the problem:
{ciphers, [
{ecdhe_ecdsa,aes_256_cbc,sha384,sha384},
{ecdhe_rsa,aes_256_cbc,sha384,sha384},
{ecdh_ecdsa,aes_256_cbc,sha384,sha384},
{ecdh_rsa,aes_256_cbc,sha384,sha384},
{dhe_rsa,aes_256_cbc,sha256},
{dhe_dss,aes_256_cbc,sha256},
{ecdhe_ecdsa,aes_256_cbc,sha},
{ecdhe_rsa,aes_256_cbc,sha},
{dhe_rsa,aes_256_cbc,sha},
{dhe_dss,aes_256_cbc,sha},
{ecdh_ecdsa,aes_256_cbc,sha},
{ecdh_rsa,aes_256_cbc,sha},
{ecdhe_rsa,aes_128_cbc,sha},
{dhe_rsa,aes_128_cbc,sha},
{dhe_dss,aes_128_cbc,sha},
{ecdh_ecdsa,aes_128_cbc,sha},
{ecdh_rsa,aes_128_cbc,sha}
]}
Any suggestions on what I'm doing wrong here?
HTTP/2 forbids the use of old ciphers including all the CBC ciphers you have listed.
Enable some GCM ciphers like this, which should be accepted by most browsers:
{ciphers, ["ECDHE-RSA-AES256-GCM-SHA384"]}
Though by default it should allow these.
See here for more information: http://ezgr.net/increasing-security-erlang-ssl-cowboy/

ssl version and cipher suites of the client

I'm working on a soap server, that will serve some old embedded computers with an legacy soap protocol.
I write it in go and so far used just plain http, but in production it must use ssl encryption. So I've just created a key and a cert (from this site) and used the http.ListenAndServeTLS function.
But now the computers cannot connect and the server is just printing a handshake error:
server.go:2848: http: TLS handshake error from [::1]:38790: tls: no cipher suite supported by both client and server
In the docs, for the computers, isn't the supported ssl version or the ciphers. So I wanted to know, how to find out the client's ssl version, and also the available cipher suites that the client supports.
And then how can I configure the golang http server so it will support the selected ciphers.
There seems to be two questions here, so let's do this in two parts:
Finding the client's TLS version and supported cipher suites:
To do this, you need to set the GetConfigForClient field of the tls.Config object.
This field takes a method with signature:
func(*ClientHelloInfo) (*Config, error)
It is called on receipt of a Client Hello message with a ClientHelloInfo struct. This struct contains the following fields of interest to you:
// CipherSuites lists the CipherSuites supported by the client (e.g.
// TLS_RSA_WITH_RC4_128_SHA).
CipherSuites []uint16
// SupportedVersions lists the TLS versions supported by the client.
// For TLS versions less than 1.3, this is extrapolated from the max
// version advertised by the client, so values other than the greatest
// might be rejected if used.
SupportedVersions []uint16
Please read the comments around GetConfigForClient and ClientHelloInfo for exactly how GetConfigForClient should behave, and for field details.
Specifying server-supported version and cipher suites:
This is also done through the tls.Config object using the following fields:
// CipherSuites is a list of supported cipher suites. If CipherSuites
// is nil, TLS uses a list of suites supported by the implementation.
CipherSuites []uint16
// MinVersion contains the minimum SSL/TLS version that is acceptable.
// If zero, then TLS 1.0 is taken as the minimum.
MinVersion uint16
// MaxVersion contains the maximum SSL/TLS version that is acceptable.
// If zero, then the maximum version supported by this package is used,
// which is currently TLS 1.2.
MaxVersion uint16
For example, you could set your tls.Config with the following fields:
CipherSuites: []uint16{
tls.TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
tls.TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
tls.TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
etc...
tls.TLS_RSA_WITH_AES_256_CBC_SHA,
},
MinVersion: tls.VersionTLS12,
The full list of supported cipher suites is in the tls docs.

How to set TLS cipher for Go server?

I'm currently using the following listen and serve command to run a secure websocket/file server:
http.ListenAndServeTLS(":443", "site.crt","site.key", router)
However, I want to set the cipher to TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and also set a min SSL/TLS version.
How can I do this?
I think I need to use this Config structure somehow, but I'm not sure how to do this.
2015: You can see an example in secrpc/tls_server.go:
tls.Listen("tcp", addr, &tls.Config{
Certificates: []tls.Certificate{cert},
CipherSuites: []uint16{
tls.TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
tls.TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
},
MinVersion: tls.VersionTLS12,
PreferServerCipherSuites: true,
})
See also go/issues/11047 for an example using ListenAndServeTLS: once you have defined your Config, you define your server:
server := &http.Server{Addr: ":4000", Handler: nil, TLSConfig: config}
server.L
In 2021, you also have "Automatic cipher suite ordering in crypto/tls" from Filippo Valsorda:
Go 1.17, recently released, takes over cipher suite preference ordering for all Go users.
While Config.CipherSuites still controls which TLS 1.0–1.2 cipher suites are enabled, it is not used for ordering, and Config.PreferServerCipherSuites is now ignored.
Instead, crypto/tls makes all ordering decisions, based on the available cipher suites, the local hardware, and the inferred remote hardware capabilities.

How to find out which cipher suites are supported by the FTP client via SSL/TLS?

I am running an FTP server based on Apache MINA/FTP and I keep getting the following exception when trying to connect in SSL mode:
javax.net.ssl.SSLHandshakeException: no cipher suites in common
I have verified that the cipher suites are set correctly on the client side like this:
SSLServerSocketFactory serverSocketFactory = (SSLServerSocketFactory)
SSLServerSocketFactory.getDefault();
String[] cipherSuites = serverSocketFactory.getDefaultCipherSuites();
SslConfigurationFactory sslConfigFactory = new SslConfigurationFactory();
sslConfigFactory.setKeystoreFile(keyStoreFile);
sslConfigFactory.setKeystorePassword(keyPass);
sslConfigFactory.setEnabledCipherSuites(cipherSuites);
sslConfigFactory.setSslProtocol("SSL");
SslConfiguration sslConfig = sslConfigFactory.createSslConfiguration();
sslFactory.setSslConfiguration(sslConfig);
Listener listener = sslFactory.createListener();
serverFactory.addListener("SSL-listener", listener);
So, how do I verify that the cipher suites used on the client side match the ones that are provided on the server side?
I am using FileZilla and Cyberduck for testing, but I haven't found anything in the settings of these clients that would tell which cipher suites are supported.
I found it useful to set the sysproperty javax.net.debug="ssl" at start time of the JVM and then watch stdout for a detailed report.