We have discovered that in some cases and some plaftorms
configuring a default `verify_mode` when creating a SSL/TCPServer
could make the certificate verification fail. Ruby default behavior is
to use `NIL` when creating a new ssl context, this revert that change.
keep in mind that all TCP clients using SSL **must** use `VERIFY_PEER`
as their verify mode to prevent man in the middle attack.
Fix: https://github.com/elastic/logstash/issues/3657
Since the defaults are constant strings, ensure the `I18n` text uses the
same defaults as does the Ruby code
Also, update the comment about line length to match the "55" that is
both correct and used further down in the file.
Fixes#1456
New defaults:
* Cipher suite based on Mozilla's Intermediate set from
https://wiki.mozilla.org/Security/Server_Side_TLS (at time of writing)
* Disable SSLv2 explicitly
* Disable SSLv3 explicitly
* Disable compression if possible
The SSL option setting came from the ruby-ftw library's FTW::Connection
(apache 2 licensed, I am author), and transitively through work
published by jmhodges to improve Ruby's SSL strength.
I include specs to ensure we never include export or weak ciphers by
default.
Using this patch to test the security improvements according to
`www.howsmyssl.com` shows much improved results:
---
Testing this:
```
ruby -r ./lib/logstash/patches/stronger_openssl_defaults.rb -ropenssl -rsocket -rjson -rawesome_print -e 'c = OpenSSL::SSL::SSLContext.new; t = TCPSocket.new("www.howsmyssl.com", 443); o = OpenSSL::SSL::SSLSocket.new(t, c); o.connect; o.puts "GET /a/check HTTP/1.1\r\nHost: www.howsmyssl.com\r\n\r\n"; headers,body = o.read.split("\r\n\r\n", 2); puts body'
```
(I processed the JSON output w/ jq for easier reading)
The purpose of the above is to test the default behavior of SSLContext.
* JRuby 1.7.19 w/ this patch reports no cipher problems.
* JRuby 1.7.19 without this patch has several weak ciphers used:
```
"TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA: [\"uses keys smaller than 128 bits in its encryption\"]",
"TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA: [\"uses keys smaller than 128 bits in its encryption\"]",
"TLS_DHE_RSA_WITH_DES_CBC_SHA: [\"uses keys smaller than 128 bits in its encryption\"]",
"TLS_RSA_EXPORT_WITH_DES40_CBC_SHA: [\"uses keys smaller than 128 bits in its encryption\"]",
"TLS_RSA_EXPORT_WITH_RC4_40_MD5: [\"uses keys smaller than 128 bits in its encryption\",\"use RC4 which has insecure biases in its output\"]",
"TLS_RSA_WITH_DES_CBC_SHA: [\"uses keys smaller than 128 bits in its encryption\"]",
"TLS_RSA_WITH_RC4_128_MD5: [\"use RC4 which has insecure biases in its output\"]",
"TLS_RSA_WITH_RC4_128_SHA: [\"use RC4 which has insecure biases in its output\"]"
```
Under MRI, similar cipher selection problems are observed without this patch (weak export
ciphers, other weak small-key ciphers, RC4 complaints). With this patch, no cipher complaints
are reported by www.howsmyssl.com
One other note: Because JRuby defaults to TLS 1.0 and only makes CBC ciphers
available under the Mozilla Intermediate cipher set, I believe (and
howsmyssl.com agrees) that these defaults still make the BEAST exploit a
problem. Switching to TLS 1.1 should fix this, but we need to do more research
to determine the what, if any, impact it will have if we force TLS 1.1 to be
the default..
Fixes#3579
Add a pre release gem test by using a mock to reproduce the behaviour
reaised by Gem::Specification.find_by_name when dealing with pre release
gems.
Fixes#3476
make the eager loading patterns consistent in the spec_helper.rb file
make the setup-simplecov task not a dependency, but an explicit task only executed when ENV['COVERAGE'] is defined
refactor eager loading code plus add some documentation to the setup-simplecov task
Added more comments to the test:setup task
Fixes#3465
This PR allow the Event class to compile a `sprintf` the first time and
reuse the template for the other calls. This strategy speeds up considerably
calls that uses date formatting or use fieldref its a bit slower if you
dont do any string manipulation.
Fixes#3425
We were synchronizing on the tick and the flush call,
in some situation it could set logstash in a deadlock when the queue was
blocked and the tick occurred. The flush call was already thread safe
since only one worker can start the flushing process.
Fixes#3378
