Encriptación en tránsito en Google Cloud

Este es el tercer informe acerca de cómo Google usa la encriptación para proteger tus datos. En este informe, encontrarás información más detallada sobre la encriptación en tránsito de Google Cloud, incluidos Google Cloud Platform y G Suite.

Nos esforzamos en mantener una alta protección de los datos de los clientes en todos los productos de Google y ser lo más transparentes posible sobre nuestros métodos de protección.

El contenido de este documento corresponde a diciembre de 2017. Este informe técnico representa el statu quo en el momento de su redacción. Es posible que las políticas y los sistemas de seguridad de Google Cloud cambien en un futuro, ya que mejoramos la protección de nuestros clientes de forma continua.

Botón de reproducción

Encriptación en tránsito de Google Cloud

Resumen para directores de generales de información

  • Google usa varias medidas de seguridad para garantizar la autenticidad, la integridad y la privacidad de los datos en tránsito.
  • Google encripta y autentica todos los datos en tránsito en una o más capas de red cuando los datos se transfieren fuera de los límites físicos no controlados por Google ni en su nombre. En general, los datos en tránsito dentro de un límite físico controlado por Google o en su nombre se autentican, pero no siempre se encriptan.
  • Según la conexión que se realice, Google aplica las protecciones predeterminadas a los datos en tránsito. Por ejemplo, aseguramos las comunicaciones entre el usuario y el Google Front End (GFE) mediante la TLS.
  • Los clientes de Google Cloud con requisitos adicionales de encriptación de datos a través de WAN pueden elegir la implementación de protección de datos adicional a medida que se transfieren de un usuario a una aplicación o de una máquina virtual a otra. Estas protecciones incluyen túneles IPsec, S/MIME de Gmail, Istio y certificados SSL administrados.
  • Google trabaja de forma activa con el sector para que todas las personas, en cualquier lugar, tengan acceso a la encriptación en tránsito. Tenemos varios proyectos de código abierto que promueven el uso de la encriptación en tránsito y la seguridad de los datos en Internet a gran escala, que incluyen el Certificado de transparencia, las API de Chrome y el SMTP seguro.
  • Google pretende seguir siendo el líder de la industria de encriptación en tránsito. A fin de lograrlo, dedicamos recursos para desarrollar y mejorar la tecnología de encriptación. Nuestro trabajo en este campo incluye innovaciones en las áreas de Key Transparency y criptografía poscuántica.

Introducción

La seguridad suele ser un factor decisivo al momento de elegir un proveedor de servicios en la nube pública. En Google, la seguridad es lo más importante. Trabajamos sin descanso para proteger tus datos, ya sea que estén en tránsito en Internet, en transferencia dentro de la infraestructura de Google o almacenados en nuestros servidores.

La autenticación, la integridad y la encriptación de datos en reposo y en tránsito son fundamentales para la estrategia de seguridad de Google. En este informe, se describe nuestro enfoque respecto a la encriptación en tránsito de Google Cloud.

Para obtener información sobre los datos en reposo, consulta Encriptación en reposo en Google Cloud Platform. Para ver una descripción general de toda la seguridad de Google, consulta la descripción general del diseño de seguridad de la infraestructura de Google.

Público: Este documento está dirigido a los equipos de operaciones de seguridad y a los CISO que usan o piensan usar Google Cloud.

Requisitos previos: Además de esta introducción, se da por sentado que tienes conocimientos básicos sobre la encriptación y las primitivas criptográficas.

Autenticación, integridad y encriptación

Google usa varias medidas de seguridad para garantizar la autenticidad, la integridad y la privacidad de los datos en tránsito.

  • Autenticación: Verificamos la fuente de datos, ya sea una persona o un proceso, y su destino.
  • Integridad: Nos aseguramos de que los datos que envíes lleguen intactos a su destino.
  • Encriptación: Para mantener la privacidad de tus datos, los hacemos ilegibles mientras estén en tránsito. La encriptación es el proceso que convierte datos legibles (texto simple) en datos ilegibles (texto cifrado) a fin de garantizar que solo las partes autorizadas por el propietario de los datos puedan acceder al texto sin formato. Los algoritmos que se usan en el proceso de encriptación son públicos, pero la clave necesaria para desencriptar el texto cifrado es privada. A menudo, la encriptación en tránsito usa un intercambio de claves asimétricas, como el intercambio basado en curvas elípticas de Diffie-Hellman, para crear una clave simétrica compartida que se usa en la encriptación de datos. Para obtener más información sobre la encriptación, consulta Introduction to Modern Cryptography (Introducción a la criptografía moderna).

La encriptación se puede usar para proteger los datos en tres estados:

  • La encriptación en reposo protege tus datos contra la vulneración del sistema o el robo de datos mediante la encriptación mientras están almacenados. A menudo, se usa el estándar de encriptación avanzada (AES) para encriptar los datos en reposo.
  • Encriptación en tránsito: Protege tus datos en caso de que se intercepten las comunicaciones mientras se transfieren datos entre tu sitio y el proveedor de servicios en la nube o entre dos servicios. Para lograr esta protección, los datos se encriptan antes de su transmisión, los extremos se autentican, y los datos se desencriptan y verifican en el momento de su llegada. Por ejemplo, la seguridad de la capa de transporte (TLS) se usa con frecuencia para encriptar datos en tránsito y garantizar la seguridad durante su transferencia, mientras que las Extensiones de Correo de Internet de Propósitos Múltiples/Seguro (S/MIME) se usan a menudo para la seguridad de los mensajes de correo electrónico.
  • Encriptación en uso: Protege tus datos cuando los servidores los usan para ejecutar cálculos; p. ej., la encriptación homomórfica.

La encriptación es uno de los componentes de una estrategia de seguridad más amplia. Una vez establecida y autenticada una conexión, la encriptación en tránsito protege tus datos contra posibles atacantes mediante las siguientes acciones:

  • Quita la necesidad de confiar en las capas inferiores de la red, las que, con frecuencia, son proporcionadas por terceros.
  • Reduce la posible superficie de exposición a ataques.
  • Impide que los atacantes accedan a los datos si se interceptan las comunicaciones.

Con una autenticación, integridad y encriptación adecuadas, es posible proteger los datos que se transfieren entre usuarios, dispositivos o procesos en un entorno hostil. En lo que queda de este informe, se explica el enfoque de Google respecto a la encriptación de datos en tránsito y dónde se aplica.

Infraestructura de red de Google

Límites físicos de la red de Google

