Any alternative to SetSslTargetNameOverride?

[solomon lifshits]

Since the function SetSslTargetNameOverride is marked as test only, I am asking whether there is any "legal" alternative to connect to  a server with specific IP address, while using a host name for server name indication? Any possibility for forced resolution of a hostname? If a tls certificate is issued for a hostname, but an rpc call has to be done on specific machine? Any ideas? Thanks in advance!

[Robert Engels]

I’m pretty sure what you are asking breaks the security of using SSL... the certificates are issued to a domain for that reason, otherwise any valid certificate would be acceptable to the caller. 

On Nov 19, 2018, at 12:33 PM, solomon lifshits <solom...@gmail.com> wrote:

Since the function SetSslTargetNameOverride is marked as test only, I am asking whether there is any "legal" alternative to connect to  a server with specific IP address, while using a host name for server name indication? Any possibility for forced resolution of a hostname? If a tls certificate is issued for a hostname, but an rpc call has to be done on specific machine? Any ideas? Thanks in advance!

--
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+u...@googlegroups.com.
To post to this group, send email to grp...@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/c5c3c642-1317-41fe-afd4-d7ff8c117585%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[solomon lifshits]

Thank you for reply. The only thing I am trying to "bypass" is the DNS resolution, so could you please elaborate how DNS resolution contributes to SSL security? 

[Robert Engels]

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. 

To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/14e8e820-3e37-471c-95f8-de2027ae3ef8%40googlegroups.com.

[Robert Engels]

Also, when this happens in a browser there will be security warnings, but the user can still bypass it. With automated systems this is harder to do, there may be an option with the underlying SSL provider on the platform being used to perform a similar bypass (since the browser can bypass it and they almost always use the same subsystems)

To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/251287BC-A2B9-44B7-834C-85BA4EFB7D94%40earthlink.net.

[Russ Allbery]

Robert Engels <ren...@earthlink.net> 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/>

[Robert Engels]

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.

[Russ Allbery]

Robert Engels <ren...@earthlink.net> 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.

[Robert Engels]

Here is how to do it with Go

https://stackoverflow.com/questions/44295820/disable-common-name-validation-go-http-client

[solomon lifshits]

You got totally right what I was asking about, the question is whether there is any plan to make that support on grpc/c++ legit, rather than test only. 

[Robert Engels]

I don’t know the C++ gRPC api but would assume there is a method to configure and control the SSL transport layer. Almost have to be otherwise you need to duplicate the entire SSL api. 

--

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+u...@googlegroups.com.
To post to this group, send email to grp...@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/d453f639-f617-495f-b1ff-4f0028ab2120%40googlegroups.com.

[jian...@google.com]

If you do not want to use SslTargetNameOverride, the other alternative is using SPIFFE credential in gRPC. This work is coming soon (estimate by the end of this year).

https://github.com/grpc/proposal/pull/98

https://github.com/grpc/grpc/pull/16614#pullrequestreview-179042959

In SPIFFE credential for gRPC, we will not verify hostname, instead, there is server authorization callback, where gRPC core will provide the peer identity and peer certificate chain, it is up to the caller's authorization policy to decide whether to accept server's credential. Mapping to your use case, you just need to check hostname in the server's certificate in the callback. We envision that SPIFFE credential rather than current SSL credential will be used for service-to-service communication.