Support transformation functions on transported data

[Nhowka]

I'm tired of finding possible NullPointerException on the Java code reviews at my company. I want to show the joy of using a single language for front and backend, plus the magic of using Fable.Remoting to my team.

But we are in banking so it would be really cool if we could just add a function to encrypt the data before it goes to the server and another to decrypt it when the data arrives. On the server I can just use HttpHandlers composition to decrypt the request and then encrypt the response.

Would that feature be welcome on the library? I believe that enabling seamless encrypted transport would be the main usage, not sure if there would be another reason to modify the request before sending or the response before deserializing.

[saboco]

I'm sincerely curious: why HTTPS/TLS is not enough?

[Nhowka]

You can see the traffic on the developer tools on the navigator, so it's a point of attack if you borrow a device to check your balance. Having an end-to-end encryption helps on that case, if it is encrypted before sending, your password won't be in plaintext there.

[Zaid-Ajaj]

Hi there @Nhowka I certainly like the idea and I think it would be doable (not sure about the API yet) but it seems to me that you already have a solution to make this work as is:

On the server I can just use HttpHandlers composition to decrypt the request and then encrypt the response.

I tend to say if this is something that is already doable using a workaround like the above, then we wouldn't add it to the library because of the extra complexity, more public API functions and more maintenance.

Does it have that much of an added value to make it builtin as opposed to using the HTTP handlers?

decrypt >=> remotingWebPart >=> encrypt

[Nhowka]

I believed that no, I said that mostly to not worry about the server part and I wasn't thinking of that. It's just the client that I couldn't find a workaround to do the same.

But now I'm not sure if it would be a good idea to make the feature client only as it really would be easier to use if it had support on both ends. Intercepting the response to encrypt before sending to the client involves some work that is not really straightforward.

[Zaid-Ajaj]

Hmm implementing this on the browser client sounds very challenging 🤔 I am not a security expert but doesn't decryption on the browser means that secret keys are deployed on the users machine as well? or maybe you are thinking of a mobile app client side (since you used to work with Flutter)?

In case of a mobile client whether that is Xamarin or Fabulous it might be doable because you can provide a custom HttpMessageHandler for your HttpClient that handles/intercepts requests and responses and in turn use that HttpClient when constructing the remoting proxy. Implementing this on the dotnet client is a matter of exposing an implementation of HttpMessageHandler from Fable.Remoting.DotnetClient that users of the package can plug into the remoting API options.

Again, this is in case you are talking about mobile/desktop apps

[Nhowka]

I was thinking in using it in the browser. We use a Diffie-Hellman key agreement to generate a AES key valid only for one session, so no need to deploy keys. Every session uses a different agreed key.

So I was thinking in simple RequestBody -> RequestBody function for encrypting the body and maybe string -> string for decrypting the json and byte[] -> byte[] for decrypting the binary case. Maybe just the byte[] -> byte[] could be enough to transform the body before being interpreted also as a string.

[Zaid-Ajaj]

I was thinking in using it in the browser. We use a Diffie-Hellman key agreement to generate a AES key valid only for one session, so no need to deploy keys. Every session uses a different agreed key.

Are you thinking of having the library handle this exchange?

So I was thinking in simple RequestBody -> RequestBody function for encrypting the body and maybe string -> string for decrypting the json and byte[] -> byte[] for decrypting the binary case. Maybe just the byte[] -> byte[] could be enough to transform the body before being interpreted also as a string.

Providing two functions for mapping byte[] and string should be really easy where the default function is the identity. Then have those functions apply when the preparing server-side requests or receiving responses

[Nhowka]

Are you thinking of having the library handle this exchange?

In that case, no. My idea would be doing that before creating the proxy, as I'd also need to use an extra header to signal the server which key agreement to use. Then I'd calculate the shared key and capture the key into a closure inside those functions to create the encrypt/decrypt flow.

I believe that just having those simple mappings where id fits would be enough to implement the feature on my use case. Having a specialized cryptographic flow would be too much to ask and probably it wouldn't be a good fit for every case.

[Zaid-Ajaj]

I believe that just having those simple mappings where id fits would be enough to implement the feature on my use case.

Is this still someone you want to implement? Please feel free to do so! As long as the API is explicit about what it does, then it should be fine