Google aplica diferentes protecciones a los datos en tránsito cuando se transmiten fuera de un límite físico controlado por Google o en su nombre. Un límite físico es la barrera de un espacio físico controlado por Google o en su nombre donde podemos garantizar el uso de medidas de seguridad estrictas. El acceso físico a estas ubicaciones es restringido y se supervisa exhaustivamente. Solo un pequeño porcentaje de los empleados de Google tiene acceso al hardware. En general, se autentican los datos en tránsito dentro de estos límites físicos, pero puede que no se encripten de manera predeterminada. Puedes elegir las medidas de seguridad adicionales que deseas aplicar en función de tu modelo de amenaza.

Debido a la escala mundial de Internet, no podemos aplicar estos mismos controles de seguridad física en los vínculos de fibra de nuestra WAN ni en cualquier lugar fuera de los límites físicos controlados por Google o en su nombre. Es por esta razón que aplicamos automáticamente protecciones adicionales fuera de nuestro límite de confianza físico. Estas protecciones incluyen la encriptación de los datos en tránsito.

Cómo se enruta el tráfico

En la sección anterior, tratamos el límite físico de la red de Google y cómo aplicamos protecciones diferentes a los datos que salen de este límite. A fin de entender por completo cómo funciona la encriptación en tránsito de Google, es necesario explicar el modo en que el tráfico se enruta a través de Internet. En esta sección se describe cómo las solicitudes van desde un usuario final hasta el servicio de Google Cloud o la aplicación del cliente correspondientes y cómo se enruta el tráfico entre servicios.

Un servicio de Google Cloud es un servicio de nube modular que ofrecemos a nuestros clientes. Estos servicios incluyen cómputo, almacenamiento de datos, análisis de datos y aprendizaje automático. Por ejemplo, Google Cloud Storage y Gmail son servicios de Google Cloud. Una aplicación de cliente es una aplicación alojada en Google Cloud que tú, como cliente de Google, puedes compilar y también implementar mediante los servicios de Google Cloud. Las aplicaciones de clientes o soluciones de socios alojadas en Google Cloud no se consideran servicios de Google Cloud.1 Por ejemplo, una aplicación compilada con Google App Engine, Google Kubernetes Engine o una VM en Google Compute Engine es una aplicación de cliente.

En la figura 1, se muestran los cinco tipos de solicitudes de enrutamiento que se analizan a continuación. En esta figura, se muestran las interacciones entre los diversos componentes de red y la seguridad aplicada a cada conexión.

Del usuario final (Internet) a un servicio de Google Cloud

Los servicios de Google Cloud aceptan solicitudes de todo el mundo a través de un sistema de distribución mundial llamado Google Front End (GFE). El GFE finaliza el tráfico entrante de proxy TLS, HTTP(S) y TCP, proporciona contramedidas para aplacar los ataques de DSD y, además, enruta el tráfico y balancea sus cargas a los servicios de Google Cloud en sí. Existen puntos de presencia del GFE en todo el mundo con rutas anunciadas a través de Unicast o Anycast.

Los GFE autorizan el tráfico a los servicios de Google Cloud. Los GFE enrutan la solicitud del usuario a través de nuestra red troncal a un servicio de Google Cloud. Esta conexión se autentica y encripta desde el GFE hasta el frontend del servicio de Google Cloud o la aplicación del cliente cuando esas comunicaciones salen de un límite físico controlado por Google o en su nombre. La figura 1 muestra esta interacción (conexión A).

Del usuario final (Internet) a una aplicación de cliente alojada en Google Cloud

Existen diversas maneras de enrutar el tráfico de Internet a una aplicación de cliente alojada en Google Cloud. El modo en que tu tráfico se enruta depende de tu configuración, como se explica a continuación. Esta interacción se muestra en la figura 1 (conexión B).

  • Uso de un balanceador de cargas externo de proxy de HTTP(S) o TCP/SSL de Google Cloud: Una aplicación de cliente alojada en VM de Google Compute Engine puede usar un servicio de balanceador de cargas de Google Cloud (GCLB) para finalizar las conexiones HTTP(S), TLS o TCP y para usar un proxy con este tráfico, y enrutarlo y distribuirlo a sus VM. Los GFE implementan estos servicios de balanceador de cargas, a la vez que finalizan y enrutan tráfico para servicios de Google Cloud. Cuando el GCLB enruta el tráfico entre los GFE, las conexiones se autentican y, cuando el tráfico sale de un límite físico controlado por Google o en su nombre, estas se encriptan. Cuando un GCLB enruta el tráfico entre un GFE y una máquina física que aloja a la VM de un cliente, este tráfico se autentica. Además, cuando el tráfico sale de un límite físico controlado por Google o en su nombre, se encripta.

    En el caso de los balanceadores de cargas HTTPS, las conexiones entre los usuarios finales y el GFE se encriptan y autentican con TLS o QUIC mediante certificados que los clientes proporcionan al balanceador de cargas. En el caso de los balanceadores de cargas HTTP, las conexiones entre los usuarios finales y el GFE no se encriptan ni autentican. En el caso de los balanceadores de cargas SSL, las conexiones entre los usuarios finales y el GFE se encriptan con TLS y, de manera similar, usan certificados proporcionados por los clientes. En el caso de los balanceadores de cargas TCP, no hay encriptación entre el usuario final y el GFE. Sin embargo, la aplicación del cliente puede usar su propia encriptación entre el usuario final y las VM.

  • Uso de una conexión directa a una VM mediante una IP externa o una IP de balanceador de cargas de red: Si te conectas a través de la IP externa de la VM o a través de la IP de un balanceador de cargas de red, la conexión no pasa por el GFE. Esta conexión no se encripta de forma predeterminada, y su seguridad se proporciona a discreción del usuario.

  • Uso de una VPN de Cloud: Si te conectas desde un host local a una VM de Google Cloud a través de una VPN, la conexión no pasa por el GFE, ya que hay una comunicación directa entre tu host local, la VPN local, la VPN de Google y la VM de Google Cloud. La conexión está protegida desde la VPN local hasta la VPN de Google con IPsec. La conexión de la VPN de Google a la VM de Google Cloud se autentica y encripta cuando esas comunicaciones salen de un límite físico controlado por Google o en su nombre.

  • Uso de una interconexión dedicada de Cloud: Si utilizas una interconexión dedicada, la conexión no pasa por el GFE, ya que hay una comunicación directa con tu host local. Esta conexión no se encripta de forma predeterminada, y su seguridad se proporciona a discreción del usuario. Puedes usar el protocolo criptográfico de Capa 7 de seguridad de la capa de transporte (TLS) para encriptar el tráfico de la aplicación a través de una interconexión dedicada.

Entre máquinas virtuales

