Access to TLS client certificate

[tv42]

I can't see any way for an RPC method to authenticate a client based on a TLS certificate.

An example program where an RPC method echoes the client TLS certificate would be great.

[tv42]

Don't know how well this aligns with your plans, but adding a Conn() net.Conn method to ServerTransport, with a trivial implementation in http2Server, is enough to do this, and also provides RemoteAddr etc.

[iamqizhao]

I would suggest adding a read-only accessor (e.g., Conn()) to
credentials.TransportAuthenticator instead.

On Tue, Mar 10, 2015 at 1:24 PM, Tv notifications@github.com wrote:

Don't know how well this aligns with your plans, but adding a Conn()
net.Conn method to ServerTransport, with a trivial implementation in
http2Server, is enough to do this, and also provides RemoteAddr etc.

—
Reply to this email directly or view it on GitHub
#111 (comment).

[iamqizhao]

Probably

credentials.TransportAuthenticator.ConnectionState() returns a struct similar to http://golang.org/pkg/crypto/tls/#ConnectionState.

[tv42]

I don't see credentials.TransportAuthenticator interacting with the server side at all. At most it's used to wrap a net.Listener (with no place to stash extra data). The plan for its future is unclear. Is there something planned that is just not implemented yet?

I agree that exposing net.Conn feels dirty, but the alternative is a lot of case-by-case things (TLS ConnectionState! RemoteAddr! Client public key for a non-TLS protocol!). Needing to support every underlying transport explicitly sounds wrong.

Perhaps the really modular way is something like func (s *Server) ServeConn(ctx context.Context, conn net.Conn) error, that lets the caller pass whatever is needed in the context. This would do what one iteration of the Serve for { Accept() } loop does now.

If pb.RegisterXxxServer was done differently, I'd be happy creating the struct that's the receiver of all the RPC methods separately for every connection, instead of sharing the same value for all connections, and storing any state I want in there -- but it seems like Context is more where the world is heading. In my own explorations of RPC in http://godoc.org/github.com/tv42/birpc , imitating net/rpc, I separated Registry from Codec to make that nicer -- though I ended up implementing an API I don't personally like anymore, filling method arguments based on type with reflect.

[iamqizhao]

On Tue, Mar 10, 2015 at 4:20 PM, Tv notifications@github.com wrote:

I don't see credentials.TransportAuthenticator interacting with the
server side at all. At most it's used to wrap a net.Listener (with no
place to stash extra data). The plan for its future is unclear. Is there
something planned that is just not implemented yet?

https://github.com/grpc/grpc-go/blob/master/interop/server/server.go#L201

I agree that exposing net.Conn feels dirty, but the alternative is a lot
of case-by-case things (TLS ConnectionState! RemoteAddr! Client public key
for a non-TLS protocol!). Needing to support every underlying transport
explicitly sounds wrong.

I said something similar to tls.ConnectionState instead of a copy of it.
Plus, most of members are pretty common for various transport level
security protocols.

Perhaps the really modular way is something like func (s *Server)
ServeConn(ctx context.Context) error, that lets the caller pass whatever
is needed in the context. This would do what one iteration of the Serve for
{ Accept() } loop does now.

If pb.RegisterXxxServer was done differently, I'd be happy creating the
struct that's the receiver of all the RPC methods separately for every
connection, instead of sharing the same value for all connections, and
storing any state I want in there -- but it seems like Context is more
where the world is heading. In my own explorations of RPC in
http://godoc.org/github.com/tv42/birpc , imitating net/rpc, I separated
Registry from Codec to make that nicer -- though I ended up implementing an
API I don't personally like anymore, filling method arguments based on type
with reflect.

—
Reply to this email directly or view it on GitHub
#111 (comment).

[tv42]

I still don't see how you want the RPC method to actually access the ConnectionState. RPC methods don't get passed the TransportAuthenticator. TransportAuthenticator is also not a per-connection value, so I don't see how adding methods to that is helpful -- except if they also take either net.Conn or Context as an argument.

If you're still talking about exposing net.Conn, then I personally don't even need anything more from TransportAuthenticator, I can hardcode my app to type assert to *tls.Conn etc.

