Go - Server with TLS and Insecure Client

3,373 views
Skip to first unread message

Amit Saha

unread,
Jul 2, 2021, 4:26:50 AM7/2/21
to grpc.io
Hello all,

I have a Go server configured to use self-signed TLS certs. When I
specify the certificate to the client, it all works great.

When I try to connect to the server over an insecure channel, it seems
that the channel gets established, but i get an error when i make the
RPC method call:

2021/07/02 17:37:04 Error getUser
2021/07/02 17:37:04 rpc error: code = Unavailable desc = connection closed

Is this expected?

Thanks,
Amit.

Menghan Li

unread,
Jul 12, 2021, 2:25:31 PM7/12/21
to grpc.io
Yes, this is expected. The connection cannot be created, because the server is expecting a handshake, but the client is not configured to do it.

The only thing is, I would expect a better error message.
Can you check the client and server logs and see if there's any information?

Thanks,
Menghan

Amit Saha

unread,
Jul 13, 2021, 6:45:22 PM7/13/21
to Menghan Li, grpc.io
On Tue, Jul 13, 2021 at 4:25 AM 'Menghan Li' via grpc.io
<grp...@googlegroups.com> wrote:
>
> Yes, this is expected. The connection cannot be created, because the server is expecting a handshake, but the client is not configured to do it.
>
> The only thing is, I would expect a better error message.
> Can you check the client and server logs and see if there's any information?
> https://github.com/grpc/grpc-go#how-to-turn-on-logging

On the server:

WARNING: 2021/07/14 08:38:25 [core] grpc: Server.Serve failed to
complete security handshake from "[::1]:56653": tls: first record does
not look like a TLS handshake

On the client:

INFO: 2021/07/14 08:38:25 [core] parsed scheme: ""
INFO: 2021/07/14 08:38:25 [core] scheme "" not registered, fallback to
default scheme
INFO: 2021/07/14 08:38:25 [core] ccResolverWrapper: sending update to
cc: {[{localhost:50051 <nil> 0 <nil>}] <nil> <nil>}
INFO: 2021/07/14 08:38:25 [core] ClientConn switching balancer to "pick_first"
INFO: 2021/07/14 08:38:25 [core] Channel switches to new LB policy "pick_first"
INFO: 2021/07/14 08:38:25 [core] Subchannel Connectivity change to CONNECTING
INFO: 2021/07/14 08:38:25 [core] blockingPicker: the picked transport
is not ready, loop back to repick
INFO: 2021/07/14 08:38:25 [core] Subchannel picks a new address
"localhost:50051" to connect
INFO: 2021/07/14 08:38:25 [core] pickfirstBalancer:
UpdateSubConnState: 0x14000113d30, {CONNECTING <nil>}
INFO: 2021/07/14 08:38:25 [core] Channel Connectivity change to CONNECTING
INFO: 2021/07/14 08:38:25 [core] Subchannel Connectivity change to
TRANSIENT_FAILURE
INFO: 2021/07/14 08:38:25 [core] pickfirstBalancer:
UpdateSubConnState: 0x14000113d30, {TRANSIENT_FAILURE connection
closed}
INFO: 2021/07/14 08:38:25 [core] Channel Connectivity change to
TRANSIENT_FAILURE

----
# My error logs
2021/07/14 08:38:25 Error getUser
2021/07/14 08:38:25 rpc error: code = Unavailable desc = connection closed
----

INFO: 2021/07/14 08:38:25 [transport] transport: loopyWriter.run
returning. connection error: desc = "transport is closing"

The above client behavior is without WithBlock(). When I specify
WithBlock(), the above connection attempt essentially continues (as
expected - since it is a TRANSIENT_FAILURE).

The interesting thing however which now explains my original query is
when I insert a time.Sleep() between establishing the connection and
calling the RPC method, i do see the above logs as well. My original
confusion was that I should have got the error due to TLS before I
made the RPC method, not when making the RPC method. However, I have
got that clarified now with the time.Sleep(..) and the logging.

Thanks. If there is any further investigation I can do, I would be keen to know.

Best Regards,
Amit