Es posible que el enrutamiento entre VM que ocurre en nuestra tecnología de red mediante direcciones IP privadas RFC 1918 necesite un tráfico de enrutamiento fuera de los límites físicos controlados por Google o en su nombre. Algunos ejemplos de enrutamiento entre VM:

  • VM de Compute Engine enviándose solicitudes entre sí
  • La VM de un cliente conectándose a una VM administrada por Google como Cloud SQL

Las conexiones entre VM se encriptan si salen de un límite físico y se autentican dentro del límite físico. El tráfico entre VM a través de direcciones IP públicas no se encripta de forma predeterminada, y su seguridad se proporciona a discreción del usuario. Esta interacción se muestra en la figura 1 (conexión C).

De máquina virtual al servicio de Google Cloud

Si una VM enruta una solicitud a un servicio de Google Cloud, esta se enruta a un GFE (salvo en los casos en que el servicio de Google Cloud se ejecuta en una VM administrada por Google, como se mencionó anteriormente). El GFE recibe la solicitud y la enruta al igual que las solicitudes que provienen de Internet: en el caso del tráfico desde una VM hasta un servicio de Google Cloud, se enruta mediante rutas privadas de Google a las mismas IP públicas del GFE. El Acceso privado a Google permite que las VM sin IP públicas accedan a algunos servicios de Google Cloud y a aplicaciones de clientes alojadas en Google App Engine. (Ten en cuenta que si una VM se conecta a una aplicación de cliente alojada en Google Compute Engine o Google Kubernetes Engine, ese tráfico se enruta al igual que las solicitudes que provienen de Internet, a través de rutas externas). En la figura 1, se muestra esta interacción (conexión D). Un ejemplo de este tipo de solicitud de enrutamiento ocurre entre una VM de Compute Engine y Google Cloud Storage o una API de aprendizaje automático. De manera predeterminada, los servicios de Google Cloud admiten la protección de estas conexiones con TLS2. Esta protección se aplica desde la VM hasta el GFE. La conexión se autentica desde el GFE hasta el servicio y se encripta si la conexión sale de un límite físico.

Entre servicios de Google Cloud

El enrutamiento de un servicio de producción a otro se realiza en nuestra tecnología de red, y es posible que requiera el enrutamiento del tráfico fuera de los límites físicos controlados por Google o en su nombre. La figura 1 muestra esta interacción (conexión E). Un ejemplo de este tipo de tráfico es un evento de Google Cloud Storage que activa a Google Cloud Functions. Las conexiones entre los servicios de producción se encriptan si salen de un límite físico y se autentican dentro del límite físico.

Figura 1: Protección predeterminada y opciones superpuestas en la red de Google

Encriptación en tránsito de forma predeterminada

Google usa diversos métodos de encriptación de datos en tránsito, tanto predeterminados como configurables por el usuario. El tipo de encriptación usado depende de la capa OSI, del tipo de servicio y del componente físico de la infraestructura. Las figuras 2 y 3 muestran las protecciones opcionales y predeterminadas que Google Cloud aplica a las capas 3, 4 y 7.

Figura 2: Protección predeterminada y opciones en las capas 3 y 4 en Google Cloud

Figura 3: Protección predeterminada y opciones en la capa 7 en Google Cloud3

En el resto de esta sección, se describen las protecciones predeterminadas que Google usa para proteger los datos en tránsito.

Encriptación del usuario al Google Front End

En la actualidad, muchos sistemas usan HTTPS para comunicarse a través de Internet. HTTPS brinda seguridad mediante la dirección del protocolo a través de una conexión TLS, lo que garantiza la autenticidad, integridad y privacidad de las solicitudes y respuestas. Para aceptar las solicitudes HTTPS, el receptor necesita un par de claves públicas/privadas y un certificado X.509 de autenticación de servidor proporcionado por una autoridad certificada (CA). El par de claves y el certificado ayudan a proteger las solicitudes de un usuario en la capa de aplicación (capa 7), ya que son prueba de que el receptor es propietario del nombre de dominio para el que se realizan las solicitudes. Las subsecciones siguientes abordan los componentes de la encriptación entre el usuario y el GFE, es decir: TLS, BoringSSL y la autoridad certificada de Google. Ten en cuenta que no todas las rutas de cliente se enrutan a través del GFE; en particular, el GFE se usa para el tráfico desde un usuario hasta un servicio de Google Cloud y desde un usuario hasta una aplicación de cliente alojada en Google Cloud que usa Google Cloud Load Balancing.

Seguridad de la capa de transporte (TLS)

Cuando un usuario envía una solicitud a un servicio de Google Cloud, aseguramos los datos en tránsito con autenticación, integridad y encriptación usando el protocolo HTTPS con un certificado de una autoridad certificada web (pública). Todos los datos que el usuario envía al GFE se encriptan en tránsito mediante la seguridad de la capa de transporte (TLS) o QUIC. El GFE negocia un protocolo de encriptación determinado con el cliente en función de lo que el cliente puede admitir. Cuando es posible, el GFE negocia protocolos de encriptación más modernos.

La encriptación TLS en escala del GFE no solo se aplica a las interacciones del usuario final con Google, sino que también facilita las interacciones de las API con Google a través de la TLS, incluido Google Cloud. Además, nuestra encriptación TLS se usa en Gmail para intercambiar correos electrónicos con servidores de correo externos (más información en la sección sobre cómo exigir TLS en Gmail).

Google es líder del sector tanto en la adopción de la TLS como en el fortalecimiento de su implementación. Para ello, habilitamos de forma predeterminada muchas de las características de seguridad de TLS. Por ejemplo, usamos la confidencialidad directa en nuestra implementación de la TLS desde 2011. La confidencialidad directa se encarga de que la clave que protege una conexión no sea persistente, de modo tal que un atacante que intercepte y lea un mensaje no pueda leer los anteriores.

BoringSSL

BoringSSL es una implementación de código abierto que mantiene Google del protocolo TLS. Proviene de OpenSSL, y su interfaz es, en su mayoría, compatible con OpenSSL. Google bifurcó BoringSSL de OpenSSL a fin de simplificar OpenSSL para el uso interno y lograr una mayor compatibilidad con los proyectos de código abierto de Android y Chromium. BoringCrypto, el núcleo de BoringSSL, cuenta con la validación FIPS 140-2 de nivel 1.

La TLS se implementa en el GFE con BoringSSL. La tabla 1 muestra los protocolos de encriptación compatibles con el GFE cuando este se comunica con los clientes.

Protocolos Autenticación Intercambio de claves Encriptación Funciones 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  

Tabla 1: Encriptación implementada en el Google Front End para los servicios de Google Cloud y también implementada en la biblioteca criptográfica BoringSSL

Autoridad certificada de Google