If you're talking about passing Context to a TransportAuthenticator method to look up some sort of client credentials, then where does the TransportAuthenticator implementation get to do context.WithValue? Also, at that point, it might as well be a standalone function -- I'm not at all convinced the client credentials are all the same type, so the calling code already needs to know what it's asking for, and then can call therightpkg.AuthFromContext(ctx).

I'm really keen to know if you have a plan for all this, e.g. based on some Google internal service or Java code, that's just slowly getting written in Go..

[iamqizhao]

Hi Tv,

I think there was a miscommunication in the beginning. To clarify, your
intention is to let users be able to extract the security info (e.g.,
client auth cert) for each incoming RPC on the server? If it is the case,
this is a generic question for gRPC. Do you have a real use case for this
requirement? Inside google, we do need to export some security info per RPC
to users but this part has not been fleshed out.

On Tue, Mar 10, 2015 at 4:43 PM, Tv notifications@github.com wrote:

I still don't see how you want the RPC method to actually access the
ConnectionState. RPC methods don't get passed the TransportAuthenticator.
TransportAuthenticator is also not a per-connection value, so I don't see
how adding methods to that is helpful -- except if they also take either
net.Conn or Context as an argument.

If you're still talking about exposing net.Conn, then I personally don't
even need anything more from TransportAuthenticator, I can hardcode my
app to type assert to *tls.Conn etc.

If you're talking about passing Context to a TransportAuthenticator
method to look up some sort of client credentials, then where does the
TransportAuthenticator implementation get to do context.WithValue? Also,
at that point, it might as well be a standalone function -- I'm not at all
convinced the client credentials are all the same type, so the calling code
already needs to know what it's asking for, and then can call
therightpkg.AuthFromContext(ctx).

I'm really keen to know if you have a plan for all this, e.g. based on
some Google internal service or Java code, that's just slowly getting
written in Go..

—
Reply to this email directly or view it on GitHub
#111 (comment).

[tv42]

My use case is this: I'm porting a peer-to-peer communication protocol to gRPC.

An ealier version did it by streaming protobufs both ways over a HTTP POST, with the URL path deciding which "method" to call. From that perspective, gRPC sounds pretty familiar, right? To me, gRPC seemed like a good way to avoid boilerplate or writing my own custom framework.

I identify which peer I'm talking to by the client certificate (and respectively, the peer verifies the server identity with the server cert). The RPC methods naturally need to know which exact peer is calling them.

[tv42]

And just to state this explicitly one more time, my current needs would be 100% covered with either of these:

1. func (s *Server) ServeConn(ctx context.Context, conn net.Conn) error, with a context derived from that being passed to the RPC method, would let me pass in whatever I need. I'd just do my own for-accept loop, and prepare a context with the information I'll need later.
2. a Conn() net.Conn method in ServerTransport and http2Server would let me dig out what I need.

Of these, 1. seems prettier to me.

(I typoed option 1. earlier and left out the net.Conn, sorry about that; updated the comment above.)

[tv42]

Example use of ServeConn:

for {
    c, err := l.Accept()
    if err != nil { ... }
    ctx := context.WithValue(context.Background(), myKey, metadata(c))
    go srv.ServeConn(ctx, c)
}

[acasajus]

The default approach to this would be to be able to define a set of handlers execute before the actual RPC request that can modify the context to add whatever info we need. It would be nice to have a set of handlers for the connection and another for each stream.

In the set of handlers that execute when a new connection is received we could do authentication and stuff like that.
And in the set of handlers that execute when a new stream is created we could do authorization.

1. Accept new connection
2. Execute handlers for new connection. We can do authentication here. If the client is not valid just close the connection or something.
3. Wait for streams
4. For each new stream execute handlers. We can do authorization here. If the client is not allowed to execute whatever he wants to do, close the connection or something
5. Execute whatever RPC method

Maybe the stream handlers can be defined in the service?

[tv42]

@acasajus For 2., the authentication also needs to pass information to the RPC method, e.g. who the current user is. Making the function both take and return a Context would be enough.

[acasajus]

@tv42 agreed 👍

[GeertJohan]

This sounds pretty handy.
There is some overlap with the DialOptions and Credentials way of handling auth, I wonder how this will fit between those.

[acasajus]

For handlers per connection there's no service yet defined so somehow we'd need to add some info to the context so the handler can check if the authentication credentials are valid.