Encriptado en tránsito en Google Cloud

En este tercer informe, hablaremos de la forma en que Google encripta los datos para protegerlos. En concreto, hablaremos sobre el encriptado en tránsito de las soluciones de Google Cloud, incluidas Google Cloud Platform y G Suite.

En Google, nos esforzamos por proteger los datos de los clientes de todos nuestros productos y por actuar con transparencia en todo momento.

El contenido incluido en este documento está actualizado a diciembre del 2017 y representa la situación en el momento en que se redactó. Es posible que los sistemas y las políticas de seguridad de Google Cloud cambien a medida que mejoramos la protección de nuestros clientes.

Botón de reproducción

Encriptado en tránsito de Google Cloud

Resumen para directores de sistemas de información

  • Google cuenta con diversos sistemas de seguridad para preservar la autenticidad, la integridad y la privacidad de los datos en tránsito.
  • En Google se encriptan y autentican todos los datos en tránsito en una o más capas de la red cuando estos salen de los límites físicos no controlados por Google o en su nombre. Los datos en tránsito que se encuentran dentro de un límite físico controlado por Google o en su nombre suelen estar autenticados, pero no necesariamente encriptados.
  • En función del tipo de conexión establecida, Google aplica una serie de protecciones predeterminadas a los datos en tránsito. Por ejemplo, para proteger las comunicaciones entre los usuarios y Google Front End (GFE), se utiliza el protocolo TLS.
  • Los clientes de Google Cloud con otros requisitos relacionados con el encriptado de datos a través de una red WAN pueden implementar otras soluciones para proteger los datos mientras se transfieren de los usuarios a las aplicaciones, o entre máquinas virtuales. Entre estas medidas se incluyen: los túneles IPSec, la API Gmail S/MIME, los certificados SSL gestionados e Istio.
  • En Google colaboramos estrechamente con otros especialistas del sector para encriptar los datos en tránsito de todos los usuarios, independientemente de dónde se encuentren. En concreto, tenemos en marcha varios proyectos de software libre para fomentar el encriptado de datos en tránsito y salvaguardarlos en Internet a gran escala, como la iniciativa de transparencia en los certificados, las API de Chrome y el protocolo SMTP seguro.
  • Google se propone seguir siendo el líder del sector en el encriptado de los datos en tránsito. Para ello, contamos con recursos dedicados a desarrollar y mejorar las tecnologías de este tipo, y con planes de innovación en áreas tales como la transparencia de claves y la criptografía poscuántica.

Introducción

A la hora de decantarse por un proveedor de nube pública, la seguridad suele ser un factor clave. Para nosotros, es de máxima importancia: trabajamos constantemente para que tus datos estén protegidos en todo momento, tanto cuando se transfieren por Internet como cuando circulan por nuestra infraestructura o simplemente están almacenados en nuestros servidores.

Los cimientos de nuestra estrategia de seguridad son la autenticación, la integridad y el encriptado de los datos, independientemente de si están en reposo o en tránsito. En este informe, hablaremos del modelo de encriptado de datos en tránsito que utilizamos en Google Cloud.

Si te interesan más los datos en reposo, consulta el informe Encriptado en reposo en Google Cloud Platform. O bien, si prefieres hacerte una idea general de cómo funcionan nuestros sistemas de seguridad, puedes leer la descripción general del diseño de la seguridad de la infraestructura de Google.

Audiencia: este documento está dirigido a los directores de seguridad de la información (o CISO) y a los equipos de operaciones de seguridad que usan o se plantean utilizar Google Cloud.

Requisitos previos: además de leer esta introducción, se presupone que el lector tiene conocimientos básicos sobre el encriptado y las primitivas criptográficas.

Autenticación, integridad y encriptado

Google cuenta con diversos sistemas de seguridad para preservar la autenticidad, la integridad y la privacidad de los datos en tránsito.

  • Autenticación: verificamos la fuente de datos (es decir, si procede de un sistema manual o automático) y el destino.
  • Integridad: nos aseguramos de que los datos llegan a su destino sin sufrir ningún cambio.
  • Encriptado: tus datos serán ininteligibles (y, por tanto, privados) durante toda la fase de tránsito. Al utilizar el encriptado, los datos legibles (texto sin formato) se transforman en ininteligibles (texto cifrado), con lo que nos aseguramos de que solo pueden acceder a ellos los usuarios a los que haya autorizado el propietario. Los algoritmos que utilizamos en el proceso de encriptado son públicos, pero la clave usada para desencriptar el texto cifrado, no. Para encriptar datos en tránsito solemos utilizar claves simétricas compartidas. Para ello, recurrimos a un proceso llamado "intercambio de claves asimétricas", como es el caso del protocolo Diffie-Hellman, que está basado en curvas elípticas. Si quieres obtener más información sobre el encriptado, te recomendamos que leas este libro a modo de introducción a la criptografía moderna.

Puedes recurrir al encriptado para proteger datos mientras están en estos tres estados:

  • En reposo: los datos se protegen frente a intrusiones en el sistema y filtraciones externas, ya que se encriptan mientras están almacenados. El estándar que más se suele utilizar para encriptar datos de este tipo es el estándar de encriptado avanzado (AES, por sus siglas en inglés).
  • En tránsito: tiene lugar si se intercepta algún tipo de comunicación mientras se transfieren datos entre tu sitio web y el proveedor de servicios en la nube, o entre dos servicios. Para proteger dichos datos, se encriptan antes de que tenga lugar la transmisión. A continuación, se autentican los puntos de conexión y, por último, se verifican los datos cuando llegan a su destino. Por ejemplo, se utiliza el protocolo de seguridad en la capa de transporte (TLS) para preservar la seguridad de los datos mientras se transportan, y las extensiones seguras multipropósito de correo de Internet (S/MIME) sirven para proteger los correos electrónicos.
  • En uso: los datos se protegen mientras se utilizan en servidores para ejecutar cálculos. Un proceso de este tipo sería el encriptado homomórfico.

El encriptado debe entenderse como un elemento más de los que componen cualquier estrategia de seguridad más amplia. Al implementar este proceso en los datos en tránsito, es posible protegerlos frente a atacantes potenciales en el momento en el que se establece y autentica una conexión. Gracias al encriptado, se consigue lo siguiente:

  • Evitar tener que depender de las capas inferiores de la red, que habitualmente suministran otras empresas.
  • Reducir la superficie de posibles ataques.
  • Impedir que los atacantes puedan acceder a los datos, en caso de que se interceptaran las comunicaciones.

Para proteger los datos que circulan entre usuarios, dispositivos o procesos en entornos hostiles, te recomendamos poner en marcha las estrategias de autenticación, integridad y encriptado más adecuadas. En el resto de este documento te explicaremos en qué consiste nuestro sistema de encriptado de datos en tránsito y en qué casos se implementa.

