Detect TLS mismatch between Client and Server

Dave Quigley

unread,

Jun 13, 2019, 3:00:43 PM6/13/19

to grpc.io

Hello,

I have enabled TLS between a gRPC client and server and require client auth to be done as part of the exchange. I also have a flag to say that the server should be started without TLS securing the channel. However there does not seem to be a good way to figure out when connecting from a client that expects a TLS handshake that the reason it was unable to connect is that there is a mismatch of expectations. Am I missing something here? It seems that TLS handshake failures are just treated as transient failures and there is no way to get more details.

Dave

Eric Anderson

unread,

Jun 17, 2019, 3:04:06 PM6/17/19

to Dave Quigley, grpc.io

Correct. If the client expects TLS you will get an error if connecting to a plaintext server. Some languages may provide more error information than others, but in all language that information is intended for developers, not programs to inspect.

--
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 view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/f4429762-f894-42df-99a1-f7bdd5301390%40googlegroups.com.

Dave Quigley

unread,

Jun 17, 2019, 4:28:30 PM6/17/19

to grpc.io

The problem though is that is a configuration error. That is something that a user of the software would need to have an idea of what is going on to fix it and asking them to set the two environment variable and crawl through internal grpc debug messages. Also that won't catch if your certificates were not generated properly either. For example if you don't have the caRoot cert installed on your machine but your saying the certificates have to be verified. There was a pull request https://github.com/grpc/grpc-go/pull/2055/ that would introduce the ability to obtain the underlying network failure during a transient failure but it seems to be closed and has gone nowhere. It would really be useful for a person using grpc to develop a program to obtain this information so it can let the user know that they have a configuration issue.

On Monday, June 17, 2019 at 1:04:06 PM UTC-6, Eric Anderson wrote:

Correct. If the client expects TLS you will get an error if connecting to a plaintext server. Some languages may provide more error information than others, but in all language that information is intended for developers, not programs to inspect.

On Thu, Jun 13, 2019 at 12:00 PM Dave Quigley <dqui...@gmail.com> wrote:

Hello,

I have enabled TLS between a gRPC client and server and require client auth to be done as part of the exchange. I also have a flag to say that the server should be started without TLS securing the channel. However there does not seem to be a good way to figure out when connecting from a client that expects a TLS handshake that the reason it was unable to connect is that there is a mismatch of expectations. Am I missing something here? It seems that TLS handshake failures are just treated as transient failures and there is no way to get more details.

Dave

--
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 grp...@googlegroups.com.

Menghan Li

unread,

Jun 18, 2019, 4:04:33 PM6/18/19

to grpc.io

If the connections fail because of TLS issues, the RPCs will also fail, and the RPC errors will have the TLS error message.

The PR https://github.com/grpc/grpc-go/pull/2055/ was to get the underlying connection error after dialing, without making an RPC. But we didn't get to finish the API design.

Dave Quigley

unread,

Jun 19, 2019, 1:13:29 PM6/19/19

to grpc.io

The issue is that I don't want to defer until an RPC is sent to tell the user something is wrong. This is part of an administration tool that has an explicit connect command and it would be good to fail then. Is there any sort of built in NULL rpc that can be used to test the connectivity or would I need to build that into my grpc definitions?

Menghan Li

unread,

Jun 19, 2019, 4:41:37 PM6/19/19

to grpc.io

There's currently no built-in ways to detect this.

You can do a dial WithBlock with FailOnNonTempDialError as mentioned in this issue: https://github.com/grpc/grpc-go/issues/2863#issuecomment-500852442

You will need wrap TLS to make the specific TLS errors non-temporary, and the dial will fail when those errors happen.

Reply all

Reply to author

Forward