No Cipher suites in common || SSLv3 not enabled or not supported

jliaocxr · November 1, 2015, 10:48pm

Hi,

I am receiving following exception with shield installation on 2.0 ES. Its quite similar to SSL certificate error - no cipher suites in common

[2015-11-01 16:01:15,324][WARN ][shield.transport.netty ] [node01]
Caught exception while handling client http traffic, closing connection
[id: 0x5479d43a, /127.0.0.1:33934 => /127.0.0.1:9200]
javax.net.ssl.SSLHandshakeException: no cipher suites in common
at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1431)
.
.
.
Caused by: javax.net.ssl.SSLHandshakeException: no cipher suites in common
at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1666)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:304)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:292)
.
.
.
And downsomewhere in the trace i have the following exception:
Caused by: javax.net.ssl.SSLHandshakeException: Client requested protocol SSLv3 not enabled or not supported

when I run the following curl command
curl -u es_admin -XGET 'https://127.0.0.1:9200'

Output is:
Enter host password for user 'es_admin': (I Provide the correct password)
curl: (35) error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake fail

Output for: openssl s_client -connect 127.0.0.1:9300
CONNECTED(00000003)
139800579409568:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:762:
no peer certificate available
No client certificate CA names sent
SSL handshake has read 7 bytes and written 317 bytes
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE

It seems like there's something wrong with the certificate only. I created my own CA anf followed steps on:

https://www.elastic.co/guide/en/shield/current/certificate-authority.html
https://www.elastic.co/guide/en/shield/current/ssl-tls.html

Ron_Pritchett · November 2, 2015, 4:37pm

SSL is no longer secure. It looks like what you're connecting to has SSL disabled (in favor of TLS), but your client doesn't support TLS. You'll want to add TLS support to your client.

https://en.wikipedia.org/wiki/Transport_Layer_Security#Security (for some general information)

Hopefully that points you in the right direction.

jliaocxr · November 2, 2015, 7:18pm

Thanks for replying Ron. It does point me to the right direction.

I will try to add TLS support to ES (which I will start exploring now, i don't have much idea around it).
In the meanwhile anyone's response related to it would be really appreciated.

skearns · November 2, 2015, 8:00pm

Hi John,

What versions of ES + Shield are you running?
What JVM version are you using to run ES?

Have you made any changes to shield.ssl.protocol or shield.ssl.supported_protocols in your elasticsearch.yml? By default, Shield 1.3+ uses TLSv1.2

You can find the settings here: https://www.elastic.co/guide/en/shield/current/reference.html#ref-ssl-tls-settings
Note that after setting these in your elasticsearch.yml, you do need to restart your ES node/cluster.

Thanks,
Steve

jliaocxr · November 2, 2015, 8:35pm

Hi Steve,

ES version is 2.0.0 and shield version is 2.0.0 and I'm using jdk1.8.0_65.

I didn't change shield.ssl.protocol or shield.ssl.supported_protocols earlier but AFTER reading your post. I tried using these the following way:

shield.ssl.protocol: SSLv3
shield.ssl.supported_protocols: SSLv3

but still it gives the following error on hitting : https://127.0.0.1:9200

[2015-11-02 14:30:23,550][WARN ][shield.transport.netty ] [node01] Caught exception while handling client http traffic, closing connection [id: 0xb4710d3e, /127.0.0.1:38120 => /127.0.0.1:9200]
javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)
at sun.security.ssl.Handshaker.activate(Handshaker.java:503)
at sun.security.ssl.SSLEngineImpl.kickstartHandshake(SSLEngineImpl.java:729)
.
.
. org.jboss.netty.handler.ipfilter.IpFilteringHandlerImpl.handleUpstream(IpFilteringHandlerImpl.java:154)
at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:559)
.
.
.
[2015-11-02 14:30:23,552][WARN ][shield.transport.netty ] [node01] Caught exception while handling client http traffic, closing connection [id: 0x7164d2b7, /127.0.0.1:38121 => /127.0.0.1:9200]
javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)
at sun.security.ssl.Handshaker.activate(Handshaker.java:503)
at sun.security.ssl.SSLEngineImpl.kickstartHandshake(SSLEngineImpl.java:729)
at sun.security.ssl.SSLEngineImpl.beginHandshake(SSLEngineImpl.java:756)
at org.jboss.netty.handler.ssl.SslHandler.handshake(SslHandler.java:361)
at org.jboss.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1198)
at org.jboss.netty.handler.ssl.SslHandler.decode(SslHandler.java:852)
at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:425)
at org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:303)
at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70)
at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
at
.
.
.
[2015-11-02 14:30:23,588][WARN ][shield.transport.netty ] [node01] Caught exception while handling client http traffic, closing connection [id: 0xa9f265d7, /127.0.0.1:38124 => /127.0.0.1:9200]
javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)
at sun.security.ssl.Handshaker.activate(Handshaker.java:503)
at sun.security.ssl.SSLEngineImpl.kickstartHandshake(SSLEngineImpl.java:729)
at sun.security.ssl.SSLEngineImpl.beginHandshake(SSLEngineImpl.java:756)
at org.jboss.netty.handler.ssl.SslHandler.handshake(SslHandler.java:361)
at org.jboss.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1198)
at org.jboss.netty.handler.ssl.SslHandler.decode(SslHandler.java:852)
at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:425)
at org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:303)
at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70)
at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)
at org.jboss.netty.handler.ipfilter.IpFilteringHandlerImpl.handleUpstream(IpFilteringHandlerImpl.java:154)
at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:559)
at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268)
at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255)
at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:88)
at org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:108)
at org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:337)
at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:89)
at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178)
at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108)
at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)