Infraestructura de red de Google

Límites físicos de las redes de nube privada virtual

Cuando los datos en tránsito se transmiten fuera de la red controlada por nosotros o en nuestro nombre, ponemos en marcha distintos sistemas de protección. Cuando hablamos de "límites físicos", nos referimos a la frontera del espacio físico que conforma dicha red. En este espacio, sabemos con total seguridad que se están aplicando unas medidas de seguridad más que estrictas. El acceso físico a dichas ubicaciones está restringido y monitorizado de cerca. De hecho, el número de empleados de Google que tienen acceso a este hardware es bastante reducido. Por lo general, los datos en tránsito que circulan dentro de este espacio físico se autentican, pero no se encriptan de forma predeterminada. Tú eres quien decide las medidas de seguridad que quieres adoptar, en función de cuál sea tu modelo de protección contra amenazas.

Internet es una red de enorme magnitud, y no podemos fijar estos mismos controles en los enlaces de fibra óptica de nuestra WAN ni en ninguna otra ubicación que esté más allá de los confines de nuestra infraestructura física. Lo que sí hacemos es imponer medidas de seguridad adicionales fuera de nuestra zona física de confianza, como el encriptado de datos en tránsito.

¿Cómo se enruta el tráfico?

En la sección anterior hemos visto cuáles son los límites físicos de las redes de VPC y qué medidas de seguridad aplicamos a los datos que salen de sus fronteras. Para entender mejor en qué consiste el sistema de encriptado de datos en tránsito de Google, es necesario saber cómo se enruta el tráfico por Internet. En esta sección, descubrirás cómo se transfieren las solicitudes de los usuarios finales al servicio de Google Cloud o la aplicación de cliente correspondiente y cómo se enruta el tráfico entre servicios.

Un servicio de Google Cloud es un servicio modular en la nube que ofrecemos a nuestros clientes: soluciones informáticas, de almacenamiento de datos, de análisis de datos y de aprendizaje automático. Por ejemplo, tanto Google Cloud Storage como Gmail son servicios de Google Cloud. Las aplicaciones de clientes se alojan en Google Cloud y nuestros clientes pueden crearlas y desplegarlas mediante los servicios de Google Cloud. Las aplicaciones de clientes o soluciones de partners que estén alojadas en Google Cloud no se considerarán servicios de Google Cloud.1 Estos son algunos ejemplos de aplicaciones que sí son de cliente: aplicaciones creadas en Google App Engine o Google Kubernetes Engine, o máquinas virtuales creadas en Google Compute Engine.

En la figura 1 aparecen representados los cinco tipos de solicitudes de enrutamiento que trataremos a continuación, así como las interacciones entre los diversos componentes de red y las medidas de seguridad aplicadas a cada conexión.

Entre el usuario final (Internet) y un servicio de Google Cloud

Los servicios de Google Cloud aceptan solicitudes de todo el mundo mediante el sistema Google Front End (GFE), distribuido globalmente. GFE cancela el tráfico de proxy HTTP(S), TCP y TLS entrante, proporciona medidas de respuesta a los ataques DDoS y enruta y equilibra la carga de tráfico que reciben los propios servicios de Google Cloud. Hay puntos de presencia de GFE en todo el mundo, y las rutas se anuncian mediante unicast o Anycast.

Los GFE dirigen el tráfico de proxy a los servicios de Google Cloud. Para ello, enrutan la solicitud del usuario por nuestra red troncal hasta un servicio de Google Cloud. Cuando los datos se transmiten fuera de los límites físicos controlados por nosotros o en nuestro nombre, esta conexión se autentica y encripta desde GFE hasta el frontend del servicio de Google Cloud o de la aplicación del cliente. En la figura 1 se muestra esta interacción (conexión A).

Entre el usuario final (Internet) y una aplicación de cliente alojada en Google Cloud

El tráfico de Internet se puede enrutar a la aplicación de cliente alojada en Google Cloud de varias formas según la configuración, como se explica más adelante. En la figura 1 se muestra esta interacción (conexión B).

Mediante un balanceador de carga externo de proxy TCP/SSL o HTTP(S) de Google Cloud

En el balanceo de carga HTTP(S), de proxy TCP y de proxy SSL, Google encripta automáticamente el tráfico entre los Google Front Ends (GFEs) y tus backends que se encuentren en Google Cloud.

Además de este encriptado a nivel de red, puedes usar un protocolo seguro (por ejemplo, SSL, HTTPS o HTTP/2 mediante TLS) como protocolo del servicio de backend tanto para los balanceadores de carga basados en GFEs como para Traffic Director y el balanceo de carga interno de tipo HTTP(S).

Cuando un balanceador de carga se conecta a tus backends mediante un protocolo de servicio de backend seguro, el GFE es el cliente SSL o HTTPS. De forma similar, cuando un proxy de cliente configurado mediante Traffic Director se conecta a tus backends usando un protocolo de servicio de backend seguro, el proxy es el cliente SSL o HTTPS.

Te recomendamos que utilices un protocolo seguro para conectarte a instancias de backend en los siguientes casos:

  • Cuando necesites una conexión auditable y encriptada del balanceador de carga (o de Traffic Director) a las instancias de backend.

  • Cuando el balanceador de carga se conecte a una instancia de backend que se encuentre fuera de Google Cloud (a través de un NEG de Internet). La comunicación con un backend de NEG de Internet puede transcurrir por la Internet pública. Cuando el balanceador de carga se conecta a un NEG de Internet, el certificado debe tener la firma de una autoridad de certificación (CA) pública y cumplir los requisitos de validación.

Para usar un protocolo seguro entre el balanceador de carga y tus backends, debes cumplir estos requisitos:

  • Debes configurar los servicios de backend de tu balanceador de carga para usar el protocolo SSL (TLS), HTTPS o HTTP/2.

  • En las instancias de backend, debes configurar el software para servir tráfico usando el mismo protocolo que el servicio de backend. Por ejemplo, si dicho servicio usa HTTPS, debes configurar tus instancias de backend para que usen HTTPS. Si usas el protocolo HTTP/2, tus backends deben usar TLS. Consulta la documentación de software de tu instancia de backend para ver instrucciones de configuración.

  • Debes instalar claves privadas y certificados en tus instancias de backend. No es necesario que esos certificados coincidan con el certificado SSL del balanceador de carga. Consulta la documentación de software de tu instancia de backend para ver instrucciones de instalación.

  • Debes configurar el software que se ejecuta en tus instancias de backend para que funcione como servidor SSL o HTTPS. Consulta la documentación de software de tu instancia de backend para ver instrucciones de configuración.

