NewServerTLS vs NewClientTLS in example

[nleiva]

Thanks for your blog post, very inspiring. One thing I noticed while trying to implement this on a gRPC client is your example calls NewServerTLSFromCert instead of NewClientTLSFromCert. I personally use client configs for Dial options (I might be off here).

conn, err := grpc.Dial(*serverAddr, grpc.NewServerTLSFromCert(tlsCert))
if err != nil {
	...
}
defer conn.Close()

So, in my case I had to create a certPool with the PeerCertificates that I can pass to NewClientTLSFromCert(cp *x509.CertPool, serverNameOverride string).

certPool := x509.NewCertPool()
for _, cert := range tconn.ConnectionState().PeerCertificates {
	certPool.AddCert(cert)
}

The good news is that it works!, I could connect to the devices (server) without manually providing the .pem certificate file. On the other hand, I'm still wrapping my head around this as NewClientTLSFromCert pass this cert as RootCAs.

func NewClientTLSFromCert(cp *x509.CertPool, serverNameOverride string) TransportCredentials {
	return NewTLS(&tls.Config{ServerName: serverNameOverride, RootCAs: cp})
}

[nleiva]

After further testing, it seems Go gRPC implementation magically uses the server public key to encrypt messages on the client (still trying to find out where exactly), so you wouldn't need to grab it from the handshake. The following creates a connection where the RPC's are encrypted, not sure exactly how yet.

config := &tls.Config{
		InsecureSkipVerify: true,
	}
opts = append(opts, grpc.WithTransportCredentials(credentials.NewTLS(config)))
conn, err := grpc.DialContext(ctx, host, opts...)

[johnsiilver]

Hey nleiva,

I’m currently on vacation, but I’ll have a deeper look when I return about your first comment.

However on the second comment, by doing skipverify, you are telling grpc not to verify the public cert. You will get transport encryption, but you might be doing it to a man in the middle. The server in this case can also only provide its public cert and not the cert chain that validates the cert.

Finally, because you didn’t get the cert in the handshake, you cannot validate the cert is signed by a trusted root CA you expect.

So in essence, no one can listen to the conversation, but you don’t know who you are talking to.

[nleiva]

No worries, take your time and enjoy your time off.

I actually created a few test cases here to probe this. You don't need to access the Server certificate yourself in order to validate it, it will be done for you.

If you clone the repo, do make cert and then make run-server in a tab and make run-client-ca in another, you will see the connection is successfully created (and encrypted) and the Server cert is validated against the CA cert you need to provide. You can also load CA certs from your system with x509.SystemCertPool().

If you don't provide the CA cert, the connection is not established (if InsecureSkipVerify is false). You can test this with make run-client-noca.