Encriptación en tránsito en Google Cloud

Este es el tercer informe técnico acerca de cómo Google usa la encriptación para proteger tus datos. También publicamos los informes Encriptación en reposo en Google Cloud Platform y Encriptación en G Suite. Recomendamos leer estos otros documentos para obtener más información acerca del uso de la encriptación en Google. En este informe técnico, encontrará 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, ya que mejoramos la protección de nuestros clientes de forma continua.

Botón para reproducir

Encriptación en tránsito de Google Cloud

Resumen a nivel del director de sistemas 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 que Google no controla o que se transfieren en su nombre. En general, los datos en tránsito dentro de un límite físico controlado por Google o en nombre de Google se autentican, pero no necesariamente se encriptan.
  • Dependiendo de 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 Google Front End (GFE) mediante 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 entre máquinas virtuales. Estas protecciones incluyen túneles IPsec, S/MIME de Gmail, Istio y certificados SSL administrados.
  • Google trabaja activamente con la industria para que todas las personas, en todos los lugares, 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 en encriptación en tránsito. A fin de lograrlo, dedicamos recursos para el desarrollo y la implementación de 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

A menudo, la seguridad es un factor decisivo en el 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, transfiriéndose dentro de la infraestructura de Google o almacenados en nuestros servidores.

La autenticación, la integración y la encriptación de datos, tanto en reposo como 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 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 CISO que usan o piensan usar Google Cloud.

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

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 sin formato) en datos ilegibles (texto cifrado), a fin de garantizar que solo las partes de los datos autorizadas por el propietario 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 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 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 ataques 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. El resto de este informe 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 nombre de Google. Un límite físico es la barrera de un espacio físico controlado por Google o en nombre de Google 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, los datos en tránsito dentro de estos límites físicos se autentican, 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 nombre de Google. 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. Esta sección describe cómo las solicitudes van desde un usuario final hasta el servicio de Google Cloud o 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, estadísticas 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 usando Google App Engine, Google Kubernetes Engine o una VM en Google Compute Engine es una aplicación de cliente.

La Figura 1 muestra los cinco tipos de solicitudes de enrutamiento que se analizan a continuación. Esta figura muestra las interacciones entre los diversos componentes de red y la seguridad aplicada a cada conexión.

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). GFE finaliza el tráfico de proxy entrante de HTTP(S), TCP y TLS, ofrece respuestas a los ataques DSD y enruta y balancea la carga del tráfico a los propios servicios de Google Cloud. Existen puntos de presencia de 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 tecnología de red a un servicio de Google Cloud. Esta conexión se autentica y encripta desde 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 nombre de Google. La Figura 1 muestra esta interacción (conexión A).

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. La Figura 1 muestra esta interacción (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 autorizar, enrutar y distribuir este tráfico a sus VM. Los GFE implementan estos servicios de balanceo de cargas y también finalizan y enrutan el tráfico de los servicios de Google Cloud. Cuando el GCLB enruta el tráfico entre los GFE, las conexiones se autentican y se encriptan cuando el tráfico sale de un límite físico controlado por Google o en su nombre. 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 y encripta cuando sale de un límite físico controlado por Google o en su nombre. En el caso de los balanceadores de cargas HTTPS, las conexiones entre los usuarios finales y 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 GFE no se encriptan ni autentican. En el caso de los balanceadores de cargas SSL, las conexiones entre los usuarios finales y GFE se encriptan con TLS y, de manera similar, usan certificados proporcionados por los clientes. En el caso de los balanceadores de carga TCP, no hay encriptación entre el usuario final y 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 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 GFE. Esta conexión no se encripta de manera 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 va desde/hasta tu host local, a la VPN local, a la VPN de Google y a la VM de Google Cloud. La conexión no pasa por GFE. 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 te estás conectando a través de una interconexión dedicada, la conexión va directamente desde/hasta tu host local y no pasa por GFE. Esta conexión no se encripta de manera 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 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 nombre de Google. 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 manera predeterminada y su seguridad se proporciona a discreción del usuario. La Figura 1 muestra esta interacción (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). 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 de 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 es 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 TLS.2 Esta protección se aplica desde la VM hasta GFE. La conexión se autentica desde 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 nombre de Google. 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 manera 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 opcional en las capas 3 y 4 en Google Cloud

Figura 3: Protección predeterminada y opcional en la Capa 7 en Google Cloud3

El resto de esta sección describe las protecciones predeterminadas que Google usa para proteger los datos en tránsito.

Encriptación de usuario a Google Front End

Actualmente, muchos sistemas usan el protocolo 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) al demostrar 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 usuario y 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 de GFE; en particular, 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 a GFE se encriptan en tránsito mediante Seguridad de la capa de transporte (TLS) o QUIC. GFE negocia un protocolo de encriptación determinado con el cliente en función de lo que el cliente puede admitir. Cuando es posible, GFE negocia protocolos de encriptación más modernos.

