-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
encryption? #47
Comments
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
<#47 (comment)>,
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. |
Would it be not possible to use SslStream to add encryption over named pipe streams ? |
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.
The text was updated successfully, but these errors were encountered: