Criptografia em trânsito no Google Cloud

Este é o terceiro whitepaper sobre como o Google usa criptografia para proteger dados de usuários. Neste whitepaper, discutimos em detalhes a criptografia em trânsito do Google Cloud, o que inclui o Google Cloud Platform e o G Suite.

Nós nos dedicamos a manter os dados do cliente protegidos em todos os produtos do Google e tentamos ser o mais transparentes possível sobre a segurança das informações.

O conteúdo apresentado aqui foi editado em dezembro de 2017. Este whitepaper representa o cenário corrente do momento em que foi escrito. Conforme nosso processo de melhoria contínua da proteção de nossos clientes, as políticas e os sistemas de segurança do Google Cloud podem ser alterados no futuro.

Botão de reprodução

Criptografia de dados em trânsito no Google Cloud

Resumo para CIOs

  • O Google emprega várias medidas de segurança para garantir a autenticidade, a integridade e a privacidade dos dados em trânsito.
  • O Google criptografa e autentica todos os dados em trânsito em uma ou mais camadas de rede quando eles são transferidos para outros limites físicos não controlados pelo Google ou em nome dele. Os dados em trânsito dentro de um limite físico controlado pelo Google ou em nome dele geralmente são autenticados, mas não necessariamente criptografados.
  • Dependendo da conexão que está sendo feita, o Google aplica proteções padrão aos dados em trânsito. Por exemplo, protegemos as comunicações entre o usuário e o Google Front End (GFE) usando TLS.
  • Os clientes do Google Cloud que tenham outros requisitos para a criptografia de dados pela WAN podem optar por implementar outras proteções para dados à medida que eles mudam de um usuário para um aplicativo ou entre máquinas virtuais. Essas proteções incluem túneis IPsec, S/MIME para Gmail, certificados SSL gerenciados e Istio.
  • O Google trabalha ativamente com o setor para que a criptografia em trânsito seja acessível a todos. Temos vários projetos de código aberto que incentivam o uso de criptografia em trânsito e a segurança de dados na Internet como um todo, incluindo transparência dos certificados, APIs do Chrome e SMTP seguro.
  • O Google quer continuar sendo o líder do setor em criptografia em trânsito. Para isso, dedicamos recursos ao desenvolvimento e aprimoramento da tecnologia de criptografia. Nessa área, nosso trabalho conta com inovações em Key Transparency e na criptografia pós-quântica.

Introdução

A segurança é frequentemente um fator decisivo na escolha de um provedor de nuvem pública. No Google, a segurança é nossa maior prioridade. Trabalhamos incansavelmente para proteger suas informações, estejam elas na Internet, em movimento pela infraestrutura do Google ou armazenadas nos nossos servidores.

A autenticação, a integridade e a criptografia, tanto para dados em repouso quanto em trânsito, estão no centro da estratégia de segurança do Google. Neste documento, descrevemos nossa abordagem para criptografia em trânsito no Google Cloud.

Para mais informações sobre dados em repouso, consulte Criptografia em repouso no Google Cloud Platform. Você também pode ter uma visão geral de toda a segurança do Google no artigo Visão geral do esquema de segurança da infraestrutura do Google.

Público-alvo: diretores de segurança da informação e equipes de operações de segurança que já usam ou querem usar o Google Cloud.

Pré-requisitos: além desta introdução, supomos que o leitor tenha algum conhecimento sobre criptografia e primitivas criptográficas.

Autenticação, integridade e criptografia

O Google emprega várias medidas de segurança para garantir a autenticidade, a integridade e a privacidade dos dados em trânsito.

  • Autenticação: verificamos a fonte, seja ela um humano ou um processo, e o destino dos dados.
  • Integridade: verificamos se os dados enviados chegam inalterados ao destino.
  • Criptografia: tornamos os dados ininteligíveis durante o trânsito, para mantê-los em sigilo. A criptografia é o processo em que dados legíveis (texto simples) ficam ilegíveis (texto criptografado) para serem acessados somente por pessoas autorizadas pelo respectivo proprietário. Os algoritmos utilizados no processo de criptografia são públicos, mas a chave necessária para descriptografar o texto criptografado é particular. Geralmente, a criptografia em trânsito faz uso da troca de chaves assimétricas, como de Diffie-Hellman, baseada em curva elíptica, para estabelecer uma chave simétrica compartilhada que será usada na criptografia dos dados. Para mais informações sobre criptografia, consulte Introdução à criptografia moderna.

A criptografia pode ser usada para proteger dados em três estados:

  • Criptografia em repouso: protege os dados por meio da criptografia durante o armazenamento, para que não sejam exfiltrados ou afetados em caso de comprometimento do sistema. Frequentemente, usa-se o padrão de criptografia avançada (AES) para criptografar dados em repouso.
  • Criptografia em trânsito: protege os dados caso a comunicação seja interceptada durante a transmissão dos dados entre um site e um provedor de nuvem ou entre dois serviços. Essa proteção é feita por meio da criptografia dos dados antes da transmissão, da autenticação dos endpoints e, por fim, da descriptografia e verificação dos dados na chegada. Por exemplo, muitas vezes, usamos o protocolo Transport Layer Security (TLS) para criptografar dados em trânsito e garantir a segurança de transporte e as Secure/Multipurpose Internet Mail Extensions (S/MIME) para proteger mensagens de e-mail.
  • Criptografia em uso: protege os dados quando eles estão sendo usados por servidores para executar cálculos. Por exemplo, criptografia homomórfica.

A criptografia é um componente de uma estratégia de segurança mais ampla. A criptografia em trânsito tem o propósito de proteger os dados contra ataques após o estabelecimento e a autenticação de uma conexão, ao:

  • acabar com a necessidade de confiar nas camadas mais inferiores da rede que normalmente são fornecidas por terceiros;
  • reduzir a superfície de ataques em potencial;
  • impedir que invasores acessem os dados em caso de interceptação das comunicações.

Ao promover autenticação, integridade e criptografia adequadas, é possível proteger os dados transmitidos entre usuários, dispositivos ou processos em um ambiente perigoso. No restante deste documento, detalhamos a abordagem do Google quanto à criptografia de dados em trânsito e onde ela é aplicada.

Infraestrutura de rede do Google

Limites físicos da rede do Google

O Google aplica proteções diferentes aos dados em trânsito quando eles são transmitidos fora de um limite físico controlado por ou em nome do Google. Um limite físico é a barreira de um espaço físico controlado por ou em nome do Google, em que podemos garantir a aplicação das nossas rigorosas medidas de segurança. O acesso físico a esses locais é restrito e rigorosamente monitorado. Apenas uma pequena porcentagem de funcionários do Google tem acesso ao hardware. Os dados em trânsito dentro desses limites físicos geralmente são autenticados, mas nem sempre criptografados por padrão. É possível escolher quais medidas de segurança adicionais devem ser aplicadas, com base em seu modelo de ameaças.