Should I set these values to some other protocol?

Thanks,
John

skearns · November 2, 2015, 10:07pm

Hi John,

SSLv3 isn't a secure protocol anymore, and Oracle disables support for it by default as of jdk1.8.0_31: http://www.oracle.com/technetwork/java/javase/documentation/cve-2014-3566-2342133.html

The problem is that your clients are declaring they only speak SSLv3, and Shield isn't able to respond, because the JVM disabled SSLv3. You'll need to remove that setting and I suggest making sure that your clients can speak any the supported flavors of TLS.

I believe it is technically possible to re-enable SSLv3 on your JVM, but it's disabled for a very good reason so we do not recommend using it.

Thanks,
Steve

jliaocxr · November 2, 2015, 10:19pm

Hi Steve,

When you say client, I believe you are referring to browser because I'm accessing ElasticSearch through URL "https://127.0.0.1:9200" on my browser. So I'm trying to understand do you want me to make some tweak to browser so that It no more send SSLv3 requests?

Or I'm using curl command to interact with shield using the same url above.

And Steve, I really appreciate your efforts in helping me through this.

Thanks,
John

skearns · November 2, 2015, 10:38pm

What browser are you using? (type, version, any special config)
What OS/version?

jliaocxr · November 2, 2015, 10:44pm

Firefox 31.0, Mozilla FF for Ubuntu canonical - 1.0, no special config.
Ubuntu 14.04.1 LTS

skearns · November 2, 2015, 11:50pm

Hi John,

That looks to be a rather old version of Firefox, where SSLv3 was still enabled. Can you try disabling SSLv3 support in Firefox or installing a newer version?

This seems to describe how to do it: http://disablessl3.com/#firefox

jliaocxr · November 3, 2015, 12:00am

I tried that as well just a minute ago. But still same response. Just for your reference the yml file config:

cluster.name: elasticsearch
node.name: node01

shield.ssl.truststore.path: /home/john/Downloads/elasticsearch-2.0.0/config/shield/truststore.jks
shield.ssl.truststore.password: impetus
shield.ssl.keystore.path: /home/john/Downloads/elasticsearch-2.0.0/config/shield/node01.jks
shield.ssl.keystore.password: testpassword
shield.ssl.keystore.key_password: testpassword
shield.transport.ssl: true
shield.http.ssl: true
shield.ssl.hostname_verification.resolve_name: false
shield.ssl.hostname_verification: false
ssl_certificate_verification: true
discovery.zen.ping.multicast.enabled: false
discovery.zen.ping.unicast.hosts: ["node01:9300"]

jliaocxr · November 3, 2015, 12:17am

I ran following command to check whether Shield is able to connect when connected via TLSv1 using openssl:

openssl s_client -connect 127.0.0.1:9300 -tls1

It results in following output:

CONNECTED(00000003)
139722194011808:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1260:SSL alert number 40
139722194011808:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:596:

no peer certificate available

No client certificate CA names sent

SSL handshake has read 7 bytes and written 0 bytes

New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1446509729
Timeout : 7200 (sec)
Verify return code: 0 (ok)

And before doing that I added the following properties to yml file:

shield.ssl.protocol: TLSv1
shield.ssl.supported_protocols: SSLv2Hello, SSLv3, TLSv1, TLSv1.1, TLSv1.2

Which means there's something definately wrong with configuration/certificate.

skearns · November 3, 2015, 3:32pm

John, just to triple-check, every time you make a change to the elasticsearch.yml, you are stopping and restarting your node ES, right? Can you stop your node, and make a request to localhost:9200 or localhost:9300, and make sure that there are no other instances of ES running?

Thanks,
Steve

jliaocxr · November 3, 2015, 7:12pm

Thanks for checking again Steve. It is always good to be sure.

I just have a single node running on that machine and everytime I make any change in elasticsearch.yml, I stop that node and ensure using JPS command that it stops completely and no more running in background. Then I start it again using bin/elasticsearch.

I hope everything is ok with my yml that I shared with you in my previous post. Also in post# 12 I shared the output of openssl s_client -connect 127.0.0.1:9300 -tls1. Does it give you any hint what may be wrong.

Thanks,
John

jaymode · November 10, 2015, 1:12pm

Hi John,

Were you able to get this working? If not, what do you get in the elasticsearch logs when running the openssl command with the -tls1 switch? How about trying the -no_ssl3 switch?

Thanks,

Jay

jliaocxr · November 11, 2015, 11:43pm

I just resolved this issue and then I came back to this thread to post the solution and saw your post Jay. I don't remember exactly what it was but yes it used to have "no common cipher....".

There are 2 Issues that were causing the problem (actually 1, just the first one below but later I faced 2 as well):

I might have used dns in keytool command like san=dns:sandbox,ip:10.0.2.15,dns:localhost,ip:127.0.0.1 and giving it like san=dns:node01.example.com,ip:127.0.0.1, seems to work fine.
Enhancement done in elasticsearch 2.x for security. https://github.com/elastic/elasticsearch/issues/13966

Thanks @Ron_Pritchett @skearns and @jaymode for helping me through this.

Thanks,
John