Verify client certificates against CA #8
Comments
|
+1 |
|
indeed, stumbled over this too. In Filebeat you can set the accepted CAs and cipher suites. |
|
+1 |
|
This seems to be an important issue, if you want to drop lumberjack in the future you should at least have the same kind of security with beats. Funny enough filebeat already supports using a client certificate. Logstash filebeat input just fails to validate it. Please add this option: |
|
@runningman84 I don't think the lumberjack input does validation (on the logstash input side) of client certificates - the original threat model was to protect data leaks (so lsf doesn't ship to untrusted servers). There's been enough requests for client authentication via certificate that it's worth adding this feature, so I agree. Hope the background helps. |
|
+1 on implementing this, /cc @suyograo |
|
+1 For me this is a major security fault and should be implemented as soon as possible |
|
+1 . We are planning a large-scale install of filebeat on 1000+ machines hence this is a critical feature. |
|
I am starting to look at this following the use cases defined in logstash-plugins/logstash-input-lumberjack#31 |
|
+1 |
|
Thanks for the feedback, we're targeting this within a short-term release. |
|
When this gets implemented, can we please have access to information about the client certificate? I want to be able to trace an event to what client certificate was used to send it to Logstash. |
The event already contains the information about the shippe (which should be similar from the certificate)? Is that enough? What is your use case here? |
I need attribution of events to shippers to be absolute under the assumption of a malicious or compromised shipper that wants to impersonate other shippers (whether valid or invalid). Hence, ideally, a logstash rule that puts information about the verified client ceritificate into the event instead of trusting origin information put into the event itself by the shipper. |
This PR introduce client verification when using `ssl`, when using this option you need to specify the **Certificate Authority** using the `ssl_certificate_authorities` option, this configuration take a certificate to validate the client with it. You also need to specify a `ssl_verify_mode`, If you want strict ssl verification use `force_peer`, with this value if the client doesn't provide a valid certificate the plugins will refuse the client. On Filebeat you need to configure the client to declare a certificate using theses options. ``` tls: certificate_authorities: ["/etc/server.crt"] certificate: /etc/server.crt certificate_key: /etc/server.key ``` This change also introduce testing with travis-ci and an integration suite with filebeat and LSF for the SSL options. Fix: logstash-plugins#8
|
When implementing this I have encountered a Jruby/OpenSSL bug thats blocking me and that prevent the server to use intermediate ca. I have created an issue on Jruby-OpenSSL to track this jruby/jruby-openssl#84 #56 is incomplete because of that, it will only work if the CA sign the client certificate directly which is problematic when you want to isolate CA. |
|
I would like to have your feedback here concerning the usage of this feature, The PR #56 implement and currently work when you have a Is this an acceptable solution for you? I don't have a workaround until the jruby-openssl bug is fixed |
This PR introduce client verification when using `ssl`, when using this option you need to specify the **Certificate Authority** using the `ssl_certificate_authorities` option, this configuration take a certificate to validate the client with it. You also need to specify a `ssl_verify_mode`, If you want strict ssl verification use `force_peer`, with this value if the client doesn't provide a valid certificate the plugins will refuse the client. On Filebeat you need to configure the client to declare a certificate using theses options. ``` tls: certificate_authorities: ["/etc/server.crt"] certificate: /etc/server.crt certificate_key: /etc/server.key ``` This change also introduce testing with travis-ci and an integration suite with filebeat and LSF for the SSL options. Fix: logstash-plugins#8
This PR introduce client verification when using `ssl`, when using this
option you need to specify the **Certificate Authority** using the
`ssl_certificate_authorities` option, this configuration take a
CA to validate the client with it.
You also need to specify a `ssl_verify_mode`, If you want strict
ssl verification use `force_peer`, with this value if the client doesn't
provide a valid certificate the plugins will refuse the client.
On Filebeat you need to configure the client to declare a certificate using
theses options.
```
tls:
certificate_authorities: ["/etc/ca.crt"]
certificate: "/etc/client.crt"
certificate_key: "/etc/client.key"
```
```
input {
beats {
ssl => true
ssl_certificate_authorities => ["/etc/ca.crt"]
ssl_certificate => "/etc/server.crt"
ssl_key => "/etc/server.key"
ssl_verify_mode => "force_peer
}
}
```
This change also introduce testing with travis-ci and an integration
suite with filebeat for the SSL newer options.
Fix: logstash-plugins#8
|
any workaround for the fact that you can't use client certs signed by a root + intermediary? looks like jruby/jruby-openssl#84 has been open for over a year now... |
Currently, the beats input does not verify the client certificate against the CA. This means that any client can connect to any logstash server and submit arbitrary data. Besides cluttering the logstash server with meaningless data, attackers could try to take servers down by submitting huge amounts of data.
Analogous to filebeat/logstash-forwarder, the client certificate should be checked against the CA on the server side.
See also logstash-plugins/logstash-input-lumberjack#31.
The text was updated successfully, but these errors were encountered: