Re: [grpc-io] Any alternative to SetSslTargetNameOverride?
Robert Engels writes: > I’m not sure I follow. The client knows the host it is expecting to > contact and verified that the certificate sent matches that host. As I > said in a later email there is almost certainly a way to bypass the > check but not sure you can change the setting while going through gRPC > layer. There are two parameters here: the hostname or IP address to which to connect, and the FQDN used for SNI and for certificate verification. The request, at least if I understand it correctly, is to support decoupling them in the API so that the client can specify an IP address to connect to and separately specify the FQDN in SNI and certificate verification, because the client knows (via some mechanism outside the scope of the API) that it wants to connect to some specific IP that isn't associated in DNS with the FQDN, but knows what certificate identity to expect. This is a quite common problem with any software using SSL. There are often reasons why you want to connect to some internal IP that isn't in DNS or has the wrong DNS or whatever, but you know as the client what the certificate will and should be. -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> -- 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 grpc-io+unsubscr...@googlegroups.com. To post to this group, send email to grpc-io@googlegroups.com. 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/87pnv0ltx7.fsf%40hope.eyrie.org. For more options, visit https://groups.google.com/d/optout.
Re: [grpc-io] Any alternative to SetSslTargetNameOverride?
Robert Engels writes: > The certificate has the domain in it. So, think of the reverse. Someone > highjacks the domain and uses a bogus certificate (valid but not for the > real company) If the two weren’t linked there would be no way to stop > this (as the certificate is still valid) > By linking the certificate and the domain it is that much harder to > break - both need to be compromised. That's why the goal is to change the hostname used for SNI and certificate verification, not blindly trust any certificate the remote server presents. Explicitly setting the hostname used for SNI and certificate verification instead of implicitly using the hostname given to connect to should not create any new security problems, as long as the hostname passed in is the correct one (the calling application has to figure that out in some way outside the scope of the API). -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> -- 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 grpc-io+unsubscr...@googlegroups.com. To post to this group, send email to grpc-io@googlegroups.com. 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/87tvkcluaj.fsf%40hope.eyrie.org. For more options, visit https://groups.google.com/d/optout.
Re: [grpc-io] Re: Gathering statistics about TLS failure (Python)
"'Carl Mastrangelo' via grpc.io" <grpc-io@googlegroups.com> writes: > At least in the Java world, connections are treated as a queue of > handlers, with TLS near the network side. Any TLS failures are not > surfaced (or not easily anyways) since they never make it up to the gRPC > layer. Gather these stats server side would require some code changes. > I know you said you are using python, but I think every language would > be able to benefit from knowing about such failures. Yeah, agreed, it just so happens that my specific problem is with Python and Go. Go is relatively straightforward to implement without making changes to gRPC because (for various other reasons) we're already hooking into the TLS negotiation and that's exposed fairly well with a few strategic proxy objects. But the C/C++ native code is a bit less amenable to that. I assume client-side poses similar challenges? Or is it easier to hook into? -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> -- 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 grpc-io+unsubscr...@googlegroups.com. To post to this group, send email to grpc-io@googlegroups.com. 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/87sh6fkyi0.fsf%40hope.eyrie.org. For more options, visit https://groups.google.com/d/optout.
[grpc-io] Gathering statistics about TLS failure (Python)
Hi all, I want to gather statistics on how many failed TLS handshakes are happening across a large gRPC deployment. (The motivation is a long story, but basically I want to be able to trigger alerts if something goes wrong with the PKI that's generating the client and server certificates.) Just a count of failed TLS handshakes would be sufficient, although if I can get at more detailed errors, that might be helpful. I see how to do this in the Go gRPC code, but also need the same support for Python. I'd mildly prefer to capture this information on the server, although it may be adequate to capture it on the client if that's easier to do. (I only need either the server or the client, not both.) Could someone point me in the right direction? I can take a cut at implementing this as a general feature suitable for a pull request, but I'm not sure the best approach to use given the code structure. What I've been able to determine (I think) so far: * Actual success or failure of the TLS handshakes is determined (for both client and server) in src/core/tsi/ssl_transport_security.cc. * For the server, these errors pass up to on_handshake_done in src/core/ext/transport/chttp2/server/chttp2_server.cc, where they're logged and discarded and the channel is closed. This seems to be below the layer where the Python bindings have any visibility. (In other words, so far as I could determine, no Python code ever sees the error from an attempted connection that results in a failed TLS handshake.) * For the client, it looks like (?) these errors will trigger a notify closure in src/core/ext/transport/chttp2/client/chttp2_connector.cc in on_handshake_done, which in turn seems to be on_subchannel_connected in core/ext/filters/client_channel/subchannel.cc, but it looks like the exact contents of the error don't go any farther beyond that function. Therefore, unless I'm mistaken, it looks like these errors are swallowed inside the core code in places where I can't get visibility to them from Python, hiding entirely (except for a log message) in the server and turning into a generic connection state inside the client channels. So there seems to be some plumbing or a hook missing here to be able to bubble these failures up to a level where I can get at them and send them to monitoring code. -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> -- 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 grpc-io+unsubscr...@googlegroups.com. To post to this group, send email to grpc-io@googlegroups.com. 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/87in7cxy6z.fsf%40hope.eyrie.org. For more options, visit https://groups.google.com/d/optout.