Como parte de la TLS, un servidor debe demostrar su identidad al usuario cuando recibe una solicitud de conexión. Esta verificación de identidad se logra en el protocolo TLS cuando se hace que el servidor presente un certificado que contenga la identidad afirmada. El certificado contiene el nombre de host DNS del servidor y su clave pública. Una vez presentado el certificado, lo firma una autoridad certificada (CA) emisora, que es de confianza para el usuario que solicita la conexión.10 Como resultado, los usuarios que solicitan conexiones al servidor solo necesitan confiar en la CA raíz. Si el servidor desea otorgar acceso universal, los dispositivos cliente de todo el mundo deben conocer la CA raíz. Actualmente, la mayoría de los navegadores y otras implementaciones de cliente de TLS cuentan con su propio conjunto de CA raíz que están configuradas como confiables en su "tienda raíz".

Google siempre ha operado su propia CA emisora, la cual usamos para firmar los certificados de los dominios de Google. Sin embargo, no operábamos nuestra propia CA raíz. En la actualidad varias CA raíces distribuidas por todo el mundo firman nuestros certificados de CA, entre ellas Symantec (“GeoTrust”) y raíces que GlobalSign operaba anteriormente (“Raíz GS R2” y “Raíz GS R4”).

En junio de 2017, anunciamos la transición hacia el uso de CA raíces de propiedad de Google. Con el tiempo, planeamos operar una CA raíz distribuida por todo el mundo que emita certificados para los dominios de Google y para nuestros clientes.

Migración de clave raíz y rotación de claves

Las claves de CA raíz no cambian con frecuencia, ya que migrar a una nueva CA raíz implica que todos los navegadores y dispositivos depositen su confianza en ese certificado, lo cual es un proceso demoroso. Como resultado, aun cuando Google opera ahora sus propias CA raíces, seguiremos dependiendo de varias CA raíces de terceros para un período de transición a fin de responder a los dispositivos heredados mientras migramos a las nuestras.

Crear una CA raíz nueva requiere una ceremonia de claves. En Google, la ceremonia ordena que un mínimo de 3 de las 6 personas autorizadas posibles se reúnan físicamente para usar claves de hardware almacenadas en una caja fuerte. Estas personas se reúnen en una habitación dedicada, protegida contra la interferencia electromagnética y con un módulo de seguridad de hardware (HSM) aislado, para generar un conjunto de claves y certificados. La habitación dedicada se encuentra en una ubicación segura en los centros de datos de Google. Existen controles adicionales, como medidas de seguridad físicas, cámaras y otros observadores humanos, que garantizan que el proceso se lleve a cabo según lo planeado. Si la ceremonia se realiza correctamente, el certificado generado es idéntico a un certificado de muestra, salvo por el nombre del emisor, la clave pública y la firma. Luego, el certificado de CA raíz resultante se envía a los programas raíces de navegadores y dispositivos para su inclusión. Este proceso se diseñó para garantizar la comprensión total de la privacidad y la seguridad de las claves privadas asociadas, a fin de que las claves sean confiables durante una década o más.

Como se explicó anteriormente, las CA usan sus claves privadas para firmar certificados, y estos verifican identidades cuando se inicia un protocolo de enlace TLS como parte de la sesión de un usuario. Los certificados de servidores se firman con CA intermedias, cuya creación es similar a la de una CA raíz. Los certificados de la CA intermedia se distribuyen como parte de la sesión de TLS para que sea más fácil migrar a una nueva CA intermedia. Este método de distribución también permite que el operador de la CA mantenga el material de la clave de la CA raíz en estado sin conexión.

La seguridad de una sesión de TLS depende del nivel de protección de la clave del servidor. Para lograr una mayor mitigación del riesgo de vulnerabilidad de claves, los ciclos de vida de los certificados TLS de Google se limitan a alrededor de tres meses y se rotan aproximadamente cada dos semanas.

Un cliente que ya se conectó antes a un servidor puede usar una clave de ticket privada11 para reanudar una sesión previa con un protocolo de enlace TLS abreviado, lo que hace que estos tickets sean muy valiosos para un atacante. Google rota las claves de tickets al menos una vez al día y se encarga de que las claves de todas las propiedades caduquen cada 3 días. Para obtener más información sobre la rotación de claves de tickets de sesión, consulta la página sobre cómo medir el peligro a la seguridad de los accesos directos criptográficos de TLS.

Del Google Front End a frontends de aplicaciones

En algunos casos, como se explica en Cómo se enruta el tráfico, el usuario se conecta a un GFE dentro de un límite físico diferente del servicio deseado y del frontend de aplicaciones asociado. Cuando esto ocurre, la solicitud del usuario y cualquier otro protocolo de capa 7, como HTTP, recibe la protección de TLS o se encapsula en una RPC protegida mediante la seguridad de transporte de la capa de la aplicación (ALTS). Esto se explica en Autenticación, integridad y encriptación entre servicios. Estas RPC están autenticadas y encriptadas.

En el caso de los servicios de Google Cloud, las RPC se protegen usando ALTS de forma predeterminada. En el caso de las aplicaciones de cliente alojadas en Google Cloud, si el tráfico se enruta mediante el Google Front End (por ejemplo, si usan el balanceador de cargas de Google Cloud), el tráfico a la VM se protege mediante la encriptación de redes virtuales de Google Cloud, que se describe en la sección siguiente.

Encriptación y autenticación de redes virtuales de Google Cloud

La infraestructura de redes virtuales de Google Cloud permite la encriptación cuando el tráfico sale de nuestros límites físicos. La encriptación se realiza en la capa de red y se aplica al tráfico de IP privado dentro de la misma nube privada virtual (VPC) o a través de redes de VPC de intercambio de tráfico.

Se da por hecho que cualquier red que cruce un límite físico no controlado por Google ni en su nombre puede estar expuesta a un adversario activo que puede husmear, inyectar o alterar el tráfico en curso. Para garantizar la integridad y privacidad de las comunicaciones, usamos encriptación cuando los datos salen de límites físicos que no controlamos.

Usamos el Estándar de encriptación avanzada (AES) en modo Galois/Counter (GCM) con una clave de 128 bits (AES-128-GCM) para implementar la encriptación en la capa de red. Cada par de hosts en comunicación establece una clave de sesión mediante un canal de control protegido por ALTS para comunicaciones autenticadas y encriptadas. La clave de sesión se usa para encriptar todas las comunicaciones de VM a VM entre esos hosts; las claves de sesión se rotan con regularidad.

En la capa de red (capa 3), la red virtual de Google Cloud autentica todo el tráfico entre las VM. Esta autenticación, que se realiza mediante tokens de seguridad, impide que un host vulnerado pueda falsificar la identidad de paquetes en la red.