Devido à escala global da Internet, não podemos aplicar os mesmos controles de segurança física aos links de fibra em nossa WAN ou em qualquer lugar fora dos limites físicos controlados por ou em nome do Google. Por esse motivo, automaticamente impomos proteções adicionais fora do limite físico confiável. Dentre essas proteções está a criptografia de dados em trânsito.

Como o tráfego é encaminhado

Na seção anterior, falamos sobre o limite físico da rede do Google e como aplicamos proteções diferentes aos dados enviados para fora desse limite. Para que você entenda completamente como a criptografia em trânsito funciona no Google, precisamos também explicar como o tráfego é encaminhado pela Internet. Nesta seção, descrevemos como as solicitações são enviadas de um usuário final e chegam ao serviço adequado do Google Cloud ou ao aplicativo do cliente, além de explicar como o tráfego é encaminhado entre serviços.

Um serviço do Google Cloud é um serviço de nuvem modular que oferecemos aos nossos clientes. Esses serviços incluem computação, armazenamento de dados, análise de dados e machine learning. Por exemplo, o Google Cloud Storage e o Gmail são serviços do Google Cloud. Um aplicativo do cliente é um aplicativo hospedado no Google Cloud que você, como nosso cliente, pode criar e implantar usando os serviços do Google Cloud. Aplicativos de clientes ou soluções de parceiros hospedados no Google Cloud não são classificados como serviços do Google Cloud1. Por exemplo, quando você cria um aplicativo com o Google App Engine, o Google Kubernetes Engine ou uma VM no Google Compute Engine, ele é considerado um aplicativo do cliente.

Os cinco tipos de solicitações de encaminhamento abordados abaixo são mostrados na Figura 1. Ela mostra as interações entre os vários componentes de rede e as medidas de segurança aplicadas em cada conexão.

Do usuário final (Internet) para um serviço do Google Cloud

Os serviços do Google Cloud aceitam solicitações de todo o mundo usando um sistema distribuído globalmente chamado Google Front End (GFE). O GFE encerra o tráfego de solicitações recebidas de proxies HTTP(S), TCP e TLS e fornece medidas para prevenção contra ataques de DDoS, além de encaminhar e balancear a carga de tráfego para os próprios serviços do Google Cloud. O GFE tem pontos de presença em todo o mundo, com rotas anunciadas via unicast ou Anycast.

Os GFEs intermedeiam o tráfego direcionado aos serviços do Google Cloud. Eles encaminham as solicitações dos usuários pelo nosso backbone de rede para um serviço do Google Cloud. Essa conexão é autenticada e criptografada desde o GFE até o front-end do serviço do Google Cloud ou do aplicativo do cliente, assim que as comunicações saem do limite físico controlado por ou em nome do Google. A Figura 1 mostra essa interação (identificada como conexão A).

Do usuário final (Internet) para um aplicativo do cliente hospedado no Google Cloud

Há várias maneiras de encaminhar o tráfego da Internet para um aplicativo do cliente hospedado no Google Cloud. A forma como isso acontece depende da configuração do cliente, conforme explicado abaixo. A Figura 1 mostra essa interação (identificada como conexão B).

  • Usando um balanceador de carga externo por proxy HTTP(S) ou TCP/SSL do Google Cloud: um aplicativo do cliente hospedado nas VMs do Google Compute Engine pode usar um serviço balanceador de carga do Google Cloud (GCLB) para encerrar conexões HTTP(S), TLS ou TCP e para fazer proxy, encaminhar e distribuir esse tráfego para suas VMs. Esses serviços balanceadores de carga são implementados pelos GFEs, contanto que os GFEs sejam encerrados e encaminhem o tráfego para os serviços do Google Cloud. Quando o GCLB encaminha o tráfego entre GFEs, as conexões são autenticadas e criptografadas assim que o tráfego sai do limite físico controlado pelo Google ou em nome dele. Assim que o GCLB encaminha o tráfego entre um GFE e uma máquina física que hospeda a VM de um cliente, o tráfego é autenticado. Quando sai do limite físico controlado pelo Google ou em nome dele, o tráfego é criptografado.

    No caso dos balanceadores de carga HTTPS, as conexões entre usuários finais e o GFE são criptografadas e autenticadas com TLS ou QUIC, usando certificados fornecidos pelos clientes para o balanceador de carga. Já no caso dos balanceadores de carga HTTP, as conexões entre usuários finais e o GFE não são criptografadas nem autenticadas. Com os balanceadores de carga SSL, as conexões entre usuários finais e o GFE são criptografadas com TLS e também requerem o uso de certificados fornecidos pelo cliente. No caso de balanceadores de carga TCP, não há criptografia entre o usuário final e o GFE. No entanto, é possível que o aplicativo do cliente use um método de criptografia próprio nas comunicações entre o usuário final e as VMs.

  • Por meio de uma conexão direta com uma VM usando o IP externo ou de balanceador de carga de rede: se você estiver se conectando de uma dessas duas formas, a conexão não passará pelo GFE. Por padrão, ela não será criptografada, e a segurança ficará a critério do usuário.

  • Por meio de uma VPN de nuvem: se estiver se conectando de um host em seu local para uma VM do Google Cloud via VPN, a conexão vai desde seu host no local até a VPN no local, para a VPN do Google, para a VM do Google; a conexão não passa pelo GFE. A conexão é protegida desde a VPN no local até a VPN do Google com IPsec. A conexão entre a VPN do Google e a VM do Google Cloud é autenticada e criptografada assim que as comunicações saem do limite físico controlado pelo Google ou em nome dele.

  • Por meio da interconexão dedicada da nuvem: se você está se conectando via interconexão dedicada, a conexão vai de/para o host no local diretamente e a conexão não passa pelo GFE. Por padrão, essa conexão não é criptografada, e a segurança fica a critério do usuário. Use o protocolo criptográfico da camada 7, Transport Layer Security (TLS), para criptografar o tráfego de aplicativos pela Interconexão dedicada.

De uma máquina virtual para outra

O roteamento entre VMs que ocorre na rede VPC dentro da rede de produção do Google por meio intervalos de sub-rede VPC pode exigir o roteamento de tráfego fora dos limites físicos controlados pelo Google ou em nome dele. Como exemplos de roteamento entre VMs, podemos citar:

  • envio de solicitações entre VMs do Compute Engine;
  • Uma conexão entre a VM de um cliente e uma VM gerenciada pelo Google, como o Cloud SQL