La encriptación TLS en escala de 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 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 Requerir TLS en Gmail).

Google es líder del sector tanto en la adopción de TLS como en el fortalecimiento de su implementación. Para ello, habilitamos de manera predeterminada muchas de las características de seguridad de TLS. Por ejemplo, usamos desde el año 2011 la confidencialidad directa en nuestra implementación de TLS. 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 derivó a BoringSSL desde OpenSSL con el objeto de simplificar OpenSSL para el uso interno y 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.

TLS se implementa en GFE con BoringSSL. La Tabla 1 muestra los protocolos de encriptación compatibles con GFE cuando 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 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 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 al hacer 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 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 vaya según los planes. 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 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 los certificados se rotan aproximadamente cada dos semanas.

Un cliente que se conectó anteriormente a un servidor puede usar una clave de ticket privada11 para reanudar una sesión previa con un protocolo de enlace TLS abreviado, por lo que estos tickets son muy valiosos para un atacante. Google rota las claves de tickets al menos una vez al día y caduca las claves de todas las propiedades cada 3 días. Para obtener más información sobre la rotación de claves de tickets de sesión, consulta Medición del peligro a la seguridad de los accesos directos criptográficos de TLS.

Google Front End a frontends de aplicaciones

En algunos casos, como se explicó 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 seguridad de transporte de la capa de la aplicación (ALTS), que 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 manera predeterminada. En el caso de aplicaciones de cliente alojadas en Google Cloud, si el tráfico se enruta mediante Google Front End (por ejemplo, si usan el balanceador de cargas de Google Cloud), el tráfico a la VM se protege usando 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 o en nombre de Google puede estar expuesta a un adversario activo que puede husmear, inyectar o alterar el tráfico en curso. Para garantizar la integridad y la 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 VM. Esta autenticación se realiza mediante tokens de seguridad y protege a un host vulnerable contra paquetes de falsificación de identidad 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 nombre de Google. 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 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 (la capa 7) para la autenticación, integridad y encriptación de las llamadas de RPC de Google desde GFE a un servicio y entre servicios.

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 envían o reciben RPC de otros servicios, un servicio usa sus credenciales para autenticarse. ALTS verifica estas credenciales mediante una autoridad certificada interna.

En un límite físico controlado por Google o en nombre de Google, 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 nombre de Google, 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.

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 Google Front End al 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 nombre de Google. 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

ALTS tiene un protocolo de enlace seguro similar al TLS mutuo. Dos servicios que desean comunicarse usando 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 la 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, ALTS usa cuentas de servicio para la autenticación, con cada servicio que se ejecuta en la infraestructura de Google ejecutándose 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 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 se relaciona y es independiente de nuestra CA externa.

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 una VMAC en vez de una 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 Google Front End. Describimos esas comunicaciones en Encriptación de máquina virtual a Google Front End.

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

El tráfico de VM a GFE usa IP externas para alcanzar a 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 a GFE. La conexión se realiza del mismo modo que cualquier otra conexión externa. Para obtener más información sobre TLS, consulta Seguridad de la capa de transporte (TLS).

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

Encriptación en tránsito describe las protecciones predeterminadas que Google aplica a los datos en tránsito. Esta sección describe las configuraciones que pueden efectuar nuestros usuarios para estas protecciones predeterminadas.

Centro de datos local a Google Cloud

TLS usando balanceadores de cargas GCLB externos

Si tu servicio de nube usa un balanceador de cargas externo de Google HTTPS o de proxy SSL, GFE finaliza las conexiones TLS de los usuarios que usan certificados SSL que aprovisionas y controlas. Para obtener más información sobre la personalización de tu certificado, consulta nuestra documentación sobre certificados SSL.

Túnel IPsec usando la VPN de Google Cloud

Como cliente de Google Cloud, puedes usar la VPN de Google Cloud 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 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. La VPN de Google Cloud protege tus datos de las siguientes maneras:

  • Los paquetes desde tus VM hasta la VPN de Cloud 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 la VPN de Cloud 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 VPN de Cloud 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 cifrados diferentes. Si especificas IKEv1, Google encriptará los paquetes mediante AES-128-CBC y brindará integridad a través de SHA-1 HMAC16. En el caso de IKEv2, diversos cifrados están disponibles y son compatibles. En todos los casos, la VPN de Google Cloud negociará el protocolo común más seguro que sea compatible con los dispositivos de intercambio de tráfico. Encontrarás las instrucciones detalladas para configurar una VPN en nuestra documentación 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, TLS. La VPN de Google Cloud 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.

Usuario a 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 de GFE con TLS. Por ejemplo, puedes hacer que la sesión TLS finalice en tu aplicación. Esta finalización es distinta a la finalización de TLS descrita en TLS con balanceadores de cargas GCLB externos

