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
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
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
remove unused load path
use either local core lib dir or logstash-core gem
include spec in logstash-core
do not include lib, spec and locales dirs in package root
environment bootstrapping in lib/bootstrap.rb
added comments
move pluginmanager out of logstash-core
kafla installation solved by pluginmanager refactor
refactor bootstrap code
refactor shell scripts to simplify and DRY, indirect rspec command to our ruby launcher
add bin/rspec
cut by half the bin/plugin and bin/rspec startup time
fix drip context
use printf instead of tr
updated Windows bin scripts
missing gemspec in gemspec
use gem instead of gemspec so our plugin manager can correctly install logstash-core
generate packages including locally built logstash-core gem
move jenkins developmnent dependencies into Gemfile, they do not belong in logstash-core
path leftover
clean help agent help usage message and remore rspec in available command
comments cosmetics
update Bundler dependency, all recent testing have been made with 1.9.4
updated .lock file with regard to updated Gemfile
cleanup gemspec, Gemfile and regen .lock file
added progress output
avoid dual require on version
closes#3096
