Sobre HTTPS¶

Es fácil asumir que HTTPS es algo que simplemente está "activado" o no.

Pero es mucho más complejo que eso.

Paraaprender los conceptos básicos de HTTPS, desde una perspectiva de consumidor, revisahttps://howhttps.works/.

Ahora, desde unaperspectiva de desarrollador, aquí hay varias cosas a tener en cuenta al pensar en HTTPS:

• Para HTTPS,el servidor necesitatener "certificados" generados por untercero.
  • Esos certificados en realidad sonadquiridos del tercero, no "generados".
• Los certificados tienen unavida útil.
  • Ellosexpiran.
  • Y luego necesitan serrenovados,adquiridos nuevamente del tercero.
• La encriptación de la conexión ocurre a nivel deTCP.
  • Esa es una capadebajo de HTTP.
  • Por lo tanto, el manejo decertificados y encriptación se realizaantes de HTTP.
• TCP no sabe acerca de "dominios". Solo sobre direcciones IP.
  • La información sobre eldominio específico solicitado va en losdatos HTTP.
• Loscertificados HTTPS "certifican" uncierto dominio, pero el protocolo y la encriptación ocurren a nivel de TCP,antes de saber con cuál dominio se está tratando.
• Por defecto, eso significaría que solo puedes tenerun certificado HTTPS por dirección IP.
  • No importa cuán grande sea tu servidor o qué tan pequeña pueda ser cada aplicación que tengas en él.
  • Sin embargo, hay unasolución para esto.
• Hay unaextensión para el protocoloTLS (el que maneja la encriptación a nivel de TCP, antes de HTTP) llamadaSNI.
  • Esta extensión SNI permite que un solo servidor (con unasola dirección IP) tengavarios certificados HTTPS y sirvamúltiples dominios/aplicaciones HTTPS.
  • Para que esto funcione, un componente (programa)único que se ejecute en el servidor, escuchando en ladirección IP pública, debe tenertodos los certificados HTTPS en el servidor.
• Después de obtener una conexión segura, el protocolo de comunicación sigue siendoHTTP.
  • Los contenidos estánencriptados, aunque se envién con elprotocolo HTTP.

Es una práctica común tenerun programa/servidor HTTP ejecutándose en el servidor (la máquina, host, etc.) ygestionando todas las partes de HTTPS: recibiendo losrequests HTTPS encriptados, enviando losrequests HTTP desencriptados a la aplicación HTTP real que se ejecuta en el mismo servidor (la aplicaciónFastAPI, en este caso), tomando elresponse HTTP de la aplicación,encriptándolo usando elcertificado HTTPS adecuado y enviándolo de vuelta al cliente usandoHTTPS. Este servidor a menudo se llama unTLS Termination Proxy.

Algunas de las opciones que podrías usar como un TLS Termination Proxy son:

• Traefik (que también puede manejar la renovación de certificados)
• Caddy (que también puede manejar la renovación de certificados)
• Nginx
• HAProxy

Let's Encrypt¶

Antes de Let's Encrypt, estoscertificados HTTPS eran vendidos por terceros.

El proceso para adquirir uno de estos certificados solía ser complicado, requerir bastante papeleo y los certificados eran bastante costosos.

Pero luego se creóLet's Encrypt.

Es un proyecto de la Linux Foundation. Proporcionacertificados HTTPS de forma gratuita, de manera automatizada. Estos certificados usan toda la seguridad criptográfica estándar, y tienen una corta duración (aproximadamente 3 meses), por lo que laseguridad es en realidad mejor debido a su lifespan reducida.

Los dominios son verificados de manera segura y los certificados se generan automáticamente. Esto también permite automatizar la renovación de estos certificados.

La idea es automatizar la adquisición y renovación de estos certificados para que puedas tenerHTTPS seguro, gratuito, para siempre.

HTTPS para Desarrolladores¶

Aquí tienes un ejemplo de cómo podría ser una API HTTPS, paso a paso, prestando atención principalmente a las ideas importantes para los desarrolladores.

Nombre de Dominio¶

Probablemente todo comenzaría adquiriendo unnombre de dominio. Luego, lo configurarías en un servidor DNS (posiblemente tu mismo proveedor de la nube).

