Open zachrybaker opened 1 year ago
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.
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.