Durante la autenticación, los tokens de seguridad se encapsulan en un encabezado de túnel que contiene la información de autenticación del emisor y del receptor. El plano de control12 del lado emisor define el token, mientras que el host receptor lo valida. Los tokens de seguridad se generan previamente para cada flujo y se componen de una clave de token (que contiene la información del emisor) y el secreto de host. Existe un secreto por cada par emisor-receptor de límites físicos controlados por Google o en su nombre. La figura 4 muestra cómo se crean las claves de tokens, los secretos de host y los tokens de seguridad.

Figura 4: Tokens de seguridad

El secreto de límite físico es un número seudoaleatorio de 128 bits del cual derivan los secretos de host mediante un HMAC-SHA1. El secreto de límite físico se negocia a través de un protocolo de enlace entre los planos de control de red de un par de límites físicos y se vuelve a negociar cada cierta cantidad de horas. Los tokens de seguridad que se usan para la autenticación individual entre VM, que derivan de estas y otras entradas, son HMAC negociados para un par de emisor-receptor determinado.

Autenticación, integridad y encriptación entre servicios

En la infraestructura de Google, usamos nuestra Seguridad de transporte de la capa de la aplicación (ALTS) en la capa de la aplicación (7) para la autenticación, integridad y encriptación de las llamadas RPC de Google desde el GFE hacia un servicio y entre servicios.

La ALTS usa cuentas de servicio para la autenticación. Cada servicio que se ejecuta en la infraestructura de Google lo hace como una identidad de cuenta de servicio con credenciales criptográficas asociadas. Cuando se hacen RPC o se reciben de otros servicios, un servicio usa sus credenciales para autenticarse. La ALTS verifica estas credenciales mediante una autoridad certificada interna.

En un límite físico controlado por Google o en su nombre, la ALTS brinda integridad y autenticación de RPC en modo "integridad y autenticación". En el caso del tráfico por la WAN fuera de los límites físicos controlados por Google o en su nombre, la ALTS aplica automáticamente la encriptación para el tráfico de RPC de la infraestructura en modo "autenticación, integridad y privacidad". Actualmente, todo el tráfico hacia los servicios de Google, incluidos los servicios de Google Cloud, se benefician de esas mismas protecciones.

La ALTS también se usa para encapsular otros protocolos de la capa 7, como HTTP, en mecanismos de RPC de infraestructura para el tráfico que va desde el Google Front End hacia el frontend de la aplicación. Esta protección aísla la capa de la aplicación y quita cualquier dependencia de la seguridad de la ruta de red.

Es posible configurar los servicios para que acepten y envíen comunicaciones ALTS solo en el modo “autenticación, integridad y privacidad”, incluso en límites físicos controlados por Google o en su nombre. Un ejemplo es el servicio de administración de claves internas de Google, que almacena y administra las claves de encriptación que se usan para proteger los datos almacenados en reposo en la infraestructura de Google.

Protocolo ALTS

La ALTS tiene un protocolo de enlace seguro similar a la TLS mutua. Dos servicios que desean comunicarse usando la ALTS utilizan este protocolo de enlace para autenticarse y negociar los parámetros de comunicación antes de enviar cualquier información sensible. El protocolo es un proceso de dos pasos:

  • Paso 1: Protocolo de enlace El cliente inicia un protocolo de enlace de curva elíptica de Diffie Hellman (ECDH) con el servidor mediante Curve25519. Tanto el cliente como el servidor tienen parámetros públicos ECDH certificados como parte de su certificado, que se usa durante un intercambio de claves Diffie Hellman. El protocolo de enlace da como resultado una clave de tráfico común que está disponible en el cliente y en el servidor. Las identidades de intercambio de tráfico de los certificados se envían a la capa de la aplicación para su uso en decisiones de autorización.
  • Paso 2: Registro de la encriptación Mediante la clave de tráfico común del paso 1, los datos se transmiten del cliente al servidor de manera segura. La encriptación en ALTS se implementa mediante BoringSSL y otras bibliotecas de encriptación. La encriptación suele ser AES-128-GCM, mientras que el GMAC de AES-GCM proporciona la integridad.

La figura 5 muestra el protocolo de enlace ALTS en detalle. En las implementaciones nuevas, un ayudante de procesos ejecuta el protocolo de enlace; no obstante, existen casos en los que las aplicaciones hacen esto directamente.

Figura 5: Protocolo de enlace ALTS

Como se describió al principio de la sección Autenticación, integridad y encriptación entre servicios, la ALTS usa cuentas de servicio para la autenticación, con cada servicio que se ejecuta en la infraestructura de Google como una identidad de servicio con credenciales criptográficas asociadas. Durante el protocolo de enlace ALTS, el ayudante de procesos accede a las claves privadas y los certificados correspondientes que cada par cliente-servidor usa en sus comunicaciones. La clave privada y el certificado correspondiente (búfer de protocolo firmado) se aprovisionaron para la identidad de la cuenta de servicio del servicio.

Certificados ALTS Existen muchos tipos de certificados ALTS:

  • Certificados de máquina: Proporcionan una identidad a los servicios principales en una máquina específica. Rotan cada 6 horas, aproximadamente.
  • Certificados de usuario: Proporcionan una identidad de usuario final para un código de desarrollo de un ingeniero de Google. Rotan cada 20 horas, aproximadamente.
  • Certificados de trabajos Borg: Proporcionan una identidad a los trabajos que se ejecutan en la infraestructura de Google. Rotan cada 48 horas, aproximadamente.

La clave de firma del certificado raíz se almacena en la autoridad certificada (CA) interna de Google, que no guarda ninguna relación con nuestra CA externa y es independiente de ella.

Encriptación en ALTS

La encriptación en ALTS puede implementarse mediante diversos algoritmos, dependiendo de las máquinas que se usan. Por ejemplo, la mayoría de los servicios usa AES-128-GCM13. Encontrarás más información sobre la encriptación ALTS en la tabla 2.

Máquinas Encriptación de mensajes usada  
Más común AES-128-GCM  
Sandy Bridge o más antigua AES-128-VCM Usa un VMAC en vez de un GMAC y es levemente más eficiente en estas máquinas más antiguas.

Tabla 2: Encriptación en ALTS

La mayoría de los servicios de Google usa ALTS o encapsulación de RPC que usa ALTS. Si no se usa ALTS, se emplean otras protecciones. Por ejemplo:

  • Algunos servicios de inicialización y administración de máquinas de nivel bajo usan SSH
  • Algunos servicios de registro de infraestructura de bajo nivel TLS o Datagram TLS (DTLS)14
  • Algunos servicios que usan transporte no TCP utilizan otros protocolos criptográficos o protecciones a nivel de red cuando se encuentran en límites físicos controlados por Google o en su nombre

