Re: [grpc-io] Any alternative to SetSslTargetNameOverride?

[jiangtao via grpc.io]

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.


On Monday, November 19, 2018 at 12:57:19 PM UTC-8, Robert Engels wrote:
>
> 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. 
>
> On Nov 19, 2018, at 2:55 PM, solomon lifshits  > wrote:
>
> 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. 
>
> On Monday, November 19, 2018 at 3:00:07 PM UTC-5, eagle wrote:
>>
>> 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)   
>>
>>
> -- 
> 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
>  
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
>

-- 
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/ee06d3f2-2810-4da5-a14d-78a6c42df375%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] Any alternative to SetSslTargetNameOverride?

[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. 

> On Nov 19, 2018, at 2:55 PM, solomon lifshits  wrote:
> 
> 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. 
> 
>> On Monday, November 19, 2018 at 3:00:07 PM UTC-5, eagle wrote:
>> 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)   
> 
> -- 
> 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/d453f639-f617-495f-b1ff-4f0028ab2120%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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/20FD2894-B080-48DC-BB59-78E308715470%40earthlink.net.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] Any alternative to SetSslTargetNameOverride?

[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. 

On Monday, November 19, 2018 at 3:00:07 PM UTC-5, eagle wrote:
>
> 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/d453f639-f617-495f-b1ff-4f0028ab2120%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] Any alternative to SetSslTargetNameOverride?

[Robert Engels]

Here is how to do it with Go

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

> On Nov 19, 2018, at 2:00 PM, Russ Allbery  wrote:
> 
> 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)  

-- 
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/560BAAF8-F612-4822-98FC-B0F1F4F20CF0%40earthlink.net.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] Any alternative to SetSslTargetNameOverride?

[Russ Allbery]

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)  

-- 
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]

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  wrote:
> 
> 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)  

-- 
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/E7B08276-8CB4-4B19-864A-AA3283DCAD3D%40earthlink.net.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] Any alternative to SetSslTargetNameOverride?

[Russ Allbery]

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)  

-- 
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] Any alternative to SetSslTargetNameOverride?

[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)

> On Nov 19, 2018, at 1:47 PM, Robert Engels  wrote:
> 
> 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. 
> 
>> On Nov 19, 2018, at 1:42 PM, solomon lifshits  wrote:
>> 
>> 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? 
>> 
>>> On Monday, November 19, 2018 at 2:06:31 PM UTC-5, Robert Engels wrote:
>>> 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  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.
>> 
>> -- 
>> 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/14e8e820-3e37-471c-95f8-de2027ae3ef8%40googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
> -- 
> 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/251287BC-A2B9-44B7-834C-85BA4EFB7D94%40earthlink.net.
> For more options, visit https://groups.google.com/d/optout.

-- 
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/149D6A0C-CD3A-424B-8DCA-F85C276F1EB6%40earthlink.net.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] Any alternative to SetSslTargetNameOverride?

[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. 

> On Nov 19, 2018, at 1:42 PM, solomon lifshits  wrote:
> 
> 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? 
> 
>> On Monday, November 19, 2018 at 2:06:31 PM UTC-5, Robert Engels wrote:
>> 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  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.
> 
> -- 
> 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/14e8e820-3e37-471c-95f8-de2027ae3ef8%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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/251287BC-A2B9-44B7-834C-85BA4EFB7D94%40earthlink.net.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] Any alternative to SetSslTargetNameOverride?

[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? 

On Monday, November 19, 2018 at 2:06:31 PM UTC-5, Robert Engels wrote:
>
> 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  > 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.
>
>

-- 
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/14e8e820-3e37-471c-95f8-de2027ae3ef8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] Any alternative to SetSslTargetNameOverride?

[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  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+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/c5c3c642-1317-41fe-afd4-d7ff8c117585%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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/FEBE5313-5115-4208-A6B8-F1B58A987020%40earthlink.net.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] 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!

-- 
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/c5c3c642-1317-41fe-afd4-d7ff8c117585%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.