Professional Cloud DevOps Engineer Certification Learning Path > Cloud Operations and Service Mesh with Anthos > Securing Network Traffic with Anthos Service Mesh: statements correcting the video

gistfile1.txt

There is several SERIOUS errors in the short video that show a severe lack of understanding of how TLS works (I'm sorry for the harsh words).

Let me elaborate:

The lecturer says: "This process is called 'asymmetric encryption' since we're only encrypting the sent message."

This is absolutely wrong. A TLS channel is always "fully encrypted," i.e. encryption happens in both directions. "Asymmetric encryption" is called "asymmetric," because encryption and decryption happens with different keys (public key for encryption, and private key for decryption,) and not with the same key (THIS is why it's called "symmetric encryption", because the encryption and decryption happens using the same key.)

Moreover, the lecturer says: "However, in a microservice architecture, we are going to have services communicating both ways, so traffic must also be encrypted from Service B to Service A. Therefore, when Service A establishes the connection with Service B, it will share a symmetric key, which both services can use to encrypt and decrypt messages."

As explained, the symmetric encryption is not called that way because it is the means used to make sure encryption occurs in both directions, but because of the symmetric use of the (one and only) encryption/decryption key.

Symmetric encryption is used to encrypt the data channel, because it is far less computationally intensive, while asymmetric encryption (also called "public key (PK) encryption") is extremely computationally intensive. This is why you use PK encryption initially only to securely transmit the key for the symmetric encryption. The recipient decrypts the encrypted symmetric key with its private key, and then it uses this symmetric key to decrypt data received via the encrypted data channel, and to encrypt data before sending it across the data channel again.


Moreover, the lecturer says: "Specifically, when Service A first tries to establish an encrypted connection, it not only shares a symmetric key, but also asks Service B for a certificate of its identity [...]."

That would be the wrong order. FIRST Service A makes sure it's actually talking to the party it expects (by verifying the server's certificate,) and only after successful verification it continues sending the encrypted key for the symmetric encryption/decryption.

Moreover, the lecturer says: "Service A then asks a trusted adviser called a Certificate Authority (or CA) that proves that the certificate is valid and proceeds based on what the CA says."

That's not exactly what's happening. Service A is not "'asking' the CA." Service A is using the CA's public key (stored locally within Service B!) to check the signature on Server B's certificate (possibly involving intermediate CA public keys). This is happening locally on Service A, no external communication is typically taking place here. Only if the signature on the certificate can be verified, Service A knows that the CA actually issued the certificate. If the "distinguished name" inside the certificate or one of the "subject alternative names" matches Service B's hostname that Service A has been talking to, only then it continues talking to Service B, otherwise it aborts the dialog.

Moreover, the lecturer says: "Since we need authentication and encryption both ways, when Service A wants to establish the connection with Service B, both certificates are exchanged and checked against the Trusted CA and the symmetric key is used to encrypt the messages."

This implies that each of the certificates (the client's certificate and the server's certificate) is used to encrypt "one direction of the dialog." Again, that is simply wrong.

In "mutual TLS" or "mTLS," the client certificate is used for the client to securely identify itself. When the client initiates the connection, it first checks the server's certificate as explained above. ONLY THEN (if verification was successful) if would continue to send its own client certificate. The server would then verify the client certificate (against whatever CA certificate(s) it trusts), and ONLY THEN the mTLS connection would continue to be set up, otherwise the server would abort the handshake.

Finally, the lecturer says: "The process of authenticating services and encrypting messages both ways is called 'mutual TLS' or 'mTLS.'"

Again, the "mutual" in mTLS is NOT about "encryption both ways," but it is ONLY about mutual authentication: server authenticates to client, and client authenticates to server.

Ok, I'm done. I spent a lot of time to write this down, but I sincerely hope the video will be corrected accordingly.

Many thanks for your attention.