Yugabyte gocql sslOptions - Does adding root cert suffice?

General
1

Below is the struct from yugabyte gocql package used to store certificate details:

type SslOptions struct {
	*tls.Config

	// CertPath and KeyPath are optional depending on server
	// config, but both fields must be omitted to avoid using a
	// client certificate
	CertPath string
	KeyPath  string
	CaPath   string //optional depending on server config
	// If you want to verify the hostname and server cert (like a wildcard for cass cluster) then you should turn this on
	// This option is basically the inverse of InSecureSkipVerify
	// See InSecureSkipVerify in http://golang.org/pkg/crypto/tls/ for more info
	EnableHostVerification bool
}

CRUD service is using yugabyte gocql driver to talk to yugabyte database service.

CRUD service sets the CaPath pointing to root cert file. Root certfile carries a trusted public key provided by yugabyte database service. TLS communication works fine with yugabyte service, with just a root cert. am not sure, why it works?

My understanding is,
this digitally signed certificate(root cert) has a trusted public key provided by yugabyte service . This public key is used by core service to perform initial TLS handshake between core service & yugabyte service. This public key is not used by core service for actual TLS communication(data) with yugabyte service. If we prefer symmetric encryption(of data), then core service should share symmetric key(as part of TLS handshake) with yugabyte service to perform encrypted data communication.

Do we not require another key(symmetric key) that can actually be used to perform TLS communication? so that… symmetric key will be shared by core service to yugabyte, as part of initial TLS handshake.

2

symmetric (session) key is randomly generated during the TLS handshake. You don’t provide this key from the client or server.

1 Like