Encrypt data sent between agent and socket

[nijikokun]

Should the provider allow things such as passwords, keys, and other sensitive information pass through (even IP addresses) we should encrypt the connection / data sent.

Related to #3

[ahmadnassri]

:+1:

[kennethklee]

Good call. We can setup some sort of TLS on socket.io

[SGrondin]

I'll try to do this.

[ahmadnassri]

• [ ] use SSL on all connections by default
• [ ] provide a method for encrypting certain headers, query and body values.
• [ ] provide a method for excluding certain headers, query and body values.

[SGrondin]

I disagree with this ^

The data should simply be sent over an encrypted channel. If they don't want certain fields to be written to disk in the cloud we should offer a configuration in the app or in agents to automatically delete those fields or replace every character with zeroes so it doesn't affect the size reported in Analytics. Thoughts?

[ahmadnassri]

which exactly do you disagree with? seems like you're talking about the encryption one, but the others?

[ahmadnassri]

as for encrypting certain attributes, it should be a one-way encryption, the utility here is the usage of logs to track data for auditing purposes and future lookups, regardless of the "analytic" function.

users would want to analytize user info (filters on reports) securely, without exposing that to a third party system. encrypting those values is one sure way to do that.

[SGrondin]

I'm not sure I see the value in encrypting it. So you're saying we could encrypt it in the agents with a key they provide us so they can reverse later if needed?

[ahmadnassri]

no, we should never decrypt (or know about it)

i'm saying a user should be able to pass an encrypt/pre-process function that can manipulate the data (encrypting it or augmenting it as needed) before sending it in. the server would never know about the encryption (if any) and treats everything equally.

[SGrondin]

Btw are we still planning on doing the centralized agent/proxy settings in the app that those agents/proxies would pull on startup?

[ahmadnassri]

Btw are we still planning on doing the centralized agent/proxy settings in the app that those agents/proxies would pull on startup?

yes, will use the node agent as the experimentation grounds

[kennethklee]

Can we NOT let users provide their own encryption?

For communication from agent to socket, SSL is a great idea. Any more encryption wouldn't add to making it more secure. Like how Digest and NTLM encryption doesn't really do anything for encrypting HTTP.

[ahmadnassri]

users have the ability to send data directly through the API, there is no controlling or limiting what they do and do not encrypt ... the agents (as drop in tools they are meant to be) should at the very least allow a pre-processing step that the user can do whatever they want with the ALF object before sending ...

whether that be filtering, blocking or encrypting data ... it is up to the user.

[kennethklee]

i don't agree. there shouldn't be direct preprocessing over the ALF object. perhaps allow censoring of specified fields. But direct transformation of the ALF? that sounds like we'll need to validate the ALF before we send it.

[ahmadnassri]

yes, validation before sending will need to be done.

[ahmadnassri]

i don't agree. there shouldn't be direct preprocessing over the ALF object.

this only would potentially work because we control the code here, but it is also open-source, so people can fork and run their own custom functions anyways, also, in the direct to API method, how can you enforce that?

[ahmadnassri]

discussion was dropped, need to revist