Take the scenario from the security concepts page:
Suppose the legitimate servers that run the service
datastoreonly use the
infra-teamidentity. A malicious user has certificate and key for the
test-teamidentity. The malicious user intends to impersonate the service to inspect the data sent from the clients. The malicious user deploys a forged server with the certificate and key for the
test-teamidentity. Suppose the malicious user successfully hacked the discovery service or DNS to map the
datastoreservice name to the forged server.
When a client calls the
datastoreservice, it extracts the
test-teamidentity from the server’s certificate, and checks whether
test-teamis allowed to run
datastorewith the secure naming information. The client detects that
test-teamis not allowed to run the
datastoreservice and the authentication fails.
It appears that envoy builds the allowed SANs list for a TCP server based on the listener config which is selected using the destination IP address of the outbound packet. There is not much else to use in TCP. So, in the example scenario, the client (envoy) would extract the
test-team identity from the server’s certificate and check it against the list of valid names that are associated with the malicious destination IP address returned from DNS. Envoy is asking the question: is
test-team allowed to run the malicious
datastore. The answer is yes and envoy will make the connection, contrary to what’s stated in the documentation.
Did I miss something that mitigates this attack?