As conexões entre VMs são autenticadas dentro do limite físico e criptografadas quando saem dele. Por padrão, o tráfego entre VMs que usam endereços IP públicos não é criptografado, e a segurança fica a critério do usuário. A Figura 1 mostra essa interação (identificada como conexão C).

Da máquina virtual para o serviço do Google Cloud

As solicitações encaminhadas de uma VM para um serviço do Google Cloud passam por um GFE, exceto nos casos em que o serviço do Google Cloud é executado em uma VM gerenciada pelo Google, conforme discutido acima. O GFE recebe a solicitação e a encaminha da mesma maneira que as solicitações provenientes da Internet: o tráfego de uma VM para um serviço do Google Cloud é encaminhado por caminhos particulares do Google para os mesmos IPs públicos dos GFEs. Com o Acesso privado do Google, as VMs sem IPs públicos podem acessar alguns serviços do Google Cloud e aplicativos de clientes hospedados no Google App Engine. Observe que, quando uma VM se conecta a um aplicativo do cliente hospedado no Google Compute Engine ou no Google Kubernetes Engine, o tráfego é encaminhado por caminhos externos, como ocorre com as solicitações provenientes da Internet. Na Figura 1, é mostrada essa interação, (identificada como conexão D). Para exemplificar esse tipo de encaminhamento de solicitações, citamos a conexão entre uma VM do Compute Engine e o Google Cloud Storage ou uma API de machine learning. Por padrão, os serviços do Google Cloud são compatíveis com a proteção por TLS para essas conexões2. Essa proteção é aplicada no tráfego da VM para o GFE. A conexão é autenticada no tráfego do GFE para o serviço e criptografada caso saia do limite físico.

De um serviço do Google Cloud para outro

O encaminhamento entre serviços de produção ocorre no nosso backbone de rede. Às vezes, é necessário encaminhar o tráfego para fora dos limites físicos controlados por ou em nome do Google. A Figura 1 mostra essa interação (identificada como conexão E). Como exemplo desse tipo de tráfego podemos mencionar um evento do Google Cloud Storage que aciona o Google Cloud Functions. As conexões entre serviços de produção são autenticadas dentro do limite físico e criptografadas quando saem dele.

Figura 1: proteção por padrão e opções sobrepostas na rede do Google

Criptografia em trânsito por padrão

O Google usa vários métodos de criptografia de dados em trânsito, tanto por padrão como configuráveis pelo usuário. O tipo de criptografia depende da camada OSI, do tipo de serviço e do componente físico da infraestrutura. As Figuras 2 e 3 abaixo ilustram as proteções opcionais e padrão que o Google Cloud aplica às camadas 3, 4 e 7.

Figura 2: proteções padrão e opcionais nas camadas 3 e 4 no Google Cloud

Figura 3: proteções padrão e opcionais na camada 7 do Google Cloud3

O restante desta seção descreve as proteções padrão que o Google usa para proteger dados em trânsito.

Criptografia do tráfego entre o usuário e o Google Front End

Atualmente, muitos sistemas usam HTTPS para se comunicarem pela Internet. O HTTPS proporciona segurança ao direcionar o protocolo por meio de uma conexão TLS, garantindo a autenticidade, a integridade e a privacidade de solicitações e respostas. Para aceitar solicitações HTTPS, o receptor requer um par de chaves pública/privada e um certificado X.509 para que uma autoridade de certificação (CA) autentique o servidor. Com o par de chaves e o certificado, as solicitações do usuário na camada 7 (do aplicativo) ficam mais protegidas porque esses dois elementos comprovam que o receptor é o proprietário do nome do domínio de destino das solicitações. Nas subseções a seguir, discutimos os componentes do usuário na criptografia do GFE: TLS, BoringSSL e a autoridade de certificação do Google. Lembre-se de que nem todos os caminhos de cliente fazem encaminhamento via GFE. Ele é usado, sobretudo, no tráfego de um usuário para um serviço do Google Cloud ou para um aplicativo do cliente hospedado no Google Cloud que usa o Google Cloud Load Balancing.

Transport Layer Security (TLS)

Quando um usuário envia uma solicitação para um serviço do Google Cloud, nós protegemos os dados em trânsito por meio de autenticação, integridade e criptografia, usando HTTPS com um certificado proveniente de uma autoridade de certificação (pública) da Web. Todos os dados que o usuário envia para o GFE são criptografados em trânsito com Transport Layer Security (TLS) ou QUIC. O GFE negocia um determinado protocolo de criptografia com o cliente, dependendo do que ele aceita. Quando possível, o GFE negocia protocolos de criptografia mais modernos.

A criptografia por TLS escalada do GFE não é apenas aplicada às interações do usuário final com o Google, mas também facilita as interações da API com o Google por TLS, incluindo com o Google Cloud. Além disso, nossa criptografia por TLS é usada no Gmail para a troca de mensagens com servidores de e-mails externos. Para mais detalhes, consulte TLS obrigatório no Gmail.

O Google é um líder do setor, tanto na adoção do TLS quanto no fortalecimento da implementação deste protocolo. Por esse motivo, ativamos por padrão muitos dos recursos de segurança do TLS. Por exemplo, usamos forward secrecy desde 2011 na nossa implementação do TLS. Com o forward secrecy, garantimos que a chave que protege uma conexão não seja mantida permanentemente. Dessa forma, um invasor que interceptar e ler uma mensagem não conseguirá ler as mensagens anteriores.

BoringSSL

BoringSSL é uma ferramenta de implementação de código aberto do protocolo TLS, criada com base na OpenSSL, mantida pelo Google e compatível com essa interface. O Google criou a BoringSSL com base na OpenSSL para simplificar o uso interno e auxiliar essa biblioteca com os projetos do Chromium e do Android Open Source Project. BoringCrypto, o núcleo da BoringSSL, foi validado quanto à conformidade com o FIPS 140-2 nível 1.

O TLS no GFE é implementado com o BoringSSL. A Tabela 1 mostra os protocolos de criptografia que o GFE aceita para se comunicar com os clientes.

Protocolos Autenticação Troca de chaves Criptografia Funções de hash
TLS 1.34 RSA 2048 Curve25519 AES-128-GCM SHA384
TLS 1.2 ECDSA P-256 P-256 (NIST secp256r1) AES-256-GCM SHA256
TLS 1.1     AES-128-CBC SHA18
TLS 1.05     AES-256-CBC MD59
QUIC6     ChaCha20-Poly1305  
      3DES7  

Tabela 1: criptografia implementada no Google Front End para os serviços do Google Cloud na biblioteca criptográfica da BoringSSL

Autoridade de certificação do Google