Google también ofrece certificados SSL gratuitos y automatizados en los dominios personalizados 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 protocolo de transporte estricto HTTPS (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 2048 bits o secp256r1 ECC, y renovaremos los certificados en nombre de nuestros clientes.

Requerir TLS en Gmail

Como se indicó en Seguridad de la capa de transporte, Gmail usa TLS de manera 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 un usuario de Gmail intercambia un correo electrónico con otro usuario de Gmail, TLS protege los correos o, en algunos casos, se envían directamente en la aplicación. En estos casos, ALTS protege los RPC que usa la aplicación de Gmail según se describió en Autenticación, integridad y encriptación entre servicios. En el caso de los mensajes entrantes de otros proveedores de correo electrónico, Gmail no aplica TLS de manera forzosa. Los administradores de Gmail pueden configurar Gmail para que requiera 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 obliga a los certificados asociados con los usuarios que envían correos electrónicos a alojarse en una CA pública.

Como administrador, puedes configurar Gmail para habilitar S/MIME en 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 servicio de código abierto desarrollada por Google, IBM y Lyft, entre otros, para simplificar el descubrimiento y la conexión 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, Istio Auth permite que una CA a nivel de clúster genere y distribuya certificados, los que luego se usarán para la seguridad mutua de la capa de transporte (mTLS) entre pods.

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

En Encriptación en tránsito de manera predeterminada y 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 explicó en Encriptación de usuario a Google Front End, para ofrecer HTTPS, un sitio debe primero postularse a un certificado de una autoridad certificada (CA) web (pública) de confianza. La autoridad certificada es responsable de verificar que el postulante esté autorizado por el titular del dominio y de garantizar que cualquier otro tipo de información incluida en el certificado sea exacta.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 el titular del dominio haya autorizado.

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, 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 sean de divulgación pública, como los certificados de validación extendida (EV) o los certificados emitidos por CA que hayan emitido certificados de manera inapropiada en el pasado. A partir del año 2018, Chrome requerirá que se divulguen todos los nuevos certificados de confianza pública.

Como operador del 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 esta labor, como el Informe de Certificado de transparencia de Google, Certificate Search 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 recomendaciones de la industria, lo cual reduce el riesgo de emisiones de certificados fraudulentos.

Aumento del uso de HTTPS

Como se explicó en Encriptación de usuario a Google Front End, nos esforzamos para asegurarnos de que nuestros sitios y servicios proporcionen HTTPS moderno de manera 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 de transporte estricto HTTPS (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 trabaja para moverse a HTTPS. Intentamos facilitar este movimiento de las siguientes maneras:

El año 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 TLS.

Como se explicó en Encriptación de usuario a Google Front End, Gmail usa TLS de manera predeterminada. Además, Requerir TLS en Gmail describe cómo los administradores de Gmail pueden forzar el uso de la protección de TLS para 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. Mostramos estos datos 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 poderosas disponibles solo para 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 con la ubicación geográfica en Chrome 50, empezamos a dar de baja a estas funciones debido a sus orígenes inseguros.

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

Experiencia del usuario de 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 de navegación incógnito. Con el tiempo, Chrome mostrará una advertencia para todas las páginas que utilicen 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 marco de trabajo abierto que ofrece un modo genérico, seguro y auditable de distribución de claves públicas. El marco de trabajo 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 nuevo enfoque de la recuperación y distribución de claves, y se basa en la información valiosa obtenida del Certificado de transparencia y de 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 en 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 criptográficas primitivas y vulnerables a los ataques cuánticos eficientes con candidatas poscuánticas que supuestamente son más sólidas. En julio de 2016, anunciamos que realizamos un experimento sobre la viabilidad de implementar este algoritmo 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 han publicado 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, así como el cumplimiento de Google Cloud y el informe público de auditoría SOC 3.

Pies de página

1 Las soluciones de socios incluyen tanto soluciones en Cloud Launcher como productos creados en colaboración con otros socios, como Cloud Dataprep.
2 Aún puedes inhabilitar esta encriptación, por ejemplo, para acceso HTTP a los depósitos de Google Cloud Storage.
3 Las comunicaciones de VM a 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 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 En el caso de 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 modo transitivo.
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 dieron de baja. Menos del 1% de los trabajos usa estos protocolos antiguos.
14 Datagram TLS (DTLS) brinda seguridad a las aplicaciones basadas en Datagram, ya que permiten la comunicación de un modo que impida el espionaje y las alteraciones.
15 Intercambio de claves por Internet (IKE) es el protocolo que se usa para configurar una asociación de seguridad en la suite de protocolos de IPsec.
16 HMAC-SHA-1 no se rompe por 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 se muestra en la IU. Los administradores de dominios pueden examinar los datos de su dominio usando la [Búsqueda en el registro de correo electrónico](https://support.google.com/a/answer/2604578).
18 El protocolo de transporte estricto HTTPS es un mecanismo que permite a los sitios web declararse accesibles solo a través de conexiones seguras o para que los usuarios puedan dirigir a su usuario-agente a fin de 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.
¿Te sirvió esta página? Envíanos tu opinión:

Enviar comentarios sobre…