>
> Thanks,
> Menghan
>
> On Friday, July 2, 2021 at 1:26:50 AM UTC-7 amits...@gmail.com wrote:
>>
>> Hello all,
>>
>> I have a Go server configured to use self-signed TLS certs. When I
>> specify the certificate to the client, it all works great.
>>
>> When I try to connect to the server over an insecure channel, it seems
>> that the channel gets established, but i get an error when i make the
>> RPC method call:
>>
>> 2021/07/02 17:37:04 Error getUser
>> 2021/07/02 17:37:04 rpc error: code = Unavailable desc = connection closed
>>
>> Is this expected?
>>
>> Thanks,
>> Amit.
>
> --
> 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/c97f567d-45e8-476f-8e5a-f2142a24ef93n%40googlegroups.com.

Menghan Li

unread,
Jul 14, 2021, 1:14:49 PM7/14/21
to grpc.io
The server side log tells you the connection is closed due to TLS failures.

The client is configured to _not_ to TLS, so it doesn't understand the handshake message, and will try to send plaintext. It only sees the connection is closed, but doesn't know why.
The client can only report TLS errors if it understands TLS. But an insecure client doesn't.

WithBlock() only changes whether Dial() will waits for connection to become READY, it doesn't change the connection behavior. With or without WithBlock(), the same failure would happen, and the same log would be printed.
Without WithBlock(), maybe things happened too fast that the client got killed before the logs were flushed?

Amit Saha

unread,
Jul 14, 2021, 7:03:09 PM7/14/21
to Menghan Li, grpc.io

On 15 Jul 2021, at 3:14 am, 'Menghan Li' via grpc.io <grp...@googlegroups.com> wrote:

The server side log tells you the connection is closed due to TLS failures.

The client is configured to _not_ to TLS, so it doesn't understand the handshake message, and will try to send plaintext. It only sees the connection is closed, but doesn't know why.
The client can only report TLS errors if it understands TLS. But an insecure client doesn't.

WithBlock() only changes whether Dial() will waits for connection to become READY, it doesn't change the connection behavior. With or without WithBlock(), the same failure would happen, and the same log would be printed.
Without WithBlock(), maybe things happened too fast that the client got killed before the logs were flushed?

That clarifies my understanding as well.

Thank you.

Best Regards,
Amit.


Abdul Salam

unread,
Aug 14, 2021, 7:56:40 PM8/14/21
to grpc.io
Please could you inform how you resolved this issue. I am unable to figure out the solution

Amit Saha

unread,
Aug 14, 2021, 8:07:12 PM8/14/21
to Abdul Salam, grpc.io

On 15 Aug 2021, at 9:56 am, Abdul Salam <ab...@mercurie.ng> wrote:

Please could you inform how you resolved this issue. I am unable to figure out the solution

You will have to configure your client to use a secure connection as well.

Abdul Salam

unread,
Aug 15, 2021, 3:04:43 AM8/15/21
to grpc.io
How can i do this on Cloud Run. I am following the example herehttps://cloud.google.com/run/docs/triggering/grpc,
but seems my docker container doesnt have certificates OR what am I missing.

Now i am getting error": "rpc error: code = Unavailable desc = upstream connect error or disconnect/reset before headers. reset reason: protocol error"
}
I am using host:443, pls what could be the problem?

Amit Saha

unread,
Aug 15, 2021, 3:27:16 AM8/15/21
to Abdul Salam, grpc.io

On 15 Aug 2021, at 5:04 pm, Abdul Salam <ab...@mercurie.ng> wrote:

How can i do this on Cloud Run. I am following the example herehttps://cloud.google.com/run/docs/triggering/grpc,
but seems my docker container doesnt have certificates OR what am I missing.

Now i am getting error": "rpc error: code = Unavailable desc = upstream connect error or disconnect/reset before headers. reset reason: protocol error"
}
I am using host:443, pls what could be the problem?

I am not familiar with cloud run. That said, are you getting the above error when running the client described at https://cloud.google.com/run/docs/triggering/grpc#connect
 ? From the example it seems like the certificate exposed via the cloud run service should be trusted by the system’s cert pool. But from the error message, it does sound like there is an issue there. Can you share more details about your setup? 

How are you running the client?


Reply all
Reply to author
Forward
0 new messages