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

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.

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

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