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
Getting error SOAPException: faultCode=SOAP-ENV:Client; msg=Error opening socket: javax.net.ssl.SSLException: java.lang.ArrayIndexOutOfBoundsException: Array index out of range: 64; targetException=java.lang.IllegalArgumentException: Error opening socket: javax.net.ssl.SSLException: java.lang.ArrayIndexOutOfBoundsException: Array index out of range: 64]"/> while connecting to a SOAP service
I am trying to connect to a SOAP service hosted in java 1.8 tomcat environment from IBM OMS system.
This is the main error :
javax.net.ssl.SSLException: java.lang.ArrayIndexOutOfBoundsException:
Array index out of range: 64'
The IBM JCE can throw this error if you are trying to handshake with TLS v1 on 2048 DH algorithm. 2048 DH key can be used only if you are handshaking with TLS 1.2 . Java 8 by default uses TLS v1.2
The error is because of the incompatibility between Key length (2048) and SSL handshake algorithm chosen (DHE).
IBM supports recommends three way to resolve this problem.
Upgrade the java to 8
Ask your destination to use DHE 1024 length and NOT DHE 2048.
Ask your destination to disable all the Diffie Hellman Ephemeral ciphers (DHE)
To ensure backward compatibility of my application, I'm testing JDBC over TLS behaviour when an MS SQL Server version vulnerable to CVE-2011-3389 is used (any 2005, or 2008/2008R2 w/o service packs fit). In theory, two options are available:
either disable CBC protection via -Djsse.enableCBCProtection=false and continue to use a block cipher such as AES_128_CBC or 3DES_EDE_CBC,
or fall back to a stream cipher such as RC4 (yes I'm aware this is insecure, too, due to CVE-2015-2808).
In practice, while I have no trouble establishing a connection using 3DES_EDE_CBC with CBC protection off, I'm still unable to use RC4_128 using an JDK newer than 1.8.0_51 (which happened to address CVE-2015-2808) or AES_{128,256}_CBC (using any 1.6+ JDK).
Here's the results broken down by Java version:
1.6.0_45 (jTDS)
SSL_RSA_WITH_RC4_128_MD5 is used
1.7.0_76 (jTDS) and any 1.8.0 up to 1.8.0_45 (MS SQL JDBC):
SSL_RSA_WITH_RC4_128_MD5 (default) or SSL_RSA_WITH_3DES_EDE_CBC_SHA can be used
won't use AES_128_CBC even if 3DES is disabled (3DES_EDE_CBC will be forced anyway)
1.8.0_45 (IBM J9 8.0 SR1) (MS SQL JDBC)
SSL_RSA_WITH_3DES_EDE_CBC_SHA is used (successful only if CBC protection is off), also if either AES or RC4 is requested
1.8.0_51+ (Oracle) (MS SQL JDBC)
SSL_RSA_WITH_3DES_EDE_CBC_SHA is used (successful only if CBC protection is off),
won't use AES_128_CBC or AES_256_CBC even if requested (unlike previous Java versions, 3DES is no longer forced, instead I get an IOException after ClientHello, which does list *_WITH_AES_128_CBC_SHA as compatible ciphersuites)
won't use RC4 even if both with AES and 3DES are disabled: "no negotiable cipher suite" (both jTDS and MS SQL JDBC).
Here's the java.security I use to request AES:
jdk.certpath.disabledAlgorithms=MD2
jdk.tls.disabledAlgorithms=SSLv3, RC4, TLSv1.1, TLSv1.2, 3DES_EDE_CBC
jdk.tls.legacyAlgorithms= \
K_NULL, C_NULL, M_NULL, \
RC4_128, RC4_40
and here's the version to request RC4:
jdk.certpath.disabledAlgorithms=MD2
jdk.tls.disabledAlgorithms=SSLv3, AES_128_CBC, TLSv1.1, TLSv1.2, AES_256_CBC, AES_128_GCM, AES_256_GCM, 3DES_EDE_CBC
jdk.tls.legacyAlgorithms= \
K_NULL, C_NULL, M_NULL
Questions:
Apparently, AES_{128,256}_CBC is supported by my Java clients, as I can use TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA when connecting to MS SQL Server 2014. Can anyone confirm it is not supported by MS SQL Server 2005? Since disabling AES effectively leads to "no negotiable cipher suite", I assume it is supported, but something happens server-side, even though CBC protection is off.
How can I still use RC4 in Java 1.8.0_51+? This solution no longer works, nor has any effect https.cipherSuites system property (described here). There's a magical jdk.tls.enableRC4CipherSuites system property in 6u115 and 7u101, but it seems to have no effect in Java 1.8.
What the heck is wrong with jTDS? It works fine with Java 1.6 and 1.7 (driver versions 1.2.8 and 1.3.1), but using Java 1.8 I'm constantly receiving "Connection reset by peer" whenever MS SQL JDBC would just use 3DES to encrypt connection data.
I am looking to connect to a server where they support the following key exchange method
ecdh-sha2-nistp521
ecdh-sha2-nistp384
ecdh-sha2-nistp256
diffie-hellman-group-exchange-sha256
diffie-hellman-group14
diffie-hellman-group
I am using jsch jsch-0.1.53 and using RSA private/public key to connect to the server. This works fine before not until the server was changed and now returning this strange error
com.jcraft.jsch.JSchException: SSH_MSG_DISCONNECT: 11 No appropriate prime between 1024 and 1024 is available. en
at com.jcraft.jsch.Session.read(Session.java:899)
at com.jcraft.jsch.Session.connect(Session.java:294)
at com.jcraft.jsch.Session.connect(Session.java:154)
I am running and compiling the project using java 1.6.0_16.
Any idea how to resolve this issue please ?
I had the same problem with jsch 0.1.53 and Java 1.7.0_05
It got solved when I update to Java 1.8_101
I am trying to authenticate my client application with the server over https - i am using axis 1.4 jar. I am passing the correct JKS file to the truststore. However, i am getting following exception.
Caused by: javax.net.ssl.SSLException: Server key
at com.sun.net.ssl.internal.ssl.Handshaker.throwSSLException(Handshaker.java:927)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:199)
at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:593)
at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:529)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:958)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1203)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1230)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1214)
at org.apache.axis.components.net.JSSESocketFactory.create(JSSESocketFactory.java:186)
at org.apache.axis.transport.http.HTTPSender.getSocket(HTTPSender.java:191)
at org.apache.axis.transport.http.HTTPSender.writeToSocket(HTTPSender.java:404)
at org.apache.axis.transport.http.HTTPSender.invoke(HTTPSender.java:138)
... 26 more
Caused by: java.security.spec.InvalidKeySpecException: does not support java.security.spec.ECPublicKeySpec
at com.certicom.ecc.jcae.ECKeyFactorySpi.engineGeneratePublic(Unknown Source)
at java.security.KeyFactory.generatePublic(KeyFactory.java:304)
at com.sun.net.ssl.internal.ssl.HandshakeMessage$ECDH_ServerKeyExchange.<init>(HandshakeMessage.java:910)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:195)
... 36 more
It was identified that the ECDH cipher suite is not part of java 1.6 setup by default which causes the exception of ECDH spec not supported.
This was fixed by added this spec which comes in the bcprov-jdk1.6.jar (bouncycastle) in the java setup. To do this do following changes
java/jdk1.6.0_45\jre\lib\security\java.security
security.provider.1=org.bouncycastle.jce.provider.BouncyCastleProvider
[Note: security.provider.1 - numbering denotes the priority of choosing the cipher suite]
and add the bcprov-jdk1.6.jar inside jdk1.6.0_45\jre\lib\ext