Custom Transport Security

[aaj...@gmail.com]

Is there a way to set custom transport security other than SSL?

I saw this post https://github.com/grpc/grpc/issues/9985 but it wasn't particularly helpful.

I have browsed through the source of gRPC a bit and see what appears to be a generic handshake mechanism that looks promising but it would take a while to comprehend. If I wanted to use something other than SSL for encryption (e.g. a key exchange algorithm) how would I go about doing it? Follow up question, can a custom handshake implementation be used with the C++ abstractions?

Thanks!

[Carl Mastrangelo]

It is technically possible, but not part of gRPC API guarantees at the moment.  If you did implement your own security, you would need to make sure it stays up to date with the internal gRPC APIs.

One alternative you could do is run a local proxy, which accepts plaintext grpc in and uses security going one.  Then you could use gRPC to connect to the encrypting proxy without depending on the internals API.

[aaj...@gmail.com]

Ya I was looking through the C core a bit last night and following through how SSL works. It definitely looks possible.

That seems reasonable, are there any future plans to make such an API stable? 

Follow up question, can you have security (encryption/decryption) enabled/disabled at the RPC level? It appears the entire channel is encrypted. I see you can have per RPC credentials but as far as I can tell that is per RPC authentication not encryption/decryption (unless I'm missing something).

The use cases I'm considering are:
1. Large binary data that we might not want to encrypt but all other RPC calls we would want to

2. Data that is already encrypted and being proxied through a gRPC server

Thanks!

[Carl Mastrangelo]

Responses inline:

On Wednesday, December 6, 2017 at 7:28:05 AM UTC-8, aaj...@gmail.com wrote:

Ya I was looking through the C core a bit last night and following through how SSL works. It definitely looks possible.

That seems reasonable, are there any future plans to make such an API stable? 

Probably not until later, when people want to implement their own transports.   Right now we only have internal ones, so there hasn't been much time put into API stability of that code.  

 

Follow up question, can you have security (encryption/decryption) enabled/disabled at the RPC level? It appears the entire channel is encrypted. I see you can have per RPC credentials but as far as I can tell that is per RPC authentication not encryption/decryption (unless I'm missing something).

I don't think so.  The recommended way to do something like that would be to have two channels that point to the same target with one of them being encypted.  

 

The use cases I'm considering are:
1. Large binary data that we might not want to encrypt but all other RPC calls we would want to

2. Data that is already encrypted and being proxied through a gRPC server

A few things:  

- You may want a compromise such as integrity checksums, but not actual encryption.  This makes it possible to still be confident no one interfered with traffic, but its okay if they look.  In addition to this, you can encrypt your auth tokens cheaply so it doesn't have high cost.

- If the data is already encrypted you can use plaintext mode.   

That said, I think multiple transports with different levels of security would be a better fit.