A la hora de usar grupos de instancias o backends de NEGs de zona, ten en cuenta lo siguiente:

  • Cuando un GFE inicia una sesión TLS en backends, ese GFE no usa la extensión de indicador del nombre de servidor (SNI).

  • Cuando un GFE se conecta a backends que se encuentran en Google Cloud, ese GFE acepta cualquier certificado que presenten tus backends. Los GFE no realizan ninguna validación de certificados. Por ejemplo, el certificado se trata como válido incluso en las siguientes circunstancias:

    • Si tiene una firma automática.
    • Si está firmado por una autoridad de certificación desconocida.
    • Si ha caducado o todavía no es válido.
    • Si los atributos CN y subjectAlternativeName no coinciden con un registro PTR de DNS o encabezado Host.

Mediante una conexión directa a una máquina virtual con una IP externa o la IP del balanceador de carga de red

Al establecer la conexión mediante la IP externa de la máquina virtual o mediante una IP con balanceo de carga de red, la conexión no pasa por el GFE ni se encripta de forma predeterminada, por lo que la seguridad queda en manos del usuario.

Mediante Cloud VPN

Las conexiones desde un host on-premise a una máquina virtual de Google Cloud mediante una VPN se establecen desde o hacia el host on-premise hasta la VPN on-premise, de ahí a la VPN de Google y, en última instancia, a la máquina virtual de Google Cloud, pero sin pasar por GFE. La conexión está protegida desde la VPN on-premise hasta la VPN de Google con IPSec, mientras que, desde la VPN de Google hasta la máquina virtual de Google Cloud, se autentica y encripta cuando abandona la infraestructura física controlada por nosotros o en nuestro nombre.

Mediante una interconexión dedicada de Cloud

En este caso, la conexión se establece directamente desde o hacia el host on-premise, sin pasar por GFE. Puesto que la conexión no se encripta de forma predeterminada, la seguridad queda en manos del usuario. Puedes usar el protocolo criptográfico Seguridad en la capa de transporte (TLS) en la capa 7 para encriptar el tráfico de la aplicaciones a través de una interconexión dedicada.

Entre máquinas virtuales

El enrutamiento entre máquinas virtuales tiene lugar en tu red de VPC dentro de la red de producción de Google mediante intervalos de subred de VPC. En este caso, puede ser necesario enrutar el tráfico fuera de la infraestructura controlada por Google o en su nombre. Estos son algunos ejemplos de enrutamiento entre máquinas virtuales:

  • Máquinas virtuales de Compute Engine que se envían solicitudes entre sí.
  • Una máquina virtual de cliente que se conecta a una máquina virtual administrada por Google, como Cloud SQL.

Las conexiones entre máquinas virtuales se encriptan si abandonan la infraestructura física, y se autentican dentro de esta. El tráfico entre estas máquinas mediante direcciones IP externas no se encripta de forma predeterminada, por lo que la seguridad queda en manos del usuario. En la figura 1 se muestra esta interacción (conexión C).

Conectividad con servicios y APIs de Google

La gestión del tráfico difiere según la ubicación del servicio de Google Cloud:

  • Aunque la mayoría de los servicios y de las API de Google se alojan en GFEs, algunos servicios se alojan en instancias gestionadas por Google. Por ejemplo, el acceso a servicios privados y las instancias maestras de GKE para clústeres privados se alojan en instancias gestionadas por Google.

    Gracias al Acceso privado de Google, las máquinas virtuales sin IP externas pueden acceder a servicios y APIs de Google admitidos, incluidas las aplicaciones de cliente alojadas en App Engine. Para obtener más información sobre el acceso a APIs y servicios de Google, consulta el artículo sobre las opciones de acceso privado a servicios.

  • Si una instancia de máquina virtual de Compute Engine se conecta a la dirección IP externa de otra instancia del mismo tipo, el tráfico permanece dentro de la red de producción de Google. El tráfico de los sistemas que se encuentran fuera de la red de producción de Google y se conectan a una dirección IP externa de una instancia de máquina virtual de Compute Engine se enruta a través de Internet.

    En la figura 1 se muestra una ruta externa (señalada con la conexión D). Algunos casos típicos de este tipo de solicitudes de enrutamiento son los siguientes:

    • De una máquina virtual de Compute Engine a Google Cloud Storage
    • De una máquina virtual de Compute Engine a una API de aprendizaje automático

Los servicios de Google Cloud utilizan el protocolo TLS de forma predeterminada para proteger las conexiones de máquina virtual a GFE.2. La conexión se autentica desde GFE hasta el servicio y se encripta si abandona nuestra infraestructura física.

Entre servicios de Google Cloud

El enrutamiento de un servicio de producción a otro tiene lugar en nuestra red troncal y puede ser necesario enrutar el tráfico fuera de los límites físicos controlados por Google o en nombre de Google. En la figura 1 se muestra esta interacción (conexión E). La activación de Google Cloud Functions mediante un evento de Google Cloud Storage es un ejemplo de este tipo de tráfico. Las conexiones entre los servicios de producción se encriptan si abandonan la infraestructura física, y se autentican dentro de esta.

El usuario se enruta a los servicios de Google Cloud en la infraestructura física usando el encriptado ALTS.

Figura 1: Protección predeterminada y opciones superpuestas en una red de VPC

Encriptado en tránsito de forma predeterminada

Para los datos en tránsito, Google usa varios métodos de encriptado, tanto predeterminados como personalizables. El tipo de encriptado depende de la capa OSI, el tipo de servicio y el componente físico de la infraestructura. En las figuras 2 y 3, a continuación, se muestran las protecciones opcionales y predeterminadas que aplica Google Cloud para las capas 3, 4 y 7.

Las opciones de encriptado para las capas 3 y 4 incluyen el tráfico de datos a la máquina virtual y en la infraestructura.

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

Las opciones de encriptado para la capa 7 incluyen los datos en tránsito entre las máquinas virtuales y los dirigidos a Google Front End.

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

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

Encriptado entre el usuario y Google Front End

En muchos sistemas actuales se usa el protocolo HTTPS para las comunicaciones a través de Internet. Se trata de una opción segura, ya que se dirige el protocolo a través de una conexión TLS, lo que garantiza la autenticidad, integridad y privacidad de las solicitudes y respuestas. Para aceptar solicitudes HTTPS, el receptor necesita un par de claves pública/privada y un certificado X.509, emitido por una autoridad de certificación (CA), para autenticar el servidor. El par de claves y el certificado ayudan a proteger las solicitudes del usuario en la capa de aplicación (capa 7) al demostrar que el receptor es propietario del nombre de dominio para el que están destinadas las solicitudes. En las siguientes subsecciones se abordan los componentes del encriptado desde el usuario a GFE: TLS, BoringSSL y la autoridad de certificación de Google. Recuerda que no todas las rutas del cliente pasan por GFE: en concreto, GFE se usa para el tráfico desde un usuario hasta un servicio de Google Cloud o hasta una aplicación de cliente alojada en Google Cloud que utilice Google Cloud Load Balancing.

