Management en Salud: Encriptación en tránsito 1: HTTPS

Buenas tardes, en este tercer capítulo de la serie Arquitectura de Sistemas Seguros para Aplicaciones Web en Salud Digital explicaré la importancia y la implementación de HTTPS (Hypertext Transfer Protocol Secure), y por qué es crítico que los profesionales de la salud empleen aplicaciones web en las que se haya configurado correctamente.

Seguridad en ausencia de HTTPS

El protocolo HTTP es el principal protocolo empleado por la web para transmitir contenido de alto nivel. Éste cumple 2 funciones principales

1. En primer lugar se encarga de transmitir información desde un servidor web al browser de un usuario, como por ejemplo los archivos requeridos para desplegar una aplicación web en un browser cualquiera

2. En segundo lugar se encarga de transmitir las peticiones de los usuarios realizan al interactuar con una aplicación web, a través de su browsers a los servidores web para ser procesadas

Con esta información podemos deducir que todo intercambio de información entre un usuario y una aplicación web, sin importar cuán sensible sea esta información será transmitida a través del protocolo HTTP. Sin embargo HTTP no está encriptado por defecto, constituyendo el principal incentivo a los ataques Man In The Middle.

Ataques MITM

¿Alguna vez has visto el mensaje “No seguro” a la izquierda de la barra de navegación? Esto significa que los mensajes HTTP no son encriptados y si eres un profesional ingresando tus credenciales a una aplicación con la información de tus pacientes, puedes estar entregando toda esta información a una entidad desconocida.

Una forma en la que este ataque puede ser realizado en aproximadamente 15 minutos

1. Emplear el comando “tracert <url-de-aplicación>” para identificar las IPs de los routers intermedios empleados para llegar al servidor web.

2. Emplear SHODAN para identificar el modelo de un router intermedio objetivo

3. Buscar en Google las credenciales por defecto para ingresar a este modelos

4. Verificar que las credenciales permitan acceder al router (probablemente esto funcione en uno de los primeros 3 routers probados) y configurar una herramienta de Sniffing diseñada para el modelo de este router

5. Esperar unos minutos hasta que alguien envíe un mensaje con las credenciales de acceso a la aplicación

Probablemente esto sea suficiente para comprender lo peligroso que es no configurar HTTPS en Salud Digital.

Primer nivel de HTTPS

Cloudflare es una de las redes más grandes operando en internet y entre muchos de sus servicios está el de administrar registros DNS y de el funcionar como proxy inverso de forma totalmente gratuita, para todos los dominios que se desee. Al activar su funcionalidad de proxy inverso los mensajes no viajarán directamente hasta los servidores web de la aplicación sino que pasarán primero por los proxies inversos de Cloudflare. Estos se encargarán de que los mensajes sean encriptados desde el usuario hasta los proxies inversos de Cloudflare además de posibilitar otros beneficios de seguridad y de performance.

Para la siguiente prueba emplearemos la arquitectura desplegada en el Capítulo anterior, por lo que es importante que éste esté desplegado antes del paso 4.

1. Suponiendo que se tiene un dominio .cl se debe acceder a nic.cl y configurar servidores DNS de Cloudflare cualquiera para que éste pueda detectarlos. Esto puede ser realizado en la sección “Configuración Técnica” al interior de la configuración de un dominio dado

2. Posteriormente ingresamos a Cloudflare y seleccionamos “Agregar un sitio” en la página inicial

3. Luego ingresamos el nombre de dominio, apretamos “Agregar sitio” y seguimos los pasos indicados

4. Una vez que el dominio está configurado en Cloudflare, vamos a la pestaña DNS y agregamos un registro A con el subdominio deseado (por ejemplo “check” en caso que las pruebas deseen realizarse en la dirección “check.<tudominio.cl>”) como nombre del registro y la dirección IPv4 de la instancia EC2 desplegada en AWS (como aparece en la Imagen 4 del Capítulo anterior, la que variará de despliegue a despliegue)

5. Luego vamos a la pestaña SSL/TLS donde nos aseguramos de que la configuración de encriptación sea flexible

6. Adicionalmente, en esta pestaña se puede ingresar a la sección “Certificados de perímetro” y especificar “Versión mínima de TLS” TLS 1.2 (mínima sin vulnerabilidades identificadas hasta la fecha) y poner el switch en “On” en la entrada “Reescrituras automáticas de HTTPS”

Con esto aumentamos en gran medida la seguridad de la aplicación, dado que al acceder a ella se indicará que la comunicación está encriptada.

Sin embargo, habrá una sección del camino de los mensajes que no lo estará, por lo que todavía es posible un ataque MITM en caso de que un atacante busque seriamente las vulnerabilidades de la aplicación.

Segundo nivel de HTTPS

Este segundo nivel consiste en alcanzar la encriptación end-to-end, para lo que es necesario poseer un certificado autofirmado en el servidor. Afortunadamente la imagen de Apache empleada ya posee uno, por lo que basta con

1. Modificar el grupo de seguridad para que permita acceso a través de HTTPS y que para ello emplee el puerto 443. Estos simples cambios están presentes en el siguiente template, para el que basta con hacer Update al template desplegado anteriormente: self-ssl-vpc.yml

2. Luego en Cloudflare

Posteriormente verificamos nuevamente que el subdominio se está desplegando correctamente mediante https, esperando unos segundos y probando en una nueva pestaña de incógnito

Tercer nivel de HTTPS

En este tercer nivel configuraremos el servidor para emplear un certificado firmado por AWS en un Balanceador de Carga, con el que luego de esto Cloudflare también se comunicará de forma encriptada. Para esto es necesario

1. Acceder a AWS Certificate Manager y seleccionar la opción de la izquierda

2. Solicitar un certificado público y especificar el dominio o subdominios para los que se desea solicitar el certificado

3. Seleccionar validación DNS, continuar y continuar

4. Luego los registros que se muestran deben ser agregados a Cloudflare para AWS pueda verificar que somos dueños del dominio, por lo que procedemos a añadirlo, pero sin que Cloudflare haga de proxy (nube gris en vez de naranja)

5. Posteriormente verificamos que el certificado fue emitido para lo que actualizamos si es necesario (debería emitirse sólo en algunos segundos) También anotamos el Arn (Amazon Resource Name) del certificado emitido

6. Ahora procedemos a descargar el template de Cloudformation para este último nivel, en el que reemplazamos el arn en el lugar que aparece indicado en su interior, y procedemos a actualizar (en este caso eliminar y crear una nueva versió de) el stack actualmente desplegado en la cuenta: ca-ssl-vpc.yml

7. Luego de que el stack ha sido desplegado copiamos el domio del balanceador de carga creado y creamos un registro CNAME con el nombre del subdominio deseado y el valor de la dirección copiada (para lo que tendremos que eliminar el registro A anteriormente empleado)