Como parte do TLS, um servidor precisa provar a identidade dele ao usuário quando recebe uma solicitação de conexão. Essa verificação é realizada no protocolo TLS quando o servidor apresenta um certificado contendo a identidade declarada. O certificado contém tanto o nome de host DNS quanto a chave pública do servidor. Depois de apresentado, o certificado é assinado por uma autoridade de certificação (CA) emissora de confiança do usuário que solicitou a conexão10. Como resultado, os usuários que solicitam conexões com o servidor precisam somente confiar na CA raiz. Caso o servidor deva ser acessado universalmente, a CA raiz precisa ser conhecida pelos dispositivos de clientes no mundo todo. Atualmente, a maioria dos navegadores e outras implementações de clientes TLS têm o próprio conjunto de CAs raiz configuradas como confiáveis no "repositório raiz".

Há muito tempo que o Google opera a própria CA emissora, que usávamos para assinar certificados para os domínios do Google. No entanto, não operávamos nossa própria CA raiz. Hoje em dia, nossos certificados de CA são assinados por várias CAs raiz que são distribuídas de maneira universal, incluindo a Symantec ("GeoTrust") e raízes operadas anteriormente pela GlobalSign ("GS Root R2" e "GS Root R4").

Em junho de 2017, anunciamos uma transição para o uso de CAs raiz de propriedade do Google. Futuramente, planejamos operar uma CA raiz distribuída universalmente que emitirá certificados para os domínios do Google e nossos clientes.

Migração de chave raiz e rotação de chaves

As chaves da CA raiz não são alteradas com frequência porque a migração para uma CA raiz nova exige que todos os navegadores e dispositivos incorporem a confiança desse certificado, o que leva muito tempo. Como resultado, mesmo com o Google agora operando as próprias CAs raiz, continuaremos confiando em várias CAs raiz de terceiros por um período de transição para atender aos dispositivos legados, enquanto estivermos migrando para as nossas próprias CAs.

Criar uma CA raiz nova requer uma cerimônia de chave. No Google, a cerimônia exige que, no mínimo, três dos seis indivíduos autorizados se reúnam presencialmente para usar as chaves de hardware armazenadas em um cofre. Esses indivíduos devem se encontrar em uma sala apropriada, protegida contra interferências eletromagnéticas, com um módulo de segurança de hardware (HSM, na sigla em inglês) fisicamente isolado, para gerar um conjunto de chaves e certificados. Essa sala está em um local seguro nos data centers do Google. Controles adicionais, como medidas de segurança física, câmeras e outros observadores humanos, garantem que o processo seja realizado conforme planejado. Se a cerimônia for bem-sucedida, o certificado gerado será idêntico a uma amostra de certificado, com exceção do nome do emissor, da chave pública e da assinatura. O certificado da CA raiz gerado é, então, enviado aos navegadores e dispositivos para a incorporação nos programas raiz deles. Esse processo foi concebido para assegurar que seja de conhecimento geral que as chaves privadas associadas têm privacidade e segurança garantidas e, dessa forma, possam ser consideradas como confiáveis por um período de dez anos ou mais.

Conforme descrito anteriormente, as CAs usam as próprias chaves privadas para assinar certificados que, por sua vez, verificam as identidades no início do processo de handshake de TLS na sessão do usuário. Os certificados de servidores são assinados com CAs intermediárias, sendo a criação semelhante à criação de uma CA raiz. Os certificados da CA intermediária são distribuídos como parte da sessão TLS, facilitando a migração para uma nova CA intermediária. Esse método de distribuição também permite que o operador da CA mantenha o material da chave da CA raiz em um estado off-line.

A segurança da sessão TLS depende de a chave do servidor estar bem protegida. Para reduzir ainda mais o risco de comprometimento da chave, a vida útil do certificado de TLS do Google é limitada a, aproximadamente, três meses. Além disso, os certificados são alternados a cada duas semanas, mais ou menos.

Um cliente conectado a um servidor usa uma chave de tíquete privada11 para retornar à sessão anterior com um handshake de TLS reduzido. Por isso, esses tíquetes são muito valiosos para os invasores. O Google alterna as chaves dos tíquetes pelo menos uma vez por dia. As chaves perdem a validade em todas as propriedades a cada três dias. Para mais informações sobre a rotação de tíquetes de chaves de sessão, consulte o artigo Measuring the Security Harm of TLS Crypto Shortcuts.

Do Google Front End para front-ends de aplicativos

Em alguns casos, conforme discutido na sessão Como o tráfego é encaminhado, o usuário se conecta a um GFE dentro de um limite físico diferente do serviço desejado e dos front-ends de aplicativos associados. Quando isso ocorre, a solicitação do usuário e todos os outros protocolos da camada 7, como HTTP, são protegidos por TLS ou encapsulados em uma RPC que, por sua vez, é protegida pelo Application Layer Transport Security (ALTS), mencionado na seção Autenticação, integridade e criptografia de serviço a serviço. Essas RPCs são autenticadas e criptografadas.

Nas comunicações com os serviços do Google Cloud, as RPCs são protegidas com o ALTS por padrão. No caso de aplicativos do cliente hospedados no Google Cloud, se o tráfego for encaminhado via Google Front End (por exemplo, caso o Google Cloud Load Balancer seja usado), o tráfego para a VM será protegido pela criptografia de rede virtual do Google Cloud, descrita na próxima seção.

Criptografia e autenticação da rede virtual do Google Cloud

A infraestrutura da rede virtual do Google Cloud criptografa o tráfego assim que ele sai dos nossos limites físicos. A criptografia é realizada na camada da rede e aplicada ao tráfego de IPs privados dentro de uma mesma nuvem privada virtual (VPC) ou em redes VPC com peering.

Presumimos que qualquer rede que entre em um limite físico não controlado por ou em nome do Google possa ser comprometida por invasores ativos que poderão rastrear, injetar ou alterar o tráfego em trânsito. Garantimos a integridade e a privacidade das comunicações por meio da criptografia quando os dados são transmitidos para fora dos limites físicos que não controlamos.

Usamos o padrão de criptografia avançada (AES) no modo de contador/Galois (GCM, na sigla em inglês) com uma chave de 128 bits (AES-128-GCM) para implementar a criptografia na camada da rede. Cada par de hosts que estão se comunicando estabelece uma chave de sessão por meio de um canal de controle protegido por ALTS para comunicações autenticadas e criptografadas. A chave de sessão é usada para criptografar todas as comunicações de VM para VM entre os hosts. Essas chaves são alternadas periodicamente.

Na camada 3 (da rede), a rede virtual do Google Cloud autentica todo o tráfego entre VMs. Esse processo, realizado com o uso de tokens de segurança, protege um host comprometido contra pacotes de spoofing.

