Referencing this doc, https://www.eclipse.org/jetty/documentation/current/configuring-ssl.html#configuring-sslcontextfactory-cipherSuites toward the top there is a note:
Once TLS v1.3 is released, there will be no workaround available for TLS v1.0 or v1.1.
Plans for TLS v1.3 include banning ciphers with known vulnerabilities from being present at any level. It is recommended to upgrade any clients using these ciphers as soon as possible or face being locked into a outdated version of Jetty, Java or even OS.
The change log for Jetty 9.4.12, includes the following:
2711 TLS 1.3 compliance
Is it confirmed that as of Jetty 9.4.12 and newer, it is no longer possible to override the default ciphers and re-enable support for TLS 1.0 and 1.1?
There is bug that Issue with default cipher excludes all about TLS1.0
: https://github.com/eclipse/jetty.project/issues/3773
private SslContextFactory(boolean trustAll, String keyStorePath)
{
setTrustAll(trustAll);
addExcludeProtocols("SSL", "SSLv2", "SSLv2Hello", "SSLv3");
setExcludeCipherSuites("^.*_(MD5|SHA|SHA1)$");
if (keyStorePath != null)
setKeyStorePath(keyStorePath);
}
The names of TLS v1.0 cipher suites are matched with above "^.*_(MD5|SHA|SHA1)$", from https://www.openssl.org/docs/man1.1.0/man1/ciphers.html
Related
I am confused about which TLS version is used, when inspecting packets in Wireshark.
In the Client Hello package it says "TLSv1.3 Record Layer", the version beneath says "TLS 1.0" and for the Handshake Protocol it says "Version: TLS 1.2".
Because RFC 8446 descirbed:
struct {
ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */
Random random;
opaque legacy_session_id<0..32>;
CipherSuite cipher_suites<2..2^16-2>;
opaque legacy_compression_methods<1..2^8-1>;
Extension extensions<8..2^16-1>;
} ClientHello;
The client must use 0x0303 (TLS 1.2) to make TLS 1.3 handshake successfully when some interval server did not implement TLS version negotiation correctly.
Instead, we use supported_versions in the Extension to tell the server that the client can support the TLS 1.3:
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've got a question of how to enforce TLSv1.2 in tibjms 8.3 client? In tibems 8.3 release note it said TLSv1.2 is supported. But I don't know how to set it in tibjms client? (which I am using)
According to the tibco documentation of TibjmsContext, the SECURITY_PROTOCOL parameter could be only accepting "ssl"
So how is TLSv1.2 supported in tibco? Can we programmatically set it in client?
TIBCO has confirmed the bug and has issued hotfix 010
(tib_ems_8.3.0_hf_010), contact them for more details.
For Enabling TLS V1.2 in TIBCO BW 5.13, add the following in
bwengine.tra file(available in the path TIBCO_HOME\bw\5.13\bin) :
"java.property.TIBCO_SECURITY_VENDOR=j2se"
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.
We are migrating to WAS 8.5.5 and TLS 1.2 and are observing some unexpected problems.
The inputs are:
Worklight 6.1.0.1
WAS 8.5.5.9 + SDK Java 8
WAS is switched to TLS 1.2 (following this guide
https://developer.ibm.com/answers/questions/206952/how-do-i-configure-websphere-application-server-ss.html)
Application is Hybrid
When we use application via web emulator - it works fine.
When we use it from hardware device (Android or iOS) via IMC - we get exception that says
"client" uses TLS 1.1
server uses TLS 1.2
error of HTTPS handshake
It's not clear what is "client" in that case and why it uses TLS v1.1.
iOS device (iPhone) web browser is TLS 1.2 enabled - can open HTTPS links with TLS 1.2 protocol.
Here is full stack trace from SystemOut.log
[6/14/16 11:16:32:197 EDT] 000000b2 SSLHandshakeE E SSLC0008E: Unable to initialize SSL connection. Unauthorized access was denied or security settings have expired. Exception is javax.net.ssl.SSLHandshakeException: Client requested protocol TLSv1.1 not enabled or not supported
at com.ibm.jsse2.C.z(C.java:532)
at com.ibm.jsse2.ap.b(ap.java:476)
at com.ibm.jsse2.ap.c(ap.java:112)
at com.ibm.jsse2.ap.wrap(ap.java:277)
at javax.net.ssl.SSLEngine.wrap(SSLEngine.java:21)
at com.ibm.ws.ssl.channel.impl.SSLUtils.handleHandshake(SSLUtils.java:748)
at com.ibm.ws.ssl.channel.impl.SSLConnectionLink.readyInbound(SSLConnectionLink.java:567)
at com.ibm.ws.ssl.channel.impl.SSLConnectionLink.ready(SSLConnectionLink.java:296)
at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminators(NewConnectionInitialReadCallback.java:214)
at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:113)
at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:175)
at com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:217)
at com.ibm.io.async.AsyncChannelFuture$1.run(AsyncChannelFuture.java:205)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1881)
Caused by: javax.net.ssl.SSLHandshakeException: Client requested protocol TLSv1.1 not enabled or not supported
at com.ibm.jsse2.j.a(j.java:31)
at com.ibm.jsse2.ap.a(ap.java:11)
at com.ibm.jsse2.C.a(C.java:342)
at com.ibm.jsse2.C.a(C.java:100)
at com.ibm.jsse2.E.a(E.java:140)
at com.ibm.jsse2.E.a(E.java:813)
at com.ibm.jsse2.C.r(C.java:44)
at com.ibm.jsse2.C$b.a(C$b.java:2)
at com.ibm.jsse2.C$b.run(C$b.java:3)
at java.security.AccessController.doPrivileged(AccessController.java:686)
at com.ibm.jsse2.C$c.run(C$c.java:11)
at com.ibm.ws.ssl.channel.impl.SSLUtils.handleHandshake(SSLUtils.java:835)
... 8 more
I have no idea what our next steps should be.
Any help will be much appreciated.
Seems pretty clear that TLSv1.2-only is too aggressive for your clients. In terms of WAS config, "ssl_tlsv2" is probably the best you can do.
IMC was causing it. Had to configure it to start using TLS v1.2