Seguridad en la capa de transporte (TLS)

Cuando el usuario envía una solicitud a un servicio de Google Cloud, protegemos los datos en tránsito y ofrecemos autenticación, integridad y encriptado mediante el protocolo HTTPS con un certificado de una autoridad de certificación web pública. Todos los datos que el usuario envía a GFE se encriptan en tránsito con los protocolos Seguridad en la capa de transporte (TLS) o QUIC. GFE negocia un protocolo de encriptado concreto con el cliente según su compatibilidad, aunque, en la medida de lo posible, intenta utilizar protocolos de encriptado más modernos.

El encriptado TLS escalado 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 mediante TLS, como en el caso de Google Cloud. Además, nuestro encriptado TLS se utiliza en Gmail para intercambiar correos electrónicos con servidores de correo externos (para obtener más información, consulta Requerir que se use TLS en Gmail).

Google es una empresa líder del sector tanto en la adopción de TLS como en el refuerzo de su implementación. Para ello, hemos habilitado de forma predeterminada muchas de las funciones de seguridad de TLS; desde el 2011, por ejemplo, estamos usando la confidencialidad directa en nuestra implementación de TLS. Este protocolo evita que se persista en la clave que protege una conexión, de modo que el atacante que intercepta y lee un mensaje no puede leer los anteriores.

BoringSSL

BoringSSL es una implementación de software libre del protocolo TLS mantenida por Google y cuya interfaz es altamente compatible con OpenSSL. Google creó BoringSSL a partir de OpenSSL para simplificar este último, tanto para uso interno como para ofrecer una mejor compatibilidad con los Proyectos de Software Libre de Android y Chromium. BoringCrypto, el núcleo de BoringSSL, se ha validado según el estándar FIPS 140-2 de nivel 1.

TLS se implementa en GFE mediante BoringSSL. En la tabla 1 se muestran los protocolos de encriptado compatibles con GFE durante la comunicación con los clientes.

Protocolos Autenticación Intercambio de claves Encriptado Funciones 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: Encriptado implementado en Google Front End para los servicios de Google Cloud y en la biblioteca criptográfica de BoringSSL

Autoridad de certificación de Google

Como parte de TLS, los servidores tienen que demostrar su identidad al usuario al recibir una solicitud de conexión, por lo que deben presentar un certificado con la identidad que reclaman. Cuando se presenta el certificado, que incluye el nombre del host de DNS y la clave pública del servidor, lo firma la autoridad de certificación (CA) emisora, en la que confía el usuario que solicita la conexión.10 Como resultado, los usuarios que solicitan las conexiones al servidor solo tienen que confiar en la CA raíz. Si el servidor requiere un acceso ubicuo, los dispositivos del cliente de todo el mundo deben conocer la CA raíz. En la actualidad, la mayoría de los navegadores y otras implementaciones de clientes de TLS tienen su propio conjunto de CA raíces, que se configuran y almacenan como autoridades de certificación de confianza.

En el caso de Google, aunque antes contábamos con nuestra propia CA emisora, que se utilizaba para firmar certificados de dominios de Google, hasta ahora no disponíamos de nuestra propia CA raíz. Actualmente, nuestros certificados los firman varias CA raíces, distribuidas de forma ubicua, como Symantec (GeoTrust) y las raíces utilizadas previamente por GlobalSign (GS Root R2 y GS Root R4).

En junio del 2017, anunciamos que empezaríamos a usar nuestras propias CA raíces. Con el tiempo, queremos utilizar una CA raíz ubicua que emita certificados para 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 se modifican con frecuencia, ya que migrar a una nueva CA raíz requiere que todos los navegadores y dispositivos incorporen la confianza de ese certificado, lo que conlleva mucho tiempo. Como resultado, aunque Google ahora utiliza sus propias CA raíces, seguiremos confiando en varias CA raíces de terceros durante un periodo de transición para cubrir los dispositivos antiguos mientras migramos a las nuestras.

Para crear una nueva CA raíz se requiere una ceremonia de claves. En Google, la ceremonia exige que, como mínimo, tres de las seis personas autorizadas accedan físicamente a las claves de hardware almacenadas en un lugar seguro. Estas personas se reúnen en una sala específica, protegida frente a interferencias electromagnéticas y con un módulo de seguridad de hardware (HSM) con tecnología de aislamiento físico, para generar un conjunto de claves y certificados. Esta sala se encuentra en un lugar seguro en los centros de datos de Google. Para garantizar que el proceso marcha según lo previsto, se aplican controles adicionales, como medidas de seguridad física, cámaras y observadores humanos. Si la ceremonia se realiza de forma correcta, el certificado generado es idéntico a un certificado de muestra, excepto por el nombre del emisor, la clave pública y la firma. A continuación, el certificado de CA raíz resultante se envía al navegador y a los programas raíces del dispositivo para su inclusión. Este proceso se ha diseñado para garantizar la seguridad y privacidad de las claves privadas asociadas y que, de este modo, sigan siendo fiables durante una década o incluso más.

Como vimos anteriormente, las CA usan sus claves privadas para firmar certificados, y estos verifican las identidades al iniciar un handshake TLS como parte de la sesión del usuario. Los certificados del servidor están firmados con CA intermedias, que se crean del mismo modo que si se tratara de un CA raíz. Los certificados de CA intermedias se distribuyen como parte de la sesión TLS, de modo que migrar a una nueva resulta más sencillo. Este método de distribución también permite que el operador de la CA conserve el material de la clave de la CA raíz en modo sin conexión.

La seguridad de una sesión TLS depende de lo bien que esté protegida la clave del servidor. Para mitigar aún más los riesgos que corre la clave, la duración de un certificado de TLS de Google está limitada a unos tres meses y los certificados van rotando cada dos semanas aproximadamente.

Un cliente que se haya conectado previamente a un servidor puede usar una clave de entrada privada11 para reanudar una sesión anterior con un handshake TLS abreviado, por lo que estas entradas son muy valiosas para cualquier atacante. Google rota las claves de entrada al menos una vez al día, y las claves de todas las propiedades caducan cada tres días. Para obtener más información sobre la rotación de entradas de claves de sesión, consulta este artículo sobre los riesgos de seguridad en los accesos directos con criptografía TLS.

Entre Google Front End y el frontend de una aplicación

Algunas veces, como hemos visto en el apartado ¿Cómo se enruta el tráfico?, el usuario se conecta a GFE dentro de un límite físico distinto del servicio deseado y, por tanto, del frontend de la aplicación asociada. En esos casos, la solicitud del usuario y todos los protocolos de capa 7, como HTTP, están protegidos por TLS o encapsulados en una llamada a procedimiento remoto (RPC), que está protegida mediante la Seguridad de transporte en la capa de la aplicación (ALTS), como veremos en Autenticación, integridad y encriptado entre servicios. Estas RPC están autenticadas y encriptadas.

