On my Netty server, I need to exclude TLS_1.0 and TLS_1.1 protocols. However, seems like Netty SslContextBuilder doesn't allow to exclude specific suits.
Current code is used to build a SSL context:
SslContextBuilder.forServer(serverCert, serverKey, serverPass)
.sslProvider(sslProvider)
.build();
SslContextBuilder has ciphers() method, but it's not clear how to exclude specific ciphers for the TLS_1.0 and TLS_1.1.
Is there any way to achieve that?
You would just specify the protocols you want to support:
SslContextBuilder.forServer(serverCert, serverKey, serverPass)
.sslProvider(sslProvider).protocols(...)
So only include TLSv1.2 and TLSv1.3 here.
Another possibility would be to specify your custom CipherSuiteFilter which filters out ciphers you don't want to support.
Related
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).
I generated a golang server with go-swagger. I set the scheme to https (and only https). When I startup my server I get a TLS error.
the required flags `--tls-certificate` and `--tls-key` were not specified
It is clear that I haven't properly set my TLS flags but I really don't know the best way to to do this in go with go-swagger.
Anyone have any experience setting up TLS with go-swagger as I couldn't find any good links?
Thank you.
When you get certificates you get a private key file and a public key (certificate) file.
Here's an example of how they are used: https://github.com/go-swagger/go-swagger/tree/master/examples/todo-list#run-full-server
./todo-list-server --tls-certificate mycert1.crt --tls-key mycert1.key
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.
I am trying to block SSL as a measure against Poodle vulnerability.
Is it possible to alter the ciphers list rather than do something to disable the SSL compatibility and switch to TLS???
Individual servers must be configured to disable SSL and use TLS exclusively - it is not a system-wide configuration.
I expect that most software in the official Fedora channels will have been updated to disable SSL where possible, but you will need to check that the server software you are using is configured appropriately.
How to disable SSL and switch to TLS for Openssl on fedora?
For OpenSSL, the answer is platform agnostic.
To disable SSL and only allow TLS, perform the following:
const SSL_METHOD* method = SSLv23_method();
if(NULL == method) handleFailure();
SSL_CTX* ctx = SSL_CTX_new(method);
if(NULL == ctx) handleFailure();
const long flags = SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3 | SSL_OP_NO_COMPRESSION;
SSL_CTX_set_options(ctx, flags);
/* No error code returned */
The SSLv23_method says "give me SSLv2 and above". You then remove the unwanted SSLv2 and SSLv3 protocols with SSL_CTX_set_options.
You should also call SSL_set_cipher_list to set your preferred cipher list. Something like:
const char* const PREFERRED_CIPHERS = "HIGH:!aNULL:!kRSA:!PSK:!SRP!MD5:!RC4";
res = SSL_CTX_set_cipher_list(ctx, PREFERRED_CIPHERS);
if(1 != res) handleFailure();
IF you control both the client and server, then only use TLS 1.2 and the AES/GCM and Camellia/GCM cipher suites. If you are interacting with compatible servers, then ChaCha20 is OK, too; but its not available everywhere (see, for example, ChaCha20 and Poly1305 based Cipher Suites for TLS
).
The GCM cipher suites (and the ChaCha20 stream cipher) avoid some bugs built into the protocol at the architectural level. They are the cause of the padding attacks.
Is it possible to alter the ciphers list rather than do something to disable the SSL compatibility and switch to TLS???
No. Protocols and cipher suites are two different things. You have to address them in turn.
I want to explicitly enable certain cipher-suites on my WildFly application server.
Therefore I tried to edit the configuration in wildflys standalone.xml.
Let's assume I want to enable the AES128-GCM-SHA256 cipher (cipher suite names from: OpenSSL documentation).
I've edited the standalone.xml file of my WildFly server like this:
<https-listener name="listener" socket-binding="https" security-realm="ssl-realm" enabled-cipher-suites="AES128-GCM-SHA256"/>
The WildFly boots up normally but when I open the page in my browser an error message appears.
Chrome says:
ERR_SSL_PROTOCOL_ERROR
Firefox says:
ssl_error_internal_error_alert
I've tried this with WildFly 8.1 and 8.2.
Anybody out there who can give my an advice how to correctly enable certain cipher-suites?
Regards Tom
You have to add a attribute called "enabled-cipher-suites" to the "https-listener" found at "subsystem undertow" -> "server".
An example for this configuration can be found here.
Unfortunately this example is wrong when it comes to the value of this attribute. You must not name such things as "ALL:!MD5:!DHA" but instead some explicit cipher suites.
You have to call em by their SSL or TLS cipher suites names and not their OpenSSL names.
So instead of "AES128-GCM-SHA256" you have to write "TLS_RSA_WITH_AES_128_GCM_SHA256".
To make the confusion complete you have to use "," instead of ":" as delimiter if you want to name more than one suite.
Regards
Ben
I can confirm Ben's answer. The documentation for how to configure this is sparse. I would suggest the following ciphers to support:
TLS_RSA_WITH_AES_128_GCM_SHA256,
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
in addition, the 'ALL' tag does not work and the best method is to list the ones that you wish to include and not the ones that you wish to exclude as that '!' marking does not appear to be supported.