15

I have implemented SSLServerSocket and when I start .jar file with option -Djavax.net.debug=ssl:handshake to debug secure handshakes, I get also these messages (before establishing some secure connection):

...
Ignoring unavailable cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
Ignoring unavailable cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA
Ignoring unavailable cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256
Ignoring unavailable cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
Ignoring unavailable cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
Ignoring unavailable cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
Ignoring unavailable cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_128_CBC_SHA256
...

What does it mean? Maybe I missing 256 bit security in Java (to replace a few files in Java directory)?

After creating SSLServerSocket I have enabled secure protocols like:

socket.setEnabledProtocols(new String[]{"TLSv1","TLSv1.1","TLSv1.2","SSLv2Hello"});

Maybe I should enable these above cipher suites also?

Besides these cipher suites, everything works fine.

EDIT:

Yes, @Boris the Spider was right: after installing Oracle's unlimited strength policy files the warnings are no longer visible.

Ernestas Gruodis
  • 8,567
  • 14
  • 55
  • 117
  • 6
    Eugh, `SSLv2`?? For 256 bit security you need to install [Oracle's unlimited strength policy files](http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html). – Boris the Spider Feb 07 '15 at 09:22
  • Yes, because some SMTP servers only supports SSLv2... and if you're receiving the message, it simply discards it... (of course it should resend it without STARTTLS option later, but not all SMTP servers behave like that).. I've tryed to use only TLSv1, TLSv1.1, TLSv1.2 because of SSLv3 security issues - but the problem was the same - not all SMTP clients/servers support it... – Ernestas Gruodis Feb 07 '15 at 09:25
  • 4
    @Boris Java `SSLv2Hello` does not implement SSLv2, it only uses (client) or allows (server) SSLv2 *format* ClientHello to negotiate a better protocol per rfc5246 E.2 et pred. If the peer chooses (client) or demands (server) actual SSLv2, the handshake is aborted with an exception. This is a bit ugly, but not as bad as actually using SSLv2. – dave_thompson_085 Feb 07 '15 at 16:38

1 Answers1

2

So the answer is you need Oracle's unlimited strength policy files

Thanks Boris the Spider for the answer.

asm0dey
  • 2,841
  • 2
  • 20
  • 33
  • 2
    You're a few months out of date. As of (Oracle) java 9 released last Aug. and 8u151/152 released last Oct. you no longer need the policy jars, you only need to edit `JRE/lib/security/java.security` file at the entry for `crypto.policy`. – dave_thompson_085 Jan 27 '18 at 14:38
  • @dave_thompson_085 yup, but I needd to leave this answer for future generations to be able to find this answers. I do not need any pluses for this answer, it wasn't found by me. But this question shouldn't be in unanswered section. – asm0dey Jan 27 '18 at 19:54
  • Just a note for those using OpenJDK 11 (or maybe any Java 9+)... I found this page searching for a problem with similar error messages. For me, the problem was that I accidentally set system property "javax.net.ssl.keyStoreType" to "". If I set it to any other bad text it would throw a clear NoSuchAlgorithmException at startup. But the empty value "" was silently accepted. Unfortunately, that resulted in *all* my cipher suites being ignored as shown above, so SSLHandshakeException was thrown during connection attempts. It took many hours to find... I hope this note is useful to someone. – Chris Janicki Apr 20 '21 at 23:18