Probablemente conseguirías un servidor en la nube (una máquina virtual) o algo similar, y tendría unadirección IP públicafija.

En el/los servidor(es) DNS configurarías un registro (un "A record") para apuntartu dominio a ladirección IP pública de tu servidor.

Probablemente harías esto solo una vez, la primera vez, al configurar todo.

DNS¶

Ahora centrémonos en todas las partes realmente de HTTPS.

Primero, el navegador consultaría con losservidores DNS cuál es laIP del dominio, en este caso,someapp.example.com.

Los servidores DNS le dirían al navegador que use unadirección IP específica. Esa sería la dirección IP pública utilizada por tu servidor, que configuraste en los servidores DNS.

Inicio del Handshake TLS¶

El navegador luego se comunicaría con esa dirección IP en elpuerto 443 (el puerto HTTPS).

La primera parte de la comunicación es solo para establecer la conexión entre el cliente y el servidor y decidir las claves criptográficas que usarán, etc.

Esta interacción entre el cliente y el servidor para establecer la conexión TLS se llamahandshake TLS.

TLS con Extensión SNI¶

Solo un proceso en el servidor puede estar escuchando en unpuerto específico en unadirección IP específica. Podría haber otros procesos escuchando en otros puertos en la misma dirección IP, pero solo uno para cada combinación de dirección IP y puerto.

TLS (HTTPS) utiliza el puerto específico443 por defecto. Así que ese es el puerto que necesitaríamos.

Como solo un proceso puede estar escuchando en este puerto, el proceso que lo haría sería elTLS Termination Proxy.

El TLS Termination Proxy tendría acceso a uno o máscertificados TLS (certificados HTTPS).

Usando laextensión SNI discutida anteriormente, el TLS Termination Proxy verificaría cuál de los certificados TLS (HTTPS) disponibles debería usar para esta conexión, usando el que coincida con el dominio esperado por el cliente.

En este caso, usaría el certificado parasomeapp.example.com.