Las comunicaciones entre las VM y los servicios de Google Cloud Platform usan TLS en vez de ALTS para comunicarse con el Google Front End. Estas comunicaciones se describen en Encriptación de máquina virtual al Google Front End.

Encriptación de máquina virtual al Google Front End

El tráfico de VM al GFE usa IP externas para alcanzar los servicios de Google, pero es posible configurar la función Acceso privado a Google a fin de usar solo direcciones IP de Google para las solicitudes.

Al igual que con las solicitudes de un usuario externo a Google, admitimos el tráfico TLS de manera predeterminada desde una VM hacia el GFE. La conexión se realiza del mismo modo que cualquier otra conexión externa. Para obtener más información sobre la TLS, consulta Seguridad de la capa de transporte (TLS).

Opciones configurables por el usuario para la encriptación en tránsito

En Encriptación en tránsito de forma predeterminada, se describen las protecciones predeterminadas que Google aplica a los datos en tránsito. En esta sección se describen las configuraciones que pueden efectuar nuestros usuarios para estas protecciones predeterminadas.

Del centro de datos local a Google Cloud

TLS con balanceadores de cargas GCLB externos

Si tu servicio de nube usa un balanceador de cargas externo de Google de proxy SSL o HTTPS, el GFE finaliza las conexiones TLS de los usuarios que usen certificados SSL que tú aprovisionas y controlas. Si deseas obtener más información para personalizar tu certificado, consulta nuestra documentación sobre certificados SSL.

Túnel IPsec con Google Cloud VPN

Como cliente de Google Cloud, puedes usar Google Cloud VPN para conectar de manera segura tu red local a tu red de nube privada virtual (VPC) de Google Cloud Platform mediante una conexión de VPN de IPsec (capa 3). Una puerta de enlace VPN encripta el tráfico que viaja entre las dos redes, y la otra puerta de enlace de VPN lo desencripta. Esto protege tus datos a través de Internet. Además, puedes configurar varios túneles con carga balanceada a través de varias puertas de enlace VPN. Google Cloud VPN protege tus datos de las siguientes maneras:

  • Los paquetes desde tus VM hasta Cloud VPN permanecen en la red de Google. La red virtual de Google Cloud encripta estos paquetes si viajan fuera de los límites físicos controlados por Google o en su nombre.
  • Los paquetes desde Cloud VPN hasta tu VPN local se encriptan y autentican con un túnel IPsec.
  • Los paquetes desde tu VPN local hasta tus hosts locales están protegidos por los controles que colocaste en tu red.

Para configurar una VPN, crea una puerta de enlace y un túnel de Cloud VPN en la red de VPC del servicio alojado y, luego, permite el tráfico entre las redes. También puedes configurar una VPN entre dos VPC.

Puedes personalizar aún más tu red si especificas la versión del intercambio de claves de Internet15 (IKE) de tu túnel VPN. Existen dos versiones de IKE para elegir: IKEv1 e IKEv2. Cada una es compatible con algoritmos de cifrado diferentes. Si especificas IKEv1, Google encriptará los paquetes con AES-128-CBC y brindará integridad a través de SHA-1 HMAC16. En el caso de IKEv2, diversos algoritmos de cifrado están disponibles y son compatibles. En todos los casos, Google Cloud VPN negociará el protocolo común más seguro que sea compatible con los dispositivos de intercambio de tráfico. Puedes consultar las instrucciones completas para configurar una VPN en nuestra documentación que te ayudará a elegir una opción de enrutamiento de VPN.

Una alternativa para un túnel IPsec es la interconexión dedicada de Google Cloud. La interconexión dedicada proporciona conexiones físicas directas y una comunicación RFC 1918 entre tu red local y la red de Google. Los datos que pasan por esta conexión NO están encriptados de manera predeterminada, por lo que deben protegerse en la capa de la aplicación usando, por ejemplo, la TLS. Google Cloud VPN y Google Cloud Interconnect usan el mismo punto de anclaje, por lo que puedes usar la encriptación de VPN de IPsec con la interconexión dedicada; sin embargo, para lograr esto, necesitarás usar una solución de terceros. Actualmente, MACsec (protección de la capa 2) no es compatible.

Del usuario al Google Front End

Certificados SSL administrados: certificados gratuitos y automatizados

Cuando compilas una aplicación en Google Cloud, puedes configurar el certificado SSL que uses para aprovechar la compatibilidad del GFE con la TLS. Por ejemplo, puedes hacer que la sesión TLS finalice en tu aplicación. Esta finalización es distinta de la finalización de TLS descrita en TLS con balanceadores de cargas externos de GCLB.

Google también ofrece certificados SSL gratuitos y automatizados en los dominios personalizados de Firebase Hosting y Google App Engine. Estos certificados solo están disponibles para las propiedades alojadas en Google. Con los dominios personalizados de Google App Engine, también puedes proporcionar tus propios certificados SSL y usar un encabezado de HTTP con Seguridad de Transporte Estricta (HSTS).

Una vez que tu dominio esté dirigido hacia la infraestructura de Google, solicitaremos y obtendremos un certificado para ese dominio a fin de permitir las comunicaciones seguras. Administramos las claves privadas de servidor de TLS, que son RSA de 2,048 bits o secp256r1 ECC, y renovaremos los certificados en nombre de nuestros clientes.

Requerir TLS en Gmail

Como se indica en Seguridad de la capa de transporte, Gmail usa TLS de forma predeterminada. Gmail registra y muestra si el último salto que realizó un correo electrónico fue a través de una sesión de TLS.17 Cuando dos usuarios de Gmail intercambian correos electrónicos, estos mensajes cuentan con protección de TLS o, en algunos casos, se envían directamente en la aplicación. En estos casos, la ALTS protege las RPC que usa esta aplicación según se describe en Autenticación, integridad y encriptación entre servicios. En el caso de los mensajes entrantes recibidos de otros proveedores de correo electrónico, Gmail no aplica TLS de manera forzosa. Los administradores de Gmail pueden configurar la aplicación a fin de que exija una conexión TLS segura para todos los correos electrónicos entrantes y salientes.

S/MIME de Gmail

Las Extensiones de Correo de Internet de Propósitos Múltiples/Seguro (S/MIME) son un estándar de seguridad de correos electrónicos que brindan autenticación, integridad y encriptación. La implementación del estándar S/MIME exige que los certificados asociados con los usuarios que envían correos electrónicos se alojen en una CA pública.