Durante a autenticação, os tokens de segurança são encapsulados em um cabeçalho de túnel que contém as informações de autenticação de quem envia e de quem recebe os dados. O token é configurado pelo plano de controle12 do remetente e validado pelo host de recebimento. Os tokens de segurança são gerados com antecedência para cada fluxo. Eles consistem em uma chave de token (contendo as informações de quem envia os dados) e a chave secreta do host. Há uma chave secreta para cada par de fonte/receptor dos limites físicos controlados por ou em nome do Google. A Figura 4 mostra como chaves de token, as chaves secretas de host e os tokens de segurança são criados.

Figura 4: tokens de segurança

A chave secreta do limite físico é um número pseudoaleatório de 128 bits que dá origem às chaves secretas do host ao assumir um HMAC-SHA1. Ela é negociada por um handshake entre os planos de controle da rede de um par de limites físicos e renegociada a cada poucas horas. Os tokens de segurança usados para a autenticação de cada conexão individual entre VMs, derivados dessas e de outras entradas, são HMACs negociados para um determinado par de remetente e receptor.

Autenticação, integridade e criptografia de serviço a serviço

Dentro da infraestrutura do Google, na camada 7 (do aplicativo), usamos nosso Application Layer Transport Security (ALTS) para fazer a autenticação, manter a integridade e realizar a criptografia de chamadas da RPC do Google que partem do GFE ou de um serviço com destino a outro serviço.

O ALTS usa contas de serviço para fazer a autenticação. Cada serviço na infraestrutura do Google é executado como uma identidade de conta de serviço com credenciais criptográficas associadas. Ao fazer ou receber RPCs de outros serviços, o serviço usa as próprias credenciais para se autenticar. O ALTS verifica essas credenciais usando uma autoridade de certificação interna.

Dentro de um limite físico controlado por ou em nome do Google, o ALTS faz a autenticação e mantém a integridade de RPCs no modo "autenticação e integridade". No caso do tráfego transmitido por WAN fora dos limites físicos controlados por ou em nome do Google, o ALTS aplica automaticamente a criptografia ao tráfego de RPCs na infraestrutura, no modo "autenticação, integridade e privacidade". Atualmente, todo o tráfego direcionado a serviços do Google, incluindo os serviços do Google Cloud, é beneficiado com essas mesmas proteções.

O ALTS também é usado para encapsular outros protocolos da camada 7, como HTTP, em mecanismos de RPC da infraestrutura para o tráfego em trânsito do Google Front End para o front-end de aplicativos. Essa proteção isola a camada do aplicativo e remove qualquer dependência na segurança do caminho da rede.

É possível configurar os serviços para que só aceitem e enviem comunicações ALTS no modo "autenticação, integridade e privacidade", mesmo dentro dos limites físicos controlados por ou em nome do Google. Um exemplo é o serviço interno de gerenciamento de chaves do Google, que armazena e gerencia as chaves de criptografia usadas para proteger os dados armazenados em repouso na infraestrutura do Google.

Protocolo do ALTS

O ALTS tem um protocolo de handshake seguro semelhante ao TLS mútuo. Dois serviços que querem se comunicar usando o ALTS empregam esse protocolo de handshake para autenticar e negociar os parâmetros de comunicação antes de enviar qualquer informação confidencial. O protocolo é um processo em duas etapas:

  • Etapa 1: handshake. O cliente usa o Curve25519 para iniciar um handshake Diffie Hellman de curva elíptica (ECDH, na sigla em inglês) com o servidor. Tanto o cliente quanto o servidor têm parâmetros públicos ECDH certificados como parte do certificado de cada um que será usado durante a troca de chaves Diffie Hellman. O handshake resulta em uma chave de tráfego comum, disponível no cliente e no servidor. As identidades das partes expressas nos certificados são exibidas para que a camada do aplicativo as utilize nas decisões de autorização.
  • Etapa 2: criptografia do registro. A chave de tráfego comum, gerada na primeira etapa, é usada para transmitir, com segurança, o tráfego do cliente para o servidor. No ALTS, a criptografia é implementada com o uso de BoringSSL e outras bibliotecas de criptografia. Geralmente o modo de criptografia adotado é AES-128-GCM e a integridade é garantida pelo GMAC da AES-GCM.

A Figura 5 mostra o handshake do ALTS em detalhes. Nas implementações mais recentes, um auxiliar de processos realiza o handshake. No entanto, esse processo ainda é realizado diretamente pelos aplicativos em alguns casos.

Figura 5: handshake do ALTS

Conforme descrito no início da seção Autenticação, integridade e criptografia de serviço a serviço, o ALTS usa contas de serviço para fazer a autenticação, sendo que cada serviço na infraestrutura do Google é executado como uma identidade de serviço com credenciais criptográficas associadas. Durante o handshake do ALTS, o auxiliar de processos acessa as chaves privadas e os certificados correspondentes usados por cada par de cliente/servidor nas comunicações deles. A chave privada e o certificado correspondente (buffer de protocolo assinado) são provisionados para a identidade da conta de serviço em questão.

Certificados do ALTS Há vários tipos de certificados do ALTS:

  • Certificados de máquinas: fornecem uma identidade aos serviços principais em uma máquina específica. Esses certificados são alternados a cada 6 horas aproximadamente.
  • Certificados de usuários: fornecem uma identidade de usuário final para um código de desenvolvimento do engenheiro do Google. Esses certificados são revezados a cada 20 horas aproximadamente.
  • Certificados de jobs Borg: fornecem uma identidade aos jobs em execução na infraestrutura do Google. Esses certificados são alternados a cada 48 horas aproximadamente.

A chave de assinatura do certificado raiz é armazenada com a autoridade de certificação (CA) interna do Google, que é independente e não tem relação com nossa CA externa.

Criptografia no ALTS

É possível implementar a criptografia no ALTS por meio de vários algoritmos, dependendo das máquinas usadas. Por exemplo, a maioria dos serviços usa AES-128-GCM13. Para saber mais sobre a criptografia no ALTS, consulte a Tabela 2.

Máquinas Criptografia usada nas mensagens  
Mais comum AES-128-GCM  
Sandy Bridge ou mais antigas AES-128-VCM Usa um VMAC, em vez de um GMAC, e é um pouco mais eficiente em máquinas antigas.

Tabela 2: criptografia no ALTS

A maioria dos serviços do Google usa o ALTS ou encapsulamento de RPCs com uso do ALTS. Nos casos em que o ALTS não é utilizado, outras proteções são empregadas. Exemplo:

  • Alguns serviços de gerenciamento de máquinas e bootstrap de nível inferior usam SSH.
  • Alguns serviços de geração de registros da infraestrutura de nível inferior usam TLS ou Datagram TLS (DTLS)14.
  • Alguns serviços que utilizam transportes diferentes de TCP usam outros protocolos criptográficos ou proteções no nível da rede, quando o tráfego ocorre nos limites físicos controlados pelo Google ou em nome dele.

