Lumberjack (beats) output not supporting SNI TLS enpoints?

(Rolf) #1

Hi all

We're testing with logstash/beats/elasticsearch and are having a data flow (like beats => logstash => elasticsearch) over different networks.

this works fine as long as there is no cloud (i.e. openshift) involved. cloud solutions require to use SNI to indicate what TLS enpoint should be used and since we're not able to setup this using the documented configuration we were asking ourselves if support for SNI is missing in lumberjack output plugin.

Looking at the code for lumberjack plugin implemenetation we cannot see any signs of SNI being used.

can anyone confirm our observation? is lumberjack unable to support SNI and thus is unable to be used in cloud environments (requiring SNI)?

Thanks for any feedback!

(Rolf) #2

So, after some time have passed (and some source code lines have been read ;)) here's news about this. we think we'd share the information we could get if anyone else came across here...

in short:
use beats not logstash

long version:
we'd thought that the lumberjack protocol is implement / used the same way in logstash as it is in beats too. points out there is a ruby-lumberjack implementation (used by logsash) and a go-lumber(jack) (used by beats).

so it turns out the go-implementation does support the use-case of multiple certificates on one IP (cloud) by correctly setting SNI. the current ruby-lumberjack (client.rb lines 94-95) does not set a hostname (as documented by ruby openssl doc) and thus it will only work if there is one single certificate (and thus no SNI is required).

a modification seems required to support SNI in ruby-lumberjack, where it makes sense to add another parameter (since its totally optional) named "ssl_hostname" for example. if there is interest by anyone (capable of accepting a MR) we can provide more details here.

our main use case will use beats so we're fine here, we discovered this at testing level where we used logstash-to-logstash communication instead of beats-to-logstash (which will be a future use-case probably).

(system) #3

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.