Como administrador, puedes configurar Gmail para habilitar S/MIME en los correos electrónicos salientes, configurar políticas para el cumplimiento de contenido y archivos adjuntos, y crear reglas de enrutamiento para los correos electrónicos entrantes y salientes. Tras finalizar la configuración, debes subir los certificados públicos de los usuarios a Gmail mediante la API de Gmail. En el caso de los usuarios externos a Gmail, se debe intercambiar un mensaje inicial firmado por S/MIME para definir S/MIME como la opción predeterminada.

Encriptación entre servicios y entre VM

Istio es una malla de servicios de código abierto desarrollada por Google, IBM y Lyft, entre otros, para simplificar el descubrimiento y la conectividad de servicios. La autenticación de Istio brinda encriptación automática de datos en tránsito entre servicios y administración de las claves y certificados asociados. Istio puede usarse en Google Kubernetes Engine y en Google Compute Engine.

Si deseas implementar autenticación y encriptación mutuas para cargas de trabajo, usa istio auth. En el caso específico de una carga de trabajo en Kubernetes, la autenticación de Istio permite que una CA a nivel de clúster genere y distribuya certificados que luego se usarán para la seguridad de la capa de transporte mutua (mTLS) entre pods.

Cómo ayuda Google a Internet a encriptar datos en tránsito

En las secciones sobre encriptación en tránsito de manera predeterminada y las opciones configurables por el usuario para la encriptación en tránsito, se explicaron las protecciones predeterminadas y personalizables con las que cuenta Google Cloud para los datos en tránsito de los clientes. Además, Google tiene diversos proyectos de código abierto y otras iniciativas que fomentan el uso de la encriptación en tránsito y la seguridad de datos en Internet a gran escala.

Certificado de transparencia

Como se explica en Encriptación del usuario al Google Front End, antes de ofrecer HTTPS, un sitio debe solicitar un certificado de una autoridad certificada (CA) web (pública) de confianza. La autoridad certificada es responsable de verificar que quien realiza la solicitud cuente con la autorización del titular del dominio y también debe cerciorarse de que cualquier otra información incluida en el certificado sea correcta. Luego, este certificado se presenta al navegador para autenticar el sitio al cual el usuario intenta acceder. A fin de asegurar que HTTPS esté autenticado adecuadamente, es importante garantizar que las CA solo emitan certificados que estén autorizados por el titular del dominio.

El Certificado de transparencia (CT) es una iniciativa que Google lanzó en marzo de 2013 para que los operadores de sitios y titulares de dominios puedan detectar si una CA emitió certificados incorrectos o no autorizados. Funciona mediante un mecanismo para que los titulares de dominios, las CA y el público ingresen los certificados de confianza que vean (o en el caso de las CA, los certificados que emitan) en registros inalterables, que solo permitan anexar contenido y que sean comprobables públicamente. Cualquiera puede examinar los certificados en estos registros para asegurarse de que la información sea correcta y exacta, y esté autorizada.

La primera versión del Certificado de transparencia se especificó en una RFC experimental de la IETF, RFC 6962. Durante el desarrollo del Certificado de transparencia, Google proporcionó varias herramientas de código abierto, entre ellas un servidor de registros de código abierto que registra certificados, así como herramientas para crear registros de Certificado de transparencia. Además, Google Chrome requiere que algunos certificados cuenten con divulgación pública. Esto sucede, por ejemplo, con los certificados de validación extendida (EV) o los provenientes de CA que hayan emitido certificados de manera inapropiada en el pasado. A partir de 2018, Chrome exige la divulgación de todos los certificados nuevos de confianza pública.

Como operador de un sitio, puedes usar el Certificado de transparencia a fin de detectar si se emitieron certificados no autorizados para tu sitio web. Existen varias herramientas gratuitas para facilitar este proceso, como el Informe de Certificado de transparencia de Google, el Certificado de búsqueda o las herramientas de Facebook. Incluso si no usas un Certificado de transparencia, varios navegadores lo examinan con regularidad para asegurarse de que las CA en las que confían tus usuarios para acceder a tu sitio web cumplan con los requisitos y las prácticas recomendadas de la industria, lo cual reduce el riesgo de que se emitan certificados fraudulentos.

Aumento del uso de HTTPS

Como se explica en Encriptación del usuario al Google Front End, nos esforzamos para asegurarnos de que nuestros sitios y servicios proporcionen el HTTPS moderno de forma predeterminada. Nuestra meta es lograr un 100% de encriptación en todos nuestros productos y servicios. Para ello, publicamos un Informe de transparencia HTTPS anual que hace un seguimiento de nuestros avances hacia nuestra meta en todas nuestras propiedades, incluido Google Cloud. Seguimos trabajando a fin de superar las barreras técnicas que dificultan la compatibilidad con la encriptación en algunos de nuestros productos, por ejemplo, soluciones para otros clientes o navegadores que no admiten el protocolo HTTP con Seguridad de Transporte Estricta (HSTS)18. Usamos HSTS en algunos de nuestros sitios, incluida la página principal de google.com, para permitir a los usuarios conectarse a un servidor solamente a través de HTTPS.

Sabemos que el resto de Internet está trabajando en la transición a HTTPS. Intentamos facilitar este cambio de las siguientes maneras:

En 2016 comenzamos a publicar métricas sobre "el uso de HTTPS en Internet" para los 100 principales sitios fuera de Google en Internet. Con estas métricas, nuestro objetivo es crear conciencia y ayudar a que Internet sea un lugar más seguro para todos los usuarios. En octubre de 2017, Chrome renovó formalmente su apoyo financiero a Let’s Encrypt como patrocinador Platino.

Aumento del uso de SMTP seguro: indicadores de Gmail

La mayor parte del correo electrónico se intercambia usando el protocolo para transferencia simple de correo (SMTP) que, de manera predeterminada, envía correo electrónico sin encriptación. Para encriptar un correo electrónico, el proveedor de correo electrónico debe implementar controles de seguridad como la TLS.

Como se indica en Encriptación del usuario al Google Front End, Gmail usa TLS de forma predeterminada. Además, en la sección sobre cómo requerir TLS en Gmail, se describe la forma en que los administradores de Gmail pueden hacer obligatorio el uso de la protección de TLS para los correos electrónicos entrantes y salientes. Al igual que los esfuerzos de Google con la transparencia de HTTPS, Gmail proporciona datos sobre el uso de TLS para el correo electrónico que ingresa a Gmail. Estos datos se presentan en nuestro Informe de transparencia sobre correos electrónicos más seguros.

Google, en asociación con la IETF y otros miembros clave de la industria, lidera el desarrollo de SMTP STS. SMTP STS es el equivalente al HSTS para HTTPS, que obliga a usar SMTP en vez de canales encriptados solamente.

API de Chrome