Para los servicios de Google Cloud, las RPC están protegidas mediante ALTS de forma predeterminada. En el caso de las aplicaciones de cliente alojadas en Google Cloud, si el tráfico se enruta mediante Google Front End, por ejemplo, si se usa el balanceador de carga de Google Cloud, el tráfico a la máquina virtual está protegido por el encriptado de red virtual de Google Cloud, como se describe en la siguiente sección.

Encriptado y autenticación de la red virtual de Google Cloud

La infraestructura de red virtual de Google Cloud habilita el encriptado cuando el tráfico abandona nuestra infraestructura física. El encriptado se realiza en la capa de red y se aplica al tráfico de IP privada en la misma nube privada virtual (VPC) o en redes VPC emparejadas.

Damos por supuesto que cualquier red que cruce un límite físico no controlado por nosotros o en nuestro nombre corre el riesgo de que un usuario malintencionado espíe, inserte o altere el tráfico durante la transmisión. Cuando los datos salen de la infraestructura física que podemos controlar, salvaguardamos la integridad y la privacidad de las comunicaciones a través del encriptado.

Para implementar el encriptado en la capa de red, usamos el estándar de encriptado avanzado (AES) en modo Galois/Counter (GCM) con una clave de 128 bits (AES-128-GCM). Cada par de hosts de comunicación establece una clave de sesión mediante un canal de control protegido por ALTS para las comunicaciones autenticadas y encriptadas. La clave de sesión se utiliza para encriptar todas las comunicaciones de máquina virtual a máquina virtual entre estos hosts, y las claves de sesión se rotan de forma periódica.

En la capa de red (capa 3), la red virtual de Google Cloud autentica todo el tráfico entre máquinas virtuales mediante tokens de seguridad para proteger los hosts comprometidos frente a paquetes de spoofing en la red.

Durante la autenticación, los tokens de seguridad se encapsulan en un encabezado de túnel que incluye información de autenticación sobre el emisor y el receptor. El plano de control12 del lado de envío configura el token y el host de recepción lo valida. Los tokens de seguridad, compuestos por una clave de token con la información del emisor y por el secreto del host, se generan previamente para cada flujo. Hay un secreto para cada par de origen y receptor de límites físicos controlados por Google o en su nombre. En la figura 4 se muestra cómo se crean las claves de token, los secretos de host y los tokens de seguridad.

Las partes que componen un token de seguridad pueden incluir una clave de token y un secreto de host, junto con sus dependencias.

Figura 4: Tokens de seguridad

El secreto de límite físico es un número seudoaleatorio de 128 bits a partir del cual se derivan los secretos de host mediante un HMAC-SHA1. El secreto de límite físico se negocia con un handshake entre los planos de control de red de un par de límites físicos, y se vuelve a negociar cada pocas horas. Los tokens de seguridad utilizados para la autenticación individual entre máquinas virtuales, derivados de estas y de otras entradas, son códigos HMAC y se negocian para un par concreto de emisor y receptor.

Autenticación, integridad y encriptado entre servicios

En la capa de aplicaciones (capa 7) de la infraestructura de Google, usamos el protocolo Seguridad de transporte en la capa de la aplicación (ALTS) para la autenticación, la integridad y el encriptado de las llamadas RPC de Google desde GFE a un servicio, o 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. Al hacer o recibir una RPC de otros servicios, el servicio utiliza sus credenciales para autenticarse. Para verificar estas credenciales, ALTS usa una autoridad de certificación interna.

Dentro de la infraestructura física controlada por Google o en su nombre, ALTS proporciona tanto la autenticación como la integridad para las RPC en el modo de autenticación e integridad. Para el tráfico a través de la red WAN fuera de los límites físicos controlados por nosotros o en nuestro nombre, ALTS aplica automáticamente el encriptado del tráfico de RPC de la infraestructura en el modo de autenticación, integridad y privacidad. En este momento, todo el tráfico a los servicios de Google, incluidos los servicios de Google Cloud, disfrutan de esta protección.

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

Los servicios se pueden configurar para aceptar y enviar comunicaciones ALTS solo en el modo de autenticación, integridad y privacidad, incluso dentro de la infraestructura física de Google o en su nombre. Un ejemplo de esto es el servicio interno de gestión de claves de Google, que almacena y administra las claves de encriptado utilizadas para proteger los datos almacenados en reposo en la infraestructura de Google.

Protocolo ALTS