As comunicações entre VMs e os serviços do Google Cloud Platform usam TLS para se comunicar com o Google Front End, em vez do ALTS. Descrevemos esse tipo de comunicação em Criptografia do tráfego entre a máquina virtual e o Google Front End.

Criptografia do tráfego entre a máquina virtual e o Google Front End

No tráfego entre uma VM e o GFE, são usados IPs externos para chegar aos serviços do Google. No entanto, é possível configurar o recurso Acesso privado do Google para usar endereços IP exclusivos do Google nas solicitações.

Assim como acontece com as solicitações de um usuário externo para o Google, por padrão, oferecemos compatibilidade com o tráfego por TLS entre uma VM e o GFE. A conexão acontece da mesma maneira que qualquer outra conexão externa. Para mais informações sobre o TLS, consulte Transport Layer Security (TLS).

Opções de criptografia em trânsito configuráveis pelo usuário

Na seção Criptografia em trânsito por padrão, descrevemos as proteções padrão que o Google aplica aos dados em trânsito. Nesta seção, descrevemos as opções de configuração que nossos usuários podem definir para essas proteções padrão.

Do data center local para o Google Cloud

TLS usando balanceadores de carga externos do GCLB

Se o serviço de nuvem usa um balanceador de carga externo de proxy HTTPS ou SSL do Google, o GFE encerra as conexões TLS dos usuários com certificados SSL provisionados e controlados por você. Para mais informações sobre como personalizar certificados, consulte nossa documentação sobre certificados SSL.

Túnel IPsec usando o Google Cloud VPN

Como cliente do Google Cloud, é possível usar o Google Cloud VPN para conectar sua rede local com segurança à rede da nuvem privada virtual (VPC) do Google Cloud Platform por meio da conexão da VPN com IPsec (camada 3). O tráfego transmitido entre as duas redes é criptografado e descriptografado por gateways de VPN diferentes. Esse procedimento protege os dados no trânsito pela Internet. Além disso, é possível configurar múltiplos túneis com balanceamento de carga por meio de vários gateways de VPN. O Google Cloud VPN protege os dados das seguintes maneiras:

  • Os pacotes enviados das VMs do cliente para a Cloud VPN permanecem dentro da rede do Google. Esses pacotes serão criptografados pela rede virtual do Google Cloud se trafegarem fora dos limites físicos controlados pelo Google ou em nome dele.
  • Os pacotes enviados da Cloud VPN para a VPN local do cliente são criptografados e autenticados com um túnel IPsec.
  • Os pacotes enviados da VPN local para os hosts locais do cliente são protegidos pelo controle que o cliente aplicar à própria rede.

Para configurar uma VPN, crie um gateway da Cloud VPN e um túnel na rede da VPC do serviço hospedado. Em seguida, autorize o tráfego entre as redes. Também há a opção de configurar uma VPN entre duas VPCs.

É possível personalizar ainda mais a rede, especificando a versão do Internet Key Exchange15 (IKE) para o túnel da VPN. É possível optar por uma das duas versões do IKE disponíveis, IKEv1 e IKEv2, sendo que cada versão é compatível com criptografias diferentes. Ao optar pelo IKEv1, o Google faz a criptografia dos pacotes usando AES-128-CBC e fornece integridade com o SHA-1 HMAC16. Já a versão IKEv2 tem uma variedade de criptografias disponíveis e compatíveis. Em todos os casos, o Google Cloud VPN negociará o protocolo comum mais seguro compatível com os dispositivos que estão se comunicando. Instruções completas sobre a configuração de uma VPN podem ser encontradas em nossa documentação Como escolher uma opção de roteamento VPN.

Uma alternativa ao túnel IPsec é a Interconexão dedicada do Google Cloud. Ela fornece conexões físicas diretas e comunicação por IP particular entre a rede local e a do Google. Os dados que trafegam por meio desse método NÃO são criptografados por padrão. Portanto, é necessário protegê-los na camada do aplicativo, por exemplo, usando TLS. O Google Cloud VPN e a Interconexão do Google Cloud usam o mesmo ponto de ligação para que você possa utilizar a criptografia de VPN com IPsec com a Interconexão dedicada. No entanto, para que isso seja possível, também é necessário usar uma solução de terceiros. No momento, não oferecemos compatibilidade com MACsec (proteção da camada 2).

Do usuário para o Google Front End

Certificados SSL gerenciados: certificados gratuitos e automatizados

Ao criar um aplicativo no Google Cloud, é possível configurar seu certificado SSL aproveitando que o GFE é compatível com o TLS. Por exemplo, é possível encerrar a sessão TLS em seu aplicativo. Isso é diferente do tipo de encerramento da sessão TLS descrito em TLS usando balanceadores de carga externos do GCLB.

O Google também fornece certificados SSL gratuitos e automatizados nos domínios personalizados do Firebase Hosting e do Google App Engine. Esses certificados só estão disponíveis para as propriedades hospedadas no Google. Com os domínios personalizados do Google App Engine, você passa a ser capaz de fornecer seus próprios certificados SSL e usar um cabeçalho HTTP Strict Transport Security (HSTS).

Uma vez definido o encaminhamento entre seu domínio e a infraestrutura do Google, solicitamos e recebemos um certificado para esse domínio, a fim de permitir comunicações seguras. Gerenciamos as chaves privadas do servidor TLS, que são RSA de 2048 bits ou ECC secp256r1, e renovamos certificados em nome dos nossos clientes.

TLS obrigatório no Gmail

Conforme discutido na seção Transport Layer Security (TLS), o Gmail usa esse protocolo por padrão. Ele registra e mostra se o último salto de um e-mail foi realizado em uma sessão TLS17. Quando há trocas de e-mails entre usuários do Gmail, esses e-mails são protegidos por TLS ou, em alguns casos, enviados diretamente no aplicativo. Nesses casos, as RPCs usadas pelo aplicativo do Gmail são protegidas pelo ALTS, conforme descrevemos na seção Autenticação, integridade e criptografia de serviço a serviço. No caso das mensagens recebidas de outros provedores de e-mail, o Gmail não aplica o TLS. Os administradores do Gmail podem configurá-lo para tornar obrigatória uma conexão TLS segura para todos os e-mails recebidos e enviados.

Gmail S/MIME

