plugins https/ssl options inconsistencies

[colinsurprenant]

We should probably look into using a standard config option for using the https/ssl protocol. I did a little survey and this is what we currently use:

• *_protocol => ['http', 'https’] - logstash-output-elasticsearch-ec2
• ssl => boolean - logstash-output-elasticsearch
• ssl => boolean - logstash-input-rabbitmq
• proto => ['http', 'https’] - logstash-output-loggly
• ssl_enable = > boolean - logstash-input-tcp
• ssl => boolean - logstash-output-redmine
• enable_ssl => boolean - logstash-output-riak

I suggest we standardize on ssl:

config :ssl, :validate => :boolean

[jordansissel]

I wonder if we shouldn't rename it to tls ? (since SSL <= 3.0 is deprecated)

[jordansissel]

Or for technologies not using TLS, can we call it secure more generally?

[colinsurprenant]

good point.

[colinsurprenant]

I think I like secure since, as you say, it can also include non TLS/SSL use cases...

[jordansissel]

Thinking out loud -

Since secure is the intent, but the specific meaning will vary from plugin to plugin, it may be worth requiring each plugin's secure setting to document exactly what technology is used and what functionality is provided (trust, authentication, encryption, etc). This seems doable given we'll have to go through each plugin to add this setting anyway.

I'd also like to see, long term, unified security settings for credentials (user/pass, certificates) and trusts (IP lists, certs, etc), but that's outside the scope of this ticket.

[jsvd]

If ssl becomes the norm, then we need to change:

*_protocol => ['http', 'https’] - logstash-output-elasticsearch-ec2
proto => ['http', 'https’] - logstash-output-loggly
ssl_enable = > boolean - logstash-input-tcp
enable_ssl => boolean - logstash-output-riak

[jordansissel]

+1 on secure w/ documenting exactly what security technology is used and functionality provided.

[purbon]

like the @jordansissel option, but we should have a clear note on the tech used for that, cause secure is so vague.

[suyograo]

I like secure too.

[jordansissel]

Here's my full proposal for unification of the secure boolean setting. All of the following:

• use secure for enabling any security-related features if security is something toggleable for an input/output
• add backwards-compatibility to have ssl => true (or whatever the current setting is) to imply secure => true AND mark the old setting :deprecated => "Use 'secure => true'"
• document precisely which technology and function is enabled when secure is true
• if additional input is required (credentials, etc), further validation must be added if secure is true.
• add tests to verify that missing credentials/etc will cause config failures if secure => true

[colinsurprenant]

👍