Bi-directional communication using `request-crypto`

[kobelb]

request-crypto was written with the specific goal of allowing an untrusted user's browser to send data from the Kibana server to the centralized telemetry service and ensure that only the telemetry service can decrypt it.

Pulse, the next generation of telemetry, would like to allow the pulse service to send information to the Kibana server and ensure that the data came from the pulse service and can only be read by the Kibana server.

[Bamieh]

@kobelb I'd love to learn more about possible implementations we can have for this bi-directional communication.

I've played around with different methods to do the encryption before landing for the private/public keys, some might be valid for this use case.

I read on the telemetry slack channel that the security team might be willing to contribute in building this feature for pulse?

[kobelb]

/cc @epixa @afharo @elastic/kibana-security

[kobelb]

@kobelb I'd love to learn more about possible implementations we can have for this bi-directional communication.

The most simplistic implementation that I've thought of is distributing a public and private key to both the Kibana server and the Pulse service. This would allow both entities to be the sender and receiver. The biggest limitation that I see with this approach is that the data sent from Pulse to Kibana could be decrypted by every instance of Kibana. I don't like this proposal for that reason.

I've also thought about having the Kibana server generate a random symmetric encryption key itself, which could be sent to Pulse and then the response would be encrypted using this symmetric encryption key.

I'm sure there are other better options out there, any input at this point is welcome.

I read on the telemetry slack channel that the security team might be willing to contribute in building this feature for pulse?

As long as the timelines and priorities align, yup!

[legrego]

I've also thought about having the Kibana server generate a random symmetric encryption key itself, which could be sent to Pulse and then the response would be encrypted using this symmetric encryption key.

This was the approach I was considering as well. I started writing this up until I re-read your comment, and saw you had already said it 😄

[kobelb]

This was the approach I was considering as well. I started writing this up until I re-read your comment, and saw you had already said it 😄

The primarily complication that I see with this approach is high-availability deployments of Kibana, and this encryption key not being synchronized across instances.

[legrego]

The primarily complication that I see with this approach is high-availability deployments of Kibana, and this encryption key not being synchronized across instances.

That's a good point. We already have a sprawling list of keys which we ask users to keep in sync today. I wonder (without thinking too much into the how) if we could derive the key from the ES cluster_uuid. This would ensure that all Kibana instances connected to the same cluster would derive the same key

[afharo]

I mentioned some ideas in this comment to Pulse's RFC (elastic/kibana#57108 (comment)). I didn't realise we had this discussion going on in here :)

Basically it's about maintaining asymmetric encryptions on both ends. And yes, I also mentioned something about the scenario where we have multiple instances of Kibana connected to the same cluster (not to mention the additional use case where we have have a Kibana instance for a side-monitoring environment that is capable of pushing telemetry about other clusters it is collecting monitoring information about).

[legrego]

Based on the updated 2020 Kibana Vision, it's my understanding that we can be flexible in terms of when we add support for bi-directional communication. Given that, I am inclined to de-prioritize this on the Kibana Security team's roadmap so that we can focus on other initiatives that align with the vision.

Please let me know if this is not the case so that we can re-evaluate. We were originally slated to start on this in the 7.9 timeframe.