O Secure/Multipurpose Internet Mail Extensions (S/MIME) é um padrão de segurança para e-mails que fornece autenticação, integridade e criptografia. A implementação do padrão S/MIME determina que os certificados associados aos usuários que enviam e-mails sejam hospedados em uma CA pública.

Como administrador, é possível configurar o Gmail para ativar o S/MIME para e-mails enviados, configurar políticas de conformidade para conteúdo e anexos e criar regras de encaminhamento para e-mails recebidos e enviados. Após finalizar a configuração, faça o upload dos certificados públicos dos usuários para o Gmail usando a API do Gmail. No caso de usuários que não utilizam o Gmail, é necessário trocar uma mensagem inicial assinada por S/MIME para definir o S/MIME como padrão.

Criptografia do tráfego entre serviços e entre VMs

O Istio é uma malha de serviço de código aberto desenvolvida pelo Google, IBM, Lyft e outros para simplificar a detecção e a conectividade de serviços. Com a autenticação do Istio, é fornecida criptografia automática de dados em trânsito entre serviços, bem como o gerenciamento de chaves e certificados associados. O Istio é usado no Google Kubernetes Engine e no Google Compute Engine.

Se você quiser implementar a autenticação mútua e a criptografia de cargas de trabalho, use o Istio Auth. Especificamente em cargas de trabalho do Kubernetes, o Istio Auth permite gerar e distribuir certificados por uma CA em nível de cluster, que serão usados na aplicação do mutual Transport Layer Security (mTLS) pod a pod.

Como o Google ajuda a criptografar dados em trânsito na Internet

Nas seções Criptografia em trânsito por padrão e Opções de criptografia em trânsito configuráveis pelo usuário, você verá explicações sobre proteções padrão e personalizáveis aplicadas pelo Google Cloud aos dados em trânsito do cliente. Além do que já foi discutido, o Google tem vários projetos de código aberto e outros esforços que incentivam o uso da criptografia em trânsito e a segurança dos dados na Internet em geral.

Transparência dos certificados

Conforme discutido em Criptografia do tráfego entre o usuário e o Google Front End, para oferecer HTTPS, um site precisa primeiro solicitar um certificado de uma CA da Web (pública) confiável. A Autoridade de certificação é responsável por verificar se o candidato está autorizado pelo titular do domínio, e também garantir que outras informações incluídas no certificado sejam precisas. Esse certificado é então apresentado ao navegador para autenticar o site que o usuário está tentando acessar. Para garantir que o HTTPS seja devidamente autenticado, é importante assegurar que as CAs emitam apenas certificados autorizados pelo titular do domínio.

A Transparência dos certificados (CT) é um esforço iniciado pelo Google em março de 2013 para oferecer aos operadores de sites e titulares de domínios uma maneira de detectar se uma CA emitiu certificados não autorizados ou incorretos. Isso é feito por meio de um mecanismo em que os titulares de domínios, as CAs e o público registram os certificados confiáveis de que tomam conhecimento ou emitem, no caso das CAs. Esses registros são apenas de acréscimo, à prova de adulterações e podem ser verificados publicamente. Os certificados contidos nesses registros podem ser examinados por qualquer pessoa que queira confirmar se as informações estão corretas, precisas e autorizadas.

A primeira versão da Transparência dos certificados foi especificada em uma RFC experimental do IETF, a RFC 6962. Durante o desenvolvimento da Transparência dos certificados, o Google abriu o código de várias ferramentas, inclusive de um servidor de registros de código aberto que pode registrar certificados, bem como ferramentas para a criação de registros da Transparência dos certificados. Além disso, o Google Chrome requer que alguns certificados sejam divulgados publicamente, como os certificados de Validação Estendida (EV) ou aqueles de CAs que já emitiram certificados incorretamente. A partir de 2018, o Chrome exigirá que todos os novos certificados públicos confiáveis sejam divulgados.

Como operador de sites, é possível usar a Transparência dos certificados para detectar se algum certificado não autorizado foi emitido para seu site. Há diversos recursos gratuitos que facilitam essa tarefa, como o Relatório de transparência dos certificados do Google, o site Certificate Search ou as ferramentas do Facebook. Mesmo que você não use a Transparência dos certificados, diversos navegadores atualmente consultam esses dados regularmente para confirmar se as CAs em que os usuários confiam para acessar seu site atendem aos requisitos e seguem as práticas recomendadas do setor, o que reduz o risco de emissão de certificados fraudulentos.

Aumento do uso de HTTPS

Como descrevemos na seção Criptografia do tráfego entre o usuário e o Google Front End, estamos nos empenhando para garantir que nossos sites e serviços forneçam, por padrão, um HTTPS moderno. Nosso objetivo é chegar a 100% de criptografia em nossos produtos e serviços. Para isso, publicamos anualmente um Transparency Report sobre HTTPS que rastreia nosso progresso em direção ao nosso objetivo em todas as propriedades, incluindo o Google Cloud. Continuamos trabalhando para superar as barreiras técnicas que dificultam a compatibilidade de criptografia em alguns de nossos produtos, como soluções para navegadores ou outros clientes incompatíveis com HTTP Strict Transport Security (HSTS)18. Usamos HSTS em alguns de nossos sites, incluindo a página inicial google.com (em inglês), para que os usuários se conectem a um servidor somente por HTTPS.

Sabemos que o restante da Internet também está trabalhando para migrar para o HTTPS e, por isso, tentamos facilitar essa mudança das seguintes maneiras:

Em 2016, começamos a publicar métricas sobre o “uso do HTTPS na Internet” para os 100 sites mais acessados da Internet que não pertencem ao Google. Com essas métricas, buscamos aumentar a conscientização e ajudar a tornar a Internet um lugar mais seguro para todos os usuários. Em outubro de 2017, o Chrome renovou formalmente o apoio financeiro à Let's Encrypt como patrocinadora Platinum.

Aumento no uso de SMTP seguro: indicadores do Gmail

A maioria dos e-mails é trocada com o uso de Simple Mail Transfer Protocol (SMTP) que, por padrão, envia e-mails sem realizar criptografia. Para criptografar um e-mail, o provedor precisa implementar controles de segurança, como o TLS.

Como discutimos na seção Criptografia do tráfego entre o usuário e o Google Front End, o Gmail usa o TLS por padrão. Além disso, em TLS obrigatório no Gmail, descrevemos como os administradores do Gmail podem impor o uso da proteção TLS para e-mails recebidos e enviados. Assim como os esforços do Google para aumentar a transparência do HTTPS, o Gmail fornece dados sobre o uso do TLS para o recebimento de e-mails. Esses dados estão apresentados no nosso Safer Email Transparency Report.

O Google, em parceria com a IETF e outros agentes importantes do setor, está liderando o desenvolvimento do SMTP STS, que é similar ao HSTS para o HTTPS e torna obrigatório o uso de SMTP exclusivamente em canais criptografados.