En febrero de 2015, Chrome anunció que habría funciones nuevas y potentes que estarían disponibles solo para los orígenes seguros.19 Estas características incluyen el manejo de información privada y el acceso a los sensores del dispositivo de un usuario. Comenzando por la ubicación geográfica en Chrome 50, empezamos a dar de baja estas características para los orígenes inseguros.

Innovación constante en la encriptación en tránsito

Experiencia del usuario en cuanto a la seguridad de Chrome

Google Chrome es un líder del sector en cuanto al aprovechamiento de su IU para mostrar información sobre seguridad de modo que los usuarios comprendan rápidamente la seguridad de su conexión a un sitio. Con esta información, los usuarios pueden tomar decisiones fundamentadas sobre cuándo y cómo comparten sus datos. Chrome realiza una extensa investigación de los usuarios, cuyos resultados se comparten en informes revisados por colegas.

A fin de proteger aún más a sus usuarios, Chrome anunció que, para fines del año 2017, marcaría todas las conexiones HTTP como no seguras. A partir de Chrome 56 y de manera predeterminada, los usuarios verán una advertencia si una página HTTP incluye un formulario con contraseña o campos para tarjetas de crédito. A partir de Chrome 62, se mostrará una advertencia cuando un usuario ingrese datos en una página HTTP y para todas las páginas HTTP visitadas en modo Incógnito. Con el tiempo, Chrome mostrará una advertencia para todas las páginas que usen HTTP.

Para ver cómo se muestra cada configuración a los usuarios de Chrome, usa la herramienta BadSSL.

Key Transparency

Un freno importante a la adopción generalizada de la encriptación de mensajes es la dificultad del intercambio de claves públicas: ¿cómo puedo encontrar de manera confiable la clave pública de un usuario nuevo con el que me estoy comunicando? Para ayudar a resolver este problema, Google anunció Key Transparency en enero de 2017. Este es un framework abierto que ofrece un modo genérico, seguro y auditable de distribución de claves públicas. El framework elimina la necesidad de que los usuarios realicen una verificación de claves manual. Key Transparency está dirigida principalmente a la distribución de claves públicas de usuarios en las comunicaciones; por ejemplo, la encriptación de correo electrónico OpenPGP y de extremo a extremo. El diseño de Key Transparency es un enfoque nuevo para la recuperación y distribución de claves y se basa en la información útil obtenida mediante el Certificado de transparencia y CONIKS.

El desarrollo de Key Transparency es de código abierto y se implementa mediante un árbol Merkle de gran escala. La verificación de Key Transparency permite a los propietarios de cuentas ver qué claves se asociaron a sus cuentas y por cuánto tiempo una cuenta se ha mantenido activa y estable El objetivo a largo plazo del trabajo de Key Transparency de Google es permitir a cualquier persona ejecutar un servidor de Key Transparency y facilitar su integración en todo tipo de aplicaciones.

Criptografía poscuántica

Google pretende seguir siendo el líder de la industria de encriptación en tránsito. Para ello, comenzamos a trabajar en el área de la criptografía poscuántica. Este tipo de criptografía nos permite reemplazar los primitivos criptográficos existentes, que son vulnerables a los ataques cuánticos eficientes, por candidatos poscuánticos que se consideran más resistentes. En julio de 2016, anunciamos que realizaríamos un experimento sobre la viabilidad de implementar un algoritmo de este tipo mediante el algoritmo criptográfico poscuántico New Hope en la versión para desarrolladores de Chrome. Además de este trabajo, los investigadores de Google publicaron informes sobre otros protocolos prácticos de intercambio de claves poscuánticas.

Apéndice

Obtén más información acerca de la seguridad en Google Cloud, incluida nuestra descripción general del diseño de seguridad de la infraestructura, además del cumplimiento de Google Cloud y el informe de auditoría SOC 3.

Pies de página

1 Las soluciones de socios incluyen soluciones en Cloud Launcher y productos creados en colaboración con otros socios, como Cloud Dataprep.
2 Aún puedes inhabilitar esta encriptación, por ejemplo, para el acceso HTTP a los depósitos de Google Cloud Storage.
3 Las comunicaciones de VM a un servicio sin protección en la capa 7 siguen protegidas en las capas 3 y 4.
4 TLS 1.3 aún no está finalizado. La versión en borrador se implementa solo para hacer pruebas en dominios de Google determinados, como Gmail.
5 Google admite TLS 1.0 para los navegadores que aún usan esta versión del protocolo. Ten en cuenta que cualquier sitio de Google que procese información de tarjetas de crédito dejará de admitir TLS 1.0 a partir de julio de 2018, cuando el cumplimiento de Payment Card Industry (PCI) requiera darlo de baja.
6 Para obtener detalles sobre QUIC, consulta [https://www.chromium.org/quic](https://www.chromium.org/quic).
7, 8, 9 A fin de mantener la retrocompatibilidad con algunos sistemas operativos heredados, admitimos 3DES, SHA1 y MD5.
10 En el caso de certificados en cadena, se confía en la CA de forma transitiva.
11 Esto puede ser una solicitud de sesión ([RFC 5077](https://tools.ietf.org/html/rfc5077)) o un ID de sesión ([RFC 5246](https://tools.ietf.org/html/rfc5246)).
12 El plano de control es la parte de la red que lleva el tráfico indicador y es responsable del enrutamiento.
13 Antes se usaban otros protocolos, pero se encuentran obsoletos. Menos del 1% de los trabajos usan estos protocolos antiguos.
14 Datagram TLS (DTLS) brinda seguridad a las aplicaciones basadas en Datagram, ya que permite la comunicación de un modo que impide el espionaje y las alteraciones.
15 El intercambio de claves por Internet (IKE) es el protocolo que se usa para configurar una asociación de seguridad en el conjunto de protocolos de IPsec.
16 HMAC-SHA-1 no se rompe con una [colisión SHA-1](https://shattered.io/), como la colisión SHAttered que descubrieron los investigadores de Google.
17 En el caso de G Suite Enterprise, esto no aparece en la IU. Los administradores de dominios pueden examinar los datos de su dominio con la [Búsqueda en el registro de correo electrónico](https://support.google.com/a/answer/2604578).
18 El HTTP con Seguridad de Transporte Estricta (HSTS) es un mecanismo que permite que los sitios web se declaren accesibles solo a través de conexiones seguras o que los usuarios puedan dirigir a su usuario-agente para interactuar con sitios determinados solo a través de conexiones seguras.
19 Los orígenes seguros son conexiones que coinciden con [patrones](https://www.chromium.org/Home/chromium-security/prefer-secure-origins-for-powerful-new-features) determinados de esquema, host o puerto.