ALTS tiene un protocolo de handshake seguro, similar a un protocolo TLS mutuo, que se usa en la comunicación entre dos servicios para autenticar y negociar los parámetros de comunicación antes de enviar información sensible. El protocolo consta de dos pasos:

  • Paso 1: Handshake El cliente inicia un handshake de protocolo Diffie‑Hellman de curva elíptica (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 utiliza durante el intercambio de claves Diffie‑Hellman. El handshake da como resultado una clave de tráfico común, disponible en el cliente y en el servidor. Las identidades del par de los certificados se utilizan en la capa de aplicaciones para tomar decisiones de autorización.
  • Paso 2: Encriptado del registro Los datos se transmiten del cliente al servidor de forma segura utilizando la clave de tráfico común del paso 1. El encriptado en ALTS se implementa mediante BoringSSL y otras bibliotecas de encriptado. El encriptado más común es AES-128-GCM y la integridad se suministra mediante el GMAC de AES-GCM.

En el siguiente diagrama, se muestra el handshake de ALTS en detalle. En implementaciones más recientes, un asistente de procesos se encarga del handshake, aunque sigue habiendo casos en los que lo hacen las aplicaciones directamente.

La aplicación cliente interactúa con un servicio handshake a través de un asistente de procesos y con la aplicación de un servidor a través de un intercambio de claves.

Figura 5: Handshake ALTS

Como se describe al inicio de la sección Autenticación, integridad y encriptado entre servicios, ALTS usa las cuentas de servicio para la autenticación, y cada servicio que se ejecuta en la infraestructura de Google lo hace como una identidad de servicio con credenciales criptográficas asociadas. Durante el handshake ALTS, el asistente de procesos accede a las claves privadas y a los certificados correspondientes que cada par de cliente‑servidor utiliza en sus comunicaciones. Por otra parte, también se ha aprovisionado la clave privada y el certificado correspondiente (búfer de protocolo firmado) a la identidad de cuenta de servicio de ese servicio.

Certificados ALTS Hay varios tipos de certificados ALTS:

  • Certificados de máquinas: proporcionan una identidad a los servicios principales de una máquina específica. Se rotan cada 6 horas aproximadamente.
  • Certificados de usuario: proporcionan una identidad de usuario final a los ingenieros de Google que desarrollan código. Se rotan cada 20 horas aproximadamente.
  • Certificados de tareas de Borg: proporcionan una identidad a las tareas que se ejecutan en la infraestructura de Google. Se rotan cada 48 horas aproximadamente.

Una autoridad de certificación (CA) interna de Google, independiente de nuestra CA externa y sin ninguna relación con ella, almacena la clave de firma del certificado raíz.

Encriptado en ALTS

Según las máquinas que se utilicen, se pueden usar diversos algoritmos para implementar el encriptado en ALTS. Por ejemplo, la mayoría de los servicios utilizan AES-128-GCM.13 Consulta la tabla 2 para obtener más información sobre el encriptado ALTS.

Máquinas Encriptado de mensajes utilizado  
Más común AES-128-GCM  
Sandy Bridge o anterior AES-128-VCM Usa un VMAC, en lugar de un GMAC, y es algo más eficiente en las máquinas más antiguas.

Tabla 2: Encriptado en ALTS

Casi todos los servicios de Google usan ALTS o la encapsulación de RPC que usa ALTS. En los casos en los que no es así, se emplean otras protecciones. Por ejemplo:

  • Algunos servicios de arranque y gestión de máquinas de nivel inferior utilizan SSH.
  • Algunos servicios de registro de infraestructuras de bajo nivel usan TLS o Datagram TLS (DTLS).14
  • Algunos servicios que usan protocolos de transporte que no son TCP emplean otros protocolos criptográficos o protecciones de nivel de red dentro de las infraestructuras controladas por Google o en su nombre.

En las comunicaciones entre las máquinas virtuales y los servicios de Google Cloud Platform se emplea TLS, y no ALTS, para la comunicación con Google Front End. Consulta Encriptado entre una máquina virtual y Google Front End para obtener más información.

Encriptado entre una máquina virtual y Google Front End

El tráfico de una máquina virtual a GFE usa IP externas para llegar a los servicios de Google, aunque puedes configurar la función de acceso privado de Google para usar solo direcciones IP de Google en las solicitudes.

Igual que sucede con otras solicitudes de usuarios externos a Google, de forma predeterminada, admitimos el tráfico TLS de una máquina virtual al GFE. La conexión se establece de la misma forma que cualquier otra conexión externa. Para obtener más información sobre TLS, consulta Seguridad en la capa de transporte (TLS).

Opciones personalizables por el usuario para el encriptado en tránsito

En la sección Encriptado en tránsito, hemos visto las protecciones predeterminadas que usamos en Google para los datos en tránsito. En esta sección se describe cómo se pueden configurar estas protecciones predeterminadas.

Entre el centro de datos on-premise y Google Cloud

TLS mediante balanceadores de carga externos GCLB

Si el servicio en la nube utiliza un balanceador de carga externo de proxy SSL o HTTPS de Google, GFE cancela las conexiones TLS de los usuarios mediante los certificados SSL que el usuario aprovisiona y controla. Para obtener más información sobre cómo personalizar el certificado, consulta nuestra documentación sobre certificados SSL.

Túnel IPSec con Google Cloud VPN

Los clientes de Google Cloud pueden usar Google Cloud VPN para conectar de forma segura sus redes on-premise a la red de nube privada virtual (VPC) de Google Cloud Platform a través de una conexión VPN IPSec (capa 3). El tráfico entre ambas redes lo encripta la pasarela VPN de una de las redes y lo desencripta la pasarela de la otra. De esta forma, tus datos están a buen recaudo en Internet. Además, puedes configurar varios túneles con balanceo de carga a través de diversas pasarelas VPN. Google Cloud VPN protege tus datos de las siguientes formas:

  • Los paquetes que se transfieren desde tus máquinas virtuales a Cloud VPN no abandonan la red de VCP. La red virtual de Google Cloud encripta estos paquetes si salen de los límites físicos controlados por nosotros o en nuestro nombre.
  • Los paquetes que se transfieren desde Cloud VPN hasta la VPN on-premise se encriptan y autentican mediante un túnel IPSec.
  • Los paquetes que se transfieren desde la VPN on-premise hasta los hosts on-premise están protegidos por los controles que el usuario haya implementado en la red.

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

Si quieres personalizar aún más tu red, puedes especificar la versión del protocolo de intercambio de claves de Internet15 (IKE) que quieres usar en tu túnel VPN. Puedes elegir entre dos versiones de IKE, IKEv1 e IKEv2, cada una de las cuales admite diferentes algoritmos de cifrado. Si especificas IKEv1, Google encripta los paquetes mediante AES-128-CBC y proporciona la integridad a través de HMAC-SHA-1.16 Si optas por IKEv2, hay una gran variedad de algoritmos de cifrado compatibles. En cualquier caso, Google Cloud VPN negociará el protocolo común más seguro que sea compatible con los dispositivos del par. Para ver las instrucciones completas sobre cómo configurar una VPN, consulta nuestra documentación sobre cómo elegir una opción de enrutamiento de VPN.

La interconexión dedicada de Google Cloud supone una alternativa a usar un túnel de Cloud VPN (IPSec), ya que proporciona conexiones físicas directas y comunicación de IP privada entre tu red on-premise y la red de VPC. Los datos que se transmiten mediante esta interconexión dedicada o de partner no se encriptan de manera predeterminada, por lo que deben protegerse en la capa de aplicación, por ejemplo, usando el protocolo TLS. Por el momento, MACsec (protección de capa 2) no es compatible.

Entre el usuario y Google Front End

Certificados SSL gestionados: certificados gratuitos y automatizados

Al crear una aplicación en Google Cloud, puedes configurar el certificado SSL que utilizas para aprovechar la compatibilidad de GFE con TLS. Por ejemplo, puedes terminar la sesión TLS en tu aplicación, aunque de forma diferente a la terminación de TLS que se explica en TLS mediante balanceadores de carga externos GCLB.

Google también proporciona 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 utilizar un encabezado de protocolo de seguridad de transporte estricta mediante HTTP (HSTS).

Cuando se señala a tu dominio en la infraestructura de Google, solicitamos y obtenemos un certificado para ese dominio que permite realizar comunicaciones seguras y administramos las claves privadas del servidor TLS, que pueden ser RSA de 2048 bits o ECC secp256r1, y renovamos los certificados en nombre de nuestros clientes.

Requerir que se use TLS en Gmail

Como hemos visto en Seguridad en la capa de transporte (TLS), Gmail usa TLS de forma predeterminada y registra y muestra si el último salto de un correo electrónico se produjo durante una sesión de TLS.17 Cuando dos usuarios de Gmail intercambian correos electrónicos, estos están protegidos por TLS o, en algunos casos, se envían directamente dentro de la aplicación. En esos casos, las RPC utilizadas por la aplicación Gmail están protegidas con ALTS, tal y como se describe en Autenticación, integridad y encriptado entre servicios. Aunque Gmail no aplica TLS a los mensajes entrantes que proceden de otros proveedores de correo electrónico, los administradores pueden configurar como requisito el uso de una conexión TLS segura para todos los mensajes entrantes y salientes.

Gmail S/MIME

Las extensiones seguras multipropósito de correo de Internet (S/MIME) son un estándar de seguridad de correo electrónico que proporciona autenticación, integridad y encriptado. La implementación del estándar S/MIME establece que todos los certificados asociados a los usuarios que mandan los 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 normas de contenido y de archivos adjuntos, y crear reglas de enrutamiento para los correos electrónicos entrantes y salientes. El siguiente paso consiste en cargar los certificados públicos de los usuarios en Gmail mediante la API de Gmail. En el caso de los usuarios externos, se debe intercambiar un mensaje inicial firmado con S/MIME para establecerlo como el protocolo predeterminado.

Encriptado entre servicios y entre máquinas virtuales

Istio es una malla de servicios de código abierto desarrollada, entre otros, por Google, IBM y Lyft para simplificar el descubrimiento y la conectividad de los servicios. La autenticación de Istio proporciona el encriptado automático de los datos en tránsito entre los servicios, y la administración de las claves y los certificados relacionados. Istio se puede utilizar en Google Kubernetes Engine y Google Compute Engine.

Si quieres implementar la autenticación y el encriptado mutuos para las cargas de trabajo, puedes utilizar la autenticación de Istio. De este modo permitirás que una CA a nivel de clúster genere y distribuya certificados, en particular para las cargas de trabajo de Kubernetes. Los certificados se usan a continuación para la Seguridad en la capa de transporte mutua (mTLS) entre pods.

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

En las secciones Encriptado en tránsito de forma predeterminada y Opciones personalizables por el usuario para el encriptado en tránsito, hemos visto las protecciones predeterminadas y personalizables que usamos en Google para los datos en tránsito de los clientes. Además, tenemos en marcha varios proyectos de software libre y otras iniciativas para fomentar el encriptado de datos en tránsito y la seguridad de los datos en Internet a gran escala.

Transparencia en los certificados

Para ofrecer HTTPS, como hemos visto en Encriptado entre el usuario y Google Front End, cualquier sitio web debe solicitar primero un certificado de una autoridad de certificación (CA) pública de una web de confianza. La autoridad de certificación se encarga de verificar que el solicitante está autorizado por el titular del dominio y de asegurar que el resto de la información incluida en el certificado sea precisa. A continuación, se envía este certificado al navegador para autenticar el sitio web al que intenta acceder el usuario. Para que la autenticación de HTTPS se realice correctamente, es importante cerciorarse de que las CA solo emiten certificados autorizados por el titular del dominio.

La transparencia en los certificados (CT) es una iniciativa lanzada por Google en marzo del 2013 para que los operadores de sitios web y los titulares de dominios puedan detectar si una CA ha emitido certificados incorrectos o sin autorización. Este sistema proporciona un mecanismo para que los titulares de dominios, las CA y los usuarios incluyan los certificados de confianza que ven o, en el caso de las CA, los certificados que emiten, en registros de solo anexión y a prueba de manipulaciones que se pueden verificar públicamente. Todo el mundo puede consultar los certificados de estos registros para asegurarse de que la información está autorizada y es correcta y precisa.

La primera versión de la transparencia en los certificados se especificó en un RFC experimental del IETF, RFC 6962. Durante el desarrollo de este sistema, Google creó numerosas herramientas de código abierto, como un servidor de registros para los certificados, así como herramientas para crear los registros de transparencia en los certificados. Además, Google Chrome requiere que algunos certificados se revelen públicamente, lo que incluye los certificados de validación extendida (EV) o los emitidos por CA que emitieron certificados inadecuados en el pasado. A partir del 2018, Chrome exigirá que se revelen todos los nuevos certificados públicos de confianza.

Los operadores de sitios web pueden usar la transparencia en los certificados para detectar si se ha emitido algún certificado no autorizado para sus sitios web. Hay varios recursos gratuitos que facilitan esta tarea, como el Informe de transparencia en los certificados o la búsqueda de certificados de Google, así como las herramientas de Facebook. Además, aunque no uses la transparencia en los certificados, muchos navegadores la examinan con frecuencia para asegurarse de que las CA en las que confían los usuarios para acceder a tu sitio web cumplen los requisitos y las prácticas recomendadas del sector, de modo que se reduce el riesgo de que se emitan certificados fraudulentos.

Aumentar el uso de HTTPS

Tal y como se describe en la sección Encriptado entre el usuario y Google Front End, nos esforzamos por asegurarnos de que nuestros sitios web y servicios proporcionen HTTPS moderno de forma predeterminada. Nuestro objetivo es llegar al 100 % de encriptado en todos nuestros productos y servicios, por lo que todos los años publicamos un Informe de transparencia de HTTPS para llevar un seguimiento del progreso hasta alcanzar nuestro objetivo en todas las propiedades, como Google Cloud. Seguimos trabajando para superar las barreras técnicas que dificultan el encriptado en algunos de nuestros productos, como soluciones para navegadores u otros clientes que no son compatibles con el protocolo de seguridad de transporte estricta mediante HTTP (HSTS).18 Usamos HSTS en algunos de nuestros sitios web, como la página principal de Google, para que los usuarios solo se conecten a un servidor a través de HTTPS.

Como sabemos que todo Internet está trabajando para migrar a HTTPS, intentamos facilitar esta transición de las siguientes formas:

En el 2016, empezamos a publicar métricas sobre el uso de HTTPS en Internet para los 100 sitios web principales que no son de Google con el objetivo de fomentar la concienciación y ayudar a convertir Internet en un lugar más seguro para todos los usuarios. En octubre del 2017, Chrome renovó formalmente la ayuda financiera a Let's Encrypt como patrocinador de nivel Platino.

Aumentar el uso del protocolo SMTP seguro: indicadores de Gmail

Casi todos los correos electrónicos se intercambian mediante el protocolo simple de transferencia de correo (SMTP), que, de forma predeterminada, envía correos electrónicos sin encriptado. Para encriptar un correo electrónico, el proveedor de correo electrónico debe implementar controles de seguridad, como TLS.

Como hemos visto en Encriptado entre el usuario y Google Front End, Gmail usa TLS de forma predeterminada. En la sección Requerir que se use TLS en Gmail, además, se describe cómo los administradores de Gmail pueden implementar de forma obligatoria el uso de una conexión TLS segura para todos los mensajes entrantes y salientes. Al igual que las iniciativas de Google por la transparencia de HTTPS, Gmail proporciona datos sobre el uso de TLS para los correos electrónicos entrantes de Gmail. Estos datos se pueden consultar en nuestro Informe de transparencia para la seguridad del correo electrónico.

Google, en colaboración con el IETF y otros importantes actores del sector, lidera el desarrollo de SMTP STS, que es similar a HSTS para HTTPS y fuerza el uso de SMTP solo en canales encriptados.

APIs de Chrome

En febrero del 2015, Chrome anunció la disponibilidad de nuevas funciones potentes solo para orígenes seguros19, como la gestión de información privada y el acceso a sensores en el dispositivo del usuario, y hemos empezado a desactivar estas funciones cuando tienen orígenes que no son seguros, empezando por la geolocalización en Chrome 50.

Innovación continua en el encriptado en tránsito

Experiencia de usuario de Chrome en materia de seguridad

Google Chrome es líder del sector en el uso de la interfaz de usuario para mostrar información de seguridad con el objetivo de que los usuarios sepan enseguida cuál es el nivel de seguridad de la conexión a un sitio web. Con esta información, los usuarios pueden tomar decisiones informadas sobre cuándo y cómo comparten sus datos. Chrome realiza minuciosos estudios de usuarios y comparte los resultados en artículos revisados por expertos.

Para ayudar a proteger aún más a sus usuarios, Chrome ha anunciado que, a finales del 2017, marcará todas las conexiones HTTP como no seguras. A partir de Chrome 56, los usuarios verán una advertencia de forma predeterminada en caso de que una página HTTP incluya un formulario con campos para indicar una contraseña o tarjeta de crédito. En Chrome 62, se mostrará una advertencia cuando un usuario introduzca sus datos en una página HTTP, así como en todas las páginas HTTP visitadas en modo de incógnito. Con el paso del tiempo, Chrome acabará mostrando una advertencia para todas las páginas servidas a través de HTTP.

Si quieres ver cómo se muestran determinadas configuraciones a los usuarios de Chrome, puedes usar la herramienta BadSSL.

Transparencia de claves

Un obstáculo significativo para la adopción generalizada del encriptado de mensajes es la dificultad del intercambio de claves públicas: ¿cómo podemos encontrar la clave pública de forma segura para comunicarnos con un nuevo usuario? Para ayudar a solucionar este problema, en enero del 2017, Google anunció la transparencia de claves, un framework abierto que proporciona un método general, seguro y auditable para distribuir claves públicas. Gracias a este framework, los usuarios no tienen que verificar manualmente las claves. La transparencia de claves está orientada principalmente a la distribución de claves públicas de los usuarios durante las comunicaciones, como el encriptado de correo electrónico OpenPGP y el de extremo a extremo. Su diseño, que constituye un nuevo enfoque de la recuperación y distribución de claves, se basa en la información obtenida mediante la transparencia en los certificados y CONIKS.

La transparencia de claves se ha desarrollado con software libre y se ha implementado mediante un árbol de Merkle a gran escala. Con la verificación de la transparencia de claves, los propietarios de las cuentas pueden ver qué claves se han asociado a sus cuentas y durante cuánto tiempo ha estado la cuenta activa y estable. El objetivo de Google a largo plazo es permitir que todo el mundo pueda ejecutar un servidor de transparencia de claves, así como facilitar su integración en cualquier número de aplicaciones.

Criptografía poscuántica

Google se propone seguir siendo el líder del sector en el encriptado de los datos en tránsito. Para ello, hemos empezado a trabajar en el área de la criptografía poscuántica, un tipo de criptografía que permite sustituir primitivas criptográficas vulnerables a ataques cuánticos eficientes por candidatos poscuánticos que parecen oponer mayor resistencia. En julio del 2016, anunciamos que habíamos llevado a cabo un experimento sobre la viabilidad del despliegue de un algoritmo de este tipo mediante el algoritmo criptográfico poscuántico New Hope en la versión para desarrolladores de Chrome. Además, los investigadores de Google han trabajado en otras publicaciones sobre distintos protocolos prácticos de intercambio de claves de tipo poscuántico.

Apéndice

Consulta más información sobre la seguridad de Google Cloud, como este resumen del diseño de la seguridad de la infraestructura, y sobre el cumplimiento de Google Cloud, como este informe de auditoría SOC 3.

Notas a pie de página

1 Entre las soluciones de partners se incluyen tanto las soluciones ofrecidas en Cloud Launcher como los productos creados en colaboración con los partners, como Cloud Dataprep.
2 Todavía puedes inhabilitar este encriptado (por ejemplo, para el acceso HTTP a segmentos de Google Cloud Storage).
3 Las comunicaciones de una máquina virtual a un servicio que no están protegidas en la capa 7 siguen estando protegidas en las capas 3 y 4.
4 TLS 1.3 no está terminado aún. La versión de borrador se ha implementado solo en ciertos dominios de Google para hacer pruebas, como Gmail.
5 Google admite TLS 1.0 en los navegadores que todavía usan esta versión del protocolo. Ten en cuenta que todos los sitios web de Google que procesan datos de tarjetas de crédito han dejado de admitir TLS 1.0 desde que en julio del 2018 se pidiera su desactivación para cumplir las normativas del sector de las tarjetas de pago (PCI).
6 Para obtener más información sobre QUIC, consulta [https://www.chromium.org/quic](https://www.chromium.org/quic).
7, 8, 9 Para ofrecer retrocompatibilidad con algunos sistemas operativos antiguos, aceptamos los protocolos 3DES, SHA1 y MD5.
10 En lo que respecta a los certificados en cadena, la CA tiene una confianza transitiva.
11 Podría ser una entrada 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 se encarga del tráfico de señalización y es responsable del enrutamiento.
13 Antes se usaban otros protocolos, pero ahora se han quedado obsoletos y los usan menos del 1 % de las tareas.
14 Datagram TLS (DTLS) proporciona seguridad para las aplicaciones basadas en datagramas al permitir la comunicación de forma que se evitan las manipulaciones y las intrusiones.
15 El protocolo de intercambio de claves en Internet (IKE) se usa para configurar una asociación de seguridad en el paquete de protocolos IPSec.
16 HMAC-SHA-1 no se rompe por una [colisión de SHA-1](https://shattered.io/), como la colisión SHAttered descubierta por los investigadores de Google.
17 En G Suite Enterprise, esto no se muestra en la interfaz de usuario. Los administradores del dominio pueden examinar los datos de su dominio mediante la [búsqueda en el registro de correo electrónico](https://support.google.com/a/answer/2604578).
18 El protocolo de seguridad de transporte estricta mediante HTTP (HSTS) es un mecanismo que permite a los sitios web declararse accesibles solo mediante conexiones seguras o que los usuarios dirijan sus user‑agents para interactuar con ciertos sitios web solo mediante conexiones seguras.
19 Los orígenes seguros son conexiones que cumplen determinados [patrones](https://www.chromium.org/Home/chromium-security/prefer-secure-origins-for-powerful-new-features) de esquema, host o puerto.