APIs do Chrome

Em fevereiro de 2015, o Chrome anunciou que novos recursos avançados estariam disponíveis apenas para proteger as origens19. Isso inclui o gerenciamento de informações particulares e o acesso a sensores no dispositivo do usuário. Começando pela geolocalização no Chrome 50, iniciamos o processo de suspensão de uso desses recursos para origens não seguras.

Inovação contínua na criptografia em trânsito

Experiência do usuário dos recursos de segurança do Chrome

O Google Chrome é líder do setor em aproveitar a própria IU para exibir informações de segurança. Dessa forma, os usuários podem saber rapidamente se estão se conectando aos sites de maneira segura. Com essas informações, os usuários podem tomar decisões embasadas sobre quando e como compartilhar dados. O Chrome conduz uma pesquisa extensa sobre os usuários, e os resultados dela são compartilhados em documentos revistos por outros pesquisadores.

Para ajudar a proteger ainda mais os usuários, o Chrome anunciou que, até o final de 2017, marcará todas as conexões HTTP como não seguras. A partir do Chrome 56, por padrão, os usuários verão um aviso caso uma página HTTP inclua um formulário com os campos de senha ou cartão de crédito. No Chrome 62, um aviso será exibido quando o usuário inserir dados em uma página HTTP, bem como em todas as páginas HTTP visitadas no modo de navegação anônima. Futuramente, o Chrome mostrará um aviso para todas as páginas disponibilizadas por HTTP.

Para ver como determinadas configurações são exibidas para os usuários no Chrome, use a ferramenta BadSSL.

Key Transparency

Um grande obstáculo para a adoção generalizada da criptografia de mensagens é a dificuldade na troca de chaves públicas: como é possível encontrar de maneira confiável uma chave pública de um novo usuário com quem estamos nos comunicando? Para ajudar a resolver esse problema, em janeiro de 2017, o Google anunciou a Key Transparency (em inglês). Trata-se de um framework aberto que oferece um meio genérico, seguro e auditável de distribuir chaves públicas. Com ele. os usuários não precisam realizar a verificação de chaves manualmente. O Key Transparency é destinado principalmente à distribuição de chaves públicas de usuários nas comunicações, por exemplo, criptografia de e-mail E2E e OpenPGP. A concepção do Key Transparency aborda uma nova maneira de recuperar e distribuir chaves com base nos insights recebidos da Transparência dos certificados e do CONIKS (links em inglês).

O Key Transparency é um diretório de código aberto implementado por meio de uma árvore Merkle de grande escala. Com a verificação do Key Transparency, é possível ver as chaves associadas a contas e há quanto tempo uma conta está ativa e estável. A meta desse trabalho do Google a longo prazo é permitir que qualquer um execute um servidor do Key Transparency, e facilitar a integração com inúmeros aplicativos.

Criptografia pós-quântica

O Google quer continuar sendo o líder do setor em criptografia em trânsito. Para tanto, começamos a trabalhar na área de criptografia pós-quântica. Esse tipo de criptografia permite substituir as primitivas criptográficas existentes, que são vulneráveis a ataques quânticos eficientes, por candidatos pós-quânticos, que são considerados mais resistentes. Em julho de 2016, anunciamos a realização de um teste sobre a viabilidade da implantação dessa criptografia usando o algoritmo criptográfico pós-quântico New Hope na versão do desenvolvedor do Chrome. Além desse trabalho, os pesquisadores do Google publicaram documentos sobre outros protocolos pós-quânticos práticos para troca de chaves.

Apêndice

Leia mais sobre a Segurança do Google Cloud, incluindo nossa Visão geral de projeto da segurança de infraestrutura e sobre a conformidade do Google Cloud, incluindo o relatório de auditoria SOC 3 público.

Notas de rodapé

1Entre as soluções de parceiros, encontram-se as oferecidas no Cloud Launcher e os produtos criados em colaboração com parceiros, como o Cloud Dataprep.
2Por exemplo, ainda é possível desativar essa criptografia para o acesso HTTP a buckets do Google Cloud Storage.
3 As comunicações entre VMs e serviços não protegidas na camada 7 permanecem protegidas nas camadas 3 e 4
4 O TLS 1.3 ainda não está finalizado. A versão preliminar foi implementada somente em determinados domínios do Google, como o Gmail, para a realização de testes.
5 O TLS 1.0 é compatível com o Google em navegadores que ainda usam essa versão do protocolo. Observe que todos os sites Google que processam informações de cartão de crédito deixarão de ser compatíveis com o TLS 1.0 até julho de 2018, quando o Setor de Cartões de Pagamento (PCI, na sigla em inglês) passará a exigir a suspensão de uso desse recurso.
6 Para mais detalhes sobre o QUIC, acesse [https://www.chromium.org/quic](https://www.chromium.org/quic).
7, 8, 9 Para que haja compatibilidade com versões anteriores de alguns sistemas operacionais legados, aceitamos 3DES, SHA1 e MD5
10Nos casos de certificados em cadeia, a CA é temporariamente confiável.
11 Ela pode ser um tíquete de sessão ([RFC 5077](https://tools.ietf.org/html/rfc5077)) ou um ID de sessão ([RFC 5246](https://tools.ietf.org/html/rfc5246)).
12 O plano de controle faz parte da rede que transporta o tráfego de sinalização e é responsável pelo encaminhamento.
13 Anteriormente eram usados outros protocolos, hoje obsoletos. Menos de 1% dos jobs usam esses protocolos mais antigos.
14 O Datagram TLS (DTLS) oferece segurança aos aplicativos baseados em datagramas, o que evita espionagens e adulterações durante a comunicação.
15 Internet Key Exchange (IKE) é o protocolo usado para configurar uma associação de segurança no conjunto de protocolos IPsec.
16HMAC-SHA-1 não é quebrado por uma [colisão SHA-1] (https://shattered.io/), como a colisão SHAttered que os pesquisadores do Google descobriram.
17 No G Suite Enterprise, isso não aparece na interface do usuário. Os administradores de domínios podem examinar os dados dos próprios domínios usando [Email Log Search] (https://support.google.com/a/answer/2604578).
18 HTTP Strict Transport Security (HSTS) é um mecanismo que permite aos sites declararem-se acessíveis apenas por conexões seguras e/ou para que os usuários possam direcionar seus agentes para a interação com sites específicos apenas em conexões seguras.
19 Origens seguras são conexões que correspondem a determinados esquemas, hosts ou [padrões de] portas (https://www.chromium.org/Home/chromium-security/prefer-secure-origins-for-powerful-new-features).