El cliente yaconfía en la entidad que generó ese certificado TLS (en este caso Let's Encrypt, pero lo veremos más adelante), por lo que puedeverificar que el certificado sea válido.

Luego, usando el certificado, el cliente y el TLS Termination Proxydeciden cómo encriptar el resto de lacomunicación TCP. Esto completa la parte deHandshake TLS.

Después de esto, el cliente y el servidor tienen unaconexión TCP encriptada, esto es lo que proporciona TLS. Y luego pueden usar esa conexión para iniciar la comunicaciónHTTP real.

Y eso es lo que esHTTPS, es simplemente HTTP simpledentro de una conexión TLS segura en lugar de una conexión TCP pura (sin encriptar).

Request HTTPS¶

Ahora que el cliente y el servidor (específicamente el navegador y el TLS Termination Proxy) tienen unaconexión TCP encriptada, pueden iniciar lacomunicación HTTP.

Así que, el cliente envía unrequest HTTPS. Esto es simplemente un request HTTP a través de una conexión TLS encriptada.

Desencriptar el Request¶

El TLS Termination Proxy usaría la encriptación acordada paradesencriptar el request, y transmitiría elrequest HTTP simple (desencriptado) al proceso que ejecuta la aplicación (por ejemplo, un proceso con Uvicorn ejecutando la aplicación FastAPI).

Response HTTP¶

La aplicación procesaría el request y enviaría unresponse HTTP simple (sin encriptar) al TLS Termination Proxy.

Response HTTPS¶

El TLS Termination Proxy entoncesencriptaría el response usando la criptografía acordada antes (que comenzó con el certificado parasomeapp.example.com), y lo enviaría de vuelta al navegador.

Luego, el navegador verificaría que el response sea válido y encriptado con la clave criptográfica correcta, etc. Entoncesdesencriptaría el response y lo procesaría.

El cliente (navegador) sabrá que el response proviene del servidor correcto porque está utilizando la criptografía que acordaron usando elcertificado HTTPS anteriormente.

Múltiples Aplicaciones¶

En el mismo servidor (o servidores), podrían habermúltiples aplicaciones, por ejemplo, otros programas API o una base de datos.

Solo un proceso puede estar gestionando la IP y puerto específica (el TLS Termination Proxy en nuestro ejemplo) pero las otras aplicaciones/procesos pueden estar ejecutándose en el/los servidor(es) también, siempre y cuando no intenten usar la mismacombinación de IP pública y puerto.

De esa manera, el TLS Termination Proxy podría gestionar HTTPS y certificados paramúltiples dominios, para múltiples aplicaciones, y luego transmitir los requests a la aplicación correcta en cada caso.

Renovación de Certificados¶

En algún momento en el futuro, cada certificadoexpiraría (alrededor de 3 meses después de haberlo adquirido).

Y entonces, habría otro programa (en algunos casos es otro programa, en algunos casos podría ser el mismo TLS Termination Proxy) que hablaría con Let's Encrypt y renovaría el/los certificado(s).

Loscertificados TLS estánasociados con un nombre de dominio, no con una dirección IP.

Entonces, para renovar los certificados, el programa de renovación necesitaprobar a la autoridad (Let's Encrypt) que de hecho"posee" y controla ese dominio.

Para hacer eso, y para acomodar diferentes necesidades de aplicaciones, hay varias formas en que puede hacerlo. Algunas formas populares son:

• Modificar algunos registros DNS.
  • Para esto, el programa de renovación necesita soportar las API del proveedor de DNS, por lo que, dependiendo del proveedor de DNS que estés utilizando, esto podría o no ser una opción.
• Ejecutarse como un servidor (al menos durante el proceso de adquisición del certificado) en la dirección IP pública asociada con el dominio.
  • Como dijimos anteriormente, solo un proceso puede estar escuchando en una IP y puerto específicos.
  • Esta es una de las razones por las que es muy útil cuando el mismo TLS Termination Proxy también se encarga del proceso de renovación del certificado.
  • De lo contrario, podrías tener que detener momentáneamente el TLS Termination Proxy, iniciar el programa de renovación para adquirir los certificados, luego configurarlos con el TLS Termination Proxy, y luego reiniciar el TLS Termination Proxy. Esto no es ideal, ya que tus aplicaciones no estarán disponibles durante el tiempo que el TLS Termination Proxy esté apagado.

Todo este proceso de renovación, mientras aún se sirve la aplicación, es una de las principales razones por las que querrías tener unsistema separado para gestionar el HTTPS con un TLS Termination Proxy en lugar de simplemente usar los certificados TLS con el servidor de aplicaciones directamente (por ejemplo, Uvicorn).

Headers reenviados por el proxy¶

Al usar un proxy para gestionar HTTPS, tuservidor de aplicaciones (por ejemplo Uvicorn vía FastAPI CLI) no sabe nada sobre el proceso HTTPS, se comunica con HTTP simple con elTLS Termination Proxy.

Esteproxy normalmente configuraría algunos headers HTTP sobre la marcha antes de transmitir el request alservidor de aplicaciones, para hacerle saber al servidor de aplicaciones que el request está siendoreenviado por el proxy.

Aun así, como elservidor de aplicaciones no sabe que está detrás de unproxy de confianza, por defecto, no confiaría en esos headers.

Pero puedes configurar elservidor de aplicaciones para confiar en los headers reenviados enviados por elproxy. Si estás usando FastAPI CLI, puedes usar laOpción de la CLI--forwarded-allow-ips para indicarle desde qué IPs debería confiar en esos headers reenviados.

Por ejemplo, si elservidor de aplicaciones solo está recibiendo comunicación delproxy de confianza, puedes establecerlo en--forwarded-allow-ips="*" para hacer que confíe en todas las IPs entrantes, ya que solo recibirá requests desde la IP que sea utilizada por elproxy.

De esta manera la aplicación podrá saber cuál es su propia URL pública, si está usando HTTPS, el dominio, etc.

Esto sería útil, por ejemplo, para manejar correctamente redirecciones.

Resumen¶

TenerHTTPS es muy importante y bastantecrítico en la mayoría de los casos. La mayor parte del esfuerzo que como desarrollador tienes que poner en torno a HTTPS es solo sobreentender estos conceptos y cómo funcionan.

Pero una vez que conoces la información básica deHTTPS para desarrolladores puedes combinar y configurar fácilmente diferentes herramientas para ayudarte a gestionar todo de una manera sencilla.

En algunos de los siguientes capítulos, te mostraré varios ejemplos concretos de cómo configurarHTTPS para aplicacionesFastAPI. 🔒