Google has deployed authentication and encryption for communication between its services, developing a customer transport layer security (TLS) protocol.
Its application layer transport security (ALTS) protocol is used to secure remote procedure calls (RPCs) within Google's cloud infrastruture.
Google said it started developing ALTS in 2007, and went with a custom security solution rather than the standard transport layer security (TLS) in the pursuit of less complexity in design and implemention.
As such, ALTS makes it easier to monitor bugs and vulnerabilities through manual code inspection or extensive fuzzing.
ALTS has been tailored for Google's production environment, and some compromises have been made to cater for this, resulting in trade-offs compared to the industry standard TLS 1.2 and 1.3 protocols.
The company said that by design, the ALTS handshake protocol is susceptible to key compromise impersonation (KCI) attacks; where an attacker who compromises the private Diffie-Hellman resumption key of a workload can use the credential to authenticate fake workloads as legitimate ones to other tasks.
Enabling protection against KCI attacks would only be worthwhile in environments where encrypted workload resumption is not desired, Google said.
As Google's RPCs are long-lived, the company also decided not to implement session resumptions that require no roundtrips (0-RTT), as it added complexity and ends up weakening security compared to ALTS.
ALTS is also not designed to disguise the internal sevices that communicate with one another, and doesn't encrypt handshake messages for that purpose.
Perfect forward secrecy, a technique that prevents attackers who capture future private keys from decrypting past communications, is supported in ALTS but not enabled by default. Instead, Google uses frequent certificate rotation to establish a similar protections for most of its applications.
