Responses inline: On Wednesday, December 6, 2017 at 7:28:05 AM UTC-8, [email protected] 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. > > Thanks! > > On Tuesday, December 5, 2017 at 7:02:08 PM UTC-5, Carl Mastrangelo wrote: >> >> 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. >> >> On Monday, December 4, 2017 at 10:03:19 AM UTC-8, [email protected] wrote: >>> >>> 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! >>> >> -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/grpc-io. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/0ba7511d-5cfe-4173-b6db-6335cd1735d9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
