grpc-dotnet-namedpipes
grpc-dotnet-namedpipes copied to clipboard
cyanfish
encryption?
I'm seeing no mention of encryption.
Granted, there's a discussion that we could have as to why Microsoft chose not to secure the transport of a pipe.
But it would be great if this package added (optionally) transport security.
You can set access controls (e.g. CurrentUserOnly). Aside from that I'm not sure there's a ton of point to encrypting a connection that doesn't go over the network. And as far as I know it's not possible to sniff a named pipe connection from a process that's not the server/client.
Sounds like you assume that it is a local pipe, but remote pipes are a thing.
On Tue, Aug 29, 2023 at 1:34 PM Ben Olden-Cooligan @.***> wrote:
You can set access controls (e.g. CurrentUserOnly https://github.com/cyanfish/grpc-dotnet-namedpipes/blob/e292e4c6d36c00321f4c60a8435d891999fe47e0/GrpcDotNetNamedPipes/NamedPipeServerOptions.cs#L26). Aside from that I'm not sure there's a ton of point to encrypting a connection that doesn't go over the network. As as far as I know it's not possible to sniff a named pipe connection from a process that's not the server/client.
— Reply to this email directly, view it on GitHub https://github.com/cyanfish/grpc-dotnet-namedpipes/issues/47#issuecomment-1697942141, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACDSMVIEXB77X3T2TYG65TXXYY2FANCNFSM6AAAAAA4DJZZQU . You are receiving this because you authored the thread.Message ID: @.***>
That's fair, I was assuming in that case you'd just use normal gRPC, but pipes do give you ACLs and impersonation.
With the way this project works adding encryption isn't a simple thing. You might try the .NET 8 implementation of gRPC named pipes, which uses HTTP as the underlying transport, so in theory should be possible to set up TLS for.
