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
correct use of @lut and cleanups
leftover
added docs and renamed a few identifiers for clarity
typos
remove strict_set stuff since its not used anymore
removed unused specs
PathCache thread safety
This is a followup of the issues #2850 and #3281.
The following configuration:
if [condition] {
} else if [condition1]
or [condition2] {
..
}
Was compiled to ruby like this:
elsif condition or condition2 # else if [condition1]
or [condition2]
and making the intepreter fails.
Fixes#3386
The previous fix for disabling the `.bundle/config` wasn't not respecting the bundler contract.
The failling tests were not wrong, in fact they exposed the issue that the configuration was transient and the underlying hash of bundler was not correctly keeping the updated values.
This patch make sure the hash is updated with the new or deleted value without persisting the change to disk.
Fixes#3332
Logstash's config compiler adds a comment to the compiled code, like
if ..... # if [your] and [conditional]
The idea is to to help aid in reading the compiled logstash config.
However, if a conditional has newlines in it, the `#text_value` of
that conditional will have newlines, and we'll accidentally create
invalid ruby code which will fail with SyntaxError.
Prior to this change, the following Logstash config, under 1.5.0,
would cause a crash on startup:
if [some]
or [condition] {
...
}
The cause was that Logstash would compile this to:
if event("[some]"]) || event("[condition]") # if [some]
or [condition]
...
end
The 2nd line there `or [condition]` was intended to be on the line
above.
This change strips the line terminators \r and \n, just in case, and
provides a test case to cover.
I verified that this test case _fails_ without the config_ast.rb patch
and _succeeds_ with the patch.
Fixes#2850Fixes#3281
