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.
> On Nov 19, 2018, at 1:52 PM, Russ Allbery <[email protected]> wrote: > > Robert Engels <[email protected]> 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 ([email protected]) <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 [email protected]. To post to this group, send email to [email protected]. 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/E7B08276-8CB4-4B19-864A-AA3283DCAD3D%40earthlink.net. For more options, visit https://groups.google.com/d/optout.
