TransportClient with SGSSL + ES without SG

I just did a test with the following:

  • ES 5.2.2 without SG installed

  • A java application with a transport client configured the way is described in the SG Java TLS docs.

Yes, this is not a typical use case. We are exploring what would happen if we have to revert our ES to not use SG. Would we have to revert our TransportClient code to not provide TLS certs, etc.

I got an exception about the stream not having the proper format.
Caused by: java.io.StreamCorruptedException: invalid internal transport message format, got (16,3,3,0)

es_1 | at org.elasticsearch.transport.TcpTransport.validateMessageHeader(TcpTransport.java:1226) ~[elasticsearch-5.2.2.jar:5.2.2]

es_1 | at org.elasticsearch.transport.netty4.Netty4SizeHeaderFrameDecoder.decode(Netty4SizeHeaderFrameDecoder.java:36) ~[?:?]

es_1 | at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:411) ~[?:?]

``

Question: is this expected with such a use-case? Or do you suspect that it should work, and that this exception is a problem to solve.

No, this will not work. If you add the SG plugin to your Transport Client, it will talk TLS to Elasticsearch. Since you removed the SG plugin from your cluster, it can’t talk TLS anymore, hence the communication fails. This is what you see in the error message.

···

On Thursday, August 3, 2017 at 11:09:10 AM UTC+2, mcostantini@np6.com wrote:

I just did a test with the following:

  • ES 5.2.2 without SG installed
  • A java application with a transport client configured the way is described in the SG Java TLS docs.

Yes, this is not a typical use case. We are exploring what would happen if we have to revert our ES to not use SG. Would we have to revert our TransportClient code to not provide TLS certs, etc.

I got an exception about the stream not having the proper format.
Caused by: java.io.StreamCorruptedException: invalid internal transport message format, got (16,3,3,0)

es_1 | at org.elasticsearch.transport.TcpTransport.validateMessageHeader(TcpTransport.java:1226) ~[elasticsearch-5.2.2.jar:5.2.2]

es_1 | at org.elasticsearch.transport.netty4.Netty4SizeHeaderFrameDecoder.decode(Netty4SizeHeaderFrameDecoder.java:36) ~[?:?]

es_1 | at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:411) ~[?:?]

``

Question: is this expected with such a use-case? Or do you suspect that it should work, and that this exception is a problem to solve.

Many thanks.

···

On Thursday, August 3, 2017 at 6:43:52 PM UTC+2, Jochen Kressin wrote:

No, this will not work. If you add the SG plugin to your Transport Client, it will talk TLS to Elasticsearch. Since you removed the SG plugin from your cluster, it can’t talk TLS anymore, hence the communication fails. This is what you see in the error message.

On Thursday, August 3, 2017 at 11:09:10 AM UTC+2, mcost...@np6.com wrote:

I just did a test with the following:

  • ES 5.2.2 without SG installed
  • A java application with a transport client configured the way is described in the SG Java TLS docs.

Yes, this is not a typical use case. We are exploring what would happen if we have to revert our ES to not use SG. Would we have to revert our TransportClient code to not provide TLS certs, etc.

I got an exception about the stream not having the proper format.
Caused by: java.io.StreamCorruptedException: invalid internal transport message format, got (16,3,3,0)

es_1 | at org.elasticsearch.transport.TcpTransport.validateMessageHeader(TcpTransport.java:1226) ~[elasticsearch-5.2.2.jar:5.2.2]

es_1 | at org.elasticsearch.transport.netty4.Netty4SizeHeaderFrameDecoder.decode(Netty4SizeHeaderFrameDecoder.java:36) ~[?:?]

es_1 | at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:411) ~[?:?]

``

Question: is this expected with such a use-case? Or do you suspect that it should work, and that this exception is a problem to solve.