[WIP] Feature: TLS on TCP connections (includes certificate authentication)

[milgner]

This has been successfully used with our Graylog 2.0.1 server but should be considered work in progress. I'd just like to get the discussion rolling and receive some feedback.

There are some changes in here which aren't related to TLS but which were convenient to make while the file was open anyway. If you want to extract these into a separate PR, let me know.

Changelist:

• make use of some Enumerable methods for more concise code
• remove unnecessary uses of self and a begin block
• fix GELF::Transport::TCP#addresses
• extract some magic numbers into constants
• replace class_eval with define_method
• support setting keepalive flag on TCP connections
• support TLS on TCP connections, including certificate authentication

Todo:

• [ ] Investigate why connect_nonblock raises SSLErrorWaitReadable and how to do it correctly
• [ ] Tests - any ideas how to best test TCP/TLS code? Fake socket objects come to mind.
• [ ] CLA?
• [ ] Split into separate PR for "drive-by" changes

Looking forward to hearing from you!

[kaiomagalhaes]

@milgner How can I configure to use the TLS?

[milgner]

For simple encryption just initialize with protocol: GELF::Protocol::TCP, tcp: { tls: true }. If you want to use certificate authentication or do additional configuration of the TLS features, best look at the initializer documentation in lib/gelf/transport/tcp_tls_socket.rb. Right now you need to either configure the server to use a proper certificate from a well-known CA or disable CA verification (not recommended). Certificate pinning (i.e. expecting a specific certificate on the remote) is a feature that I haven't implemented yet, probably going to tackle that next weekend along with the other points in this PR.

[milgner]

A quick update on this: we have now been using this version for a couple of days without problems. There was a slight bug (tentatively fixed) where it would raise OpenSSL exceptions in case the Graylog server could not be reached. This is something that I need to investigate some more especially with regards to re-establishing the connection.

Update to the update: the best solution here would probably to use Celluloid::IO or a similar framework to generally move blocking TCP communication out of the senders execution context.

[milgner]

Closing in favour of #46.