Modifying SSL settings to be consistent with the stack#9823
Modifying SSL settings to be consistent with the stack#9823kobelb merged 6 commits intoelastic:masterfrom
Conversation
jbudz
left a comment
There was a problem hiding this comment.
I tested all of the new configurations and they're functioning as expected. Deprecation warnings look good, including the more complicated ones like console.proxyConfig.
Lots of tests too, great work on this. A few comments below but otherwise this lgtm.
docs/setup/settings.asciidoc
Outdated
There was a problem hiding this comment.
thoughts on adding these to kibana.yml?
There was a problem hiding this comment.
Good question! It's my understanding that we only try to put the common settings in the kibana.yml, I feel like keyPassphrase is a contender to add in there, but I dunno how I feel about clientAuthentication and certiricateAuthorities because I don't see a majority of our users using these. What are your thoughts?
There was a problem hiding this comment.
makes sense, on second thought it's probably fine. consistent with the configs for our other products too.
src/core_plugins/console/index.js
Outdated
There was a problem hiding this comment.
can we remove this from the settings docs page and console page?
There was a problem hiding this comment.
Great call, I'll make it so.
docs/setup/settings.asciidoc
Outdated
There was a problem hiding this comment.
When using this I'm occasionally seeing
log [18:54:38.465] [error][client][connection] Error: TLS handshake timeout
at TLSSocket._handleTimeout (_tls_wrap.js:539:22)
at TLSSocket.g (events.js:291:16)
at emitNone (events.js:86:13)
at TLSSocket.emit (events.js:185:7)
at TLSSocket.Socket._onTimeout (net.js:339:8)
at ontimeout (timers.js:365:14)
at tryOnTimeout (timers.js:237:5)
at Timer.listOnTimeout (timers.js:207:5)
I'm not able to reproduce it consistently or often. Functionally it doesn't seem to have an impact, is this something we want in the error log?
There was a problem hiding this comment.
Lemme see if I can track down where this is coming from, and see if there's a way to at least downgrade it from error like we're doing elsewhere.
There was a problem hiding this comment.
I've been able to consistently get this log message to occur by setting server.ssl.clientAuthentication: required and then opening up Kibana and letting the browser sit on the prompt for me to select a certificate for a long-time. However, I'm sure that other situations could also cause this to occur as well.
This error is being emitted by the tls socket to the https Server to the hapi connection which we then intercept, and downgrade certain errors.
We've been downgrading errors based on their errno, but those only exist on System Errors, and these are just generic Errors.
We could potentially filter these out by matching the err.message of TLS handshake timeout, but that feels rather brittle. Additionally, there are various other generic client errors the underlying ssl library is throwing with uglier messages like the following:
4330128320:error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca:../deps/openssl/openssl/ssl/s3_pkt.c:1487:SSL alert number 48
4330128320:error:140940E5:SSL routines:ssl3_read_bytes:ssl handshake failure:../deps/openssl/openssl/ssl/s3_pkt.c:1210:
I'm beginning to wonder whether we should be downgrading all client errors to debug/info. What are your alls thoughts @spalger @tylersmalley @jbudz?
|
@jbudz caught that this PR does not currently allow the user to configure the list of cipher-suites. @epixa - in the chart in #7777 there's a note next to cipher-suites saying 'see list below' and 'language specific', do you happen to recall the original discussion surrounding this issue and whether it impacts how we implement this? @spalger do you happen to recall why we're customizing the current default list of cipher-suites and whether there is any reason why we wouldn't use the NodeJS default and then allow the user to overwrite this? |
config/kibana.yml
Outdated
There was a problem hiding this comment.
If we are seeking consistent configurations, why do we camel case our names when ES and others are all lowercase with underscore delimited words?
There was a problem hiding this comment.
Should use use the array for this to show multiple CA's can be provided?
elasticsearch.ssl.certificateAuthorities: [ "/path/to/your/CA.pem" ]
There was a problem hiding this comment.
we do have #7444. i was on the fence for this one, it is consistent with out current config
There was a problem hiding this comment.
Regarding camelCasing, I wanted to keep this consistent with the rest of our settings and then address converting all of them to snake_case in a separate PR. Should we consider trying to do both in the same minor version to reduce the impact on the user? I would prefer to at least do it in a separate PR, even if it's for the same minor version. What are your thoughts?
There was a problem hiding this comment.
I agree, let's keep it out of this PR and see if it's something we want to also get into 5.2 to reduce the number of times folks are re-doing their config.
docs/setup/settings.asciidoc
Outdated
There was a problem hiding this comment.
I am personally really excited about this as I had been previously needing to remove the passphrase from my generated certs.
There was a problem hiding this comment.
bindKey can actually be removed as it's not being used.
|
When testing the deprecation for pid_file, it appears were now handling the deprecation calls later in the startup processing than before. In this test, I have defined When testing for the same thing on master, I immediately get the deprecation warning without a file error. |
tylersmalley
left a comment
There was a problem hiding this comment.
A couple feedback items. Only one of concern is when the deprecations are ran.
|
@tylersmalley, after discussing with Spencer, we decided to move the deprecation logging to use the standard logger, which unfortunately delayed when these deprecations will be output because the logging is currently attached to the kibana server. It's a trade-off that at the time seemed reasonable, but I'm definitely open to alternatives. |
|
Yeah, there are only a couple settings that will trigger failures before the deprecation warning, and you found one of them, but I think it's better to use the standard logging format than fix the ordering for those edge cases. That said, if we can do the deprecation logging any earlier I think we should (it runs after http right now which seems unnecessary, but idk) |
|
@spalger good call on moving the deprecations to earlier in the kbn_server. The deprecations currently have to run after http and logging because the log function is exposed on the server, but I was able to put it before the warnings and status. |
|
LGTM! By moving the deprecations were now consistent with the behavior in master. |
|
@jbudz you mind giving the changes that I made a look over? |
Backports PR #9823 **Commit 1:** Modifying SSL settings to be consistent with the stack * Original sha: 6ea4077 * Authored by = <brandon.kobel@elastic.co> on 2016-10-07T10:19:45Z **Commit 2:** Removing deprecated console settings from the docs * Original sha: 9dc79fd * Authored by kobelb <brandon.kobel@elastic.co> on 2017-01-13T16:08:18Z **Commit 3:** Removing unused code * Original sha: 22713b7 * Authored by kobelb <brandon.kobel@elastic.co> on 2017-01-13T16:09:43Z **Commit 4:** Using array for certificateAuthorities in the kibana.yml * Original sha: a93c9fe * Authored by kobelb <brandon.kobel@elastic.co> on 2017-01-13T16:10:01Z **Commit 5:** Moving the kbn_server deprecation warnings to be earlier * Original sha: 9dba22a * Authored by kobelb <brandon.kobel@elastic.co> on 2017-01-20T12:30:51Z **Commit 6:** Allowing the cipher suites to be configured * Original sha: e224268 * Authored by kobelb <brandon.kobel@elastic.co> on 2017-01-20T19:00:40Z
Backports PR #9823 **Commit 1:** Modifying SSL settings to be consistent with the stack * Original sha: 6ea4077 * Authored by = <brandon.kobel@elastic.co> on 2016-10-07T10:19:45Z **Commit 2:** Removing deprecated console settings from the docs * Original sha: 9dc79fd * Authored by kobelb <brandon.kobel@elastic.co> on 2017-01-13T16:08:18Z **Commit 3:** Removing unused code * Original sha: 22713b7 * Authored by kobelb <brandon.kobel@elastic.co> on 2017-01-13T16:09:43Z **Commit 4:** Using array for certificateAuthorities in the kibana.yml * Original sha: a93c9fe * Authored by kobelb <brandon.kobel@elastic.co> on 2017-01-13T16:10:01Z **Commit 5:** Moving the kbn_server deprecation warnings to be earlier * Original sha: 9dba22a * Authored by kobelb <brandon.kobel@elastic.co> on 2017-01-20T12:30:51Z **Commit 6:** Allowing the cipher suites to be configured * Original sha: e224268 * Authored by kobelb <brandon.kobel@elastic.co> on 2017-01-20T19:00:40Z
|
If you need assistance generating certs with passphrases, this will help: https://gist.github.com/mtigas/952344 Certgen doesn't let you specify passphrases, but it's nice for the other test-cases |
|
To Test:
Tested on 5.3.0 -BC1 builds From dev ticket #725 |
|
To test the |
| and `none`. `required` forces a client to present a certificate, while `none` does not. | ||
| `server.ssl.supportedProtocols`:: *Default: TLSv1, TLSv1.1, TLSv1.2* Supported protocols with versions. Valid protocols: `TLSv1`, `TLSv1.1`, `TLSv1.2` | ||
| `server.ssl.cipherSuites`:: *Default: ECDHE-RSA-AES128-GCM-SHA256, ECDHE-ECDSA-AES128-GCM-SHA256, ECDHE-RSA-AES256-GCM-SHA384, ECDHE-ECDSA-AES256-GCM-SHA384, DHE-RSA-AES128-GCM-SHA256, ECDHE-RSA-AES128-SHA256, DHE-RSA-AES128-SHA256, ECDHE-RSA-AES256-SHA384, DHE-RSA-AES256-SHA384, ECDHE-RSA-AES256-SHA256, DHE-RSA-AES256-SHA256, HIGH,!aNULL, !eNULL, !EXPORT, !DES, !RC4, !MD5, !PSK, !SRP, !CAMELLIA*. Details on the format, and the valid options, are available via the [OpenSSL cipher list format documentation](https://www.openssl.org/docs/man1.0.2/apps/ciphers.html#CIPHER-LIST-FORMAT) | ||
| `elasticsearch.ssl.cert:` and `elasticsearch.ssl.key:`:: Optional settings that provide the paths to the PEM-format SSL |
There was a problem hiding this comment.
Is this a missed rename to elasticsearch.ssl.certificate?
There was a problem hiding this comment.
@Jarpy it is, I'll get a fix up there for this, thanks!


Per #7777 we want to move towards consistent SSL settings across the stack.
This introduces the following new settings:
and deprecates the following: