Curso interactivo de HTTP y HTTPS: qué protege TLS, qué no protege y cómo dejar de confiar solo en el candado

Cuando un agente de IA, un script de automatización o una integración de tu empresa envía datos a una API de terceros, casi todo lo que ocurre viaja sobre HTTP. Y hay una pregunta que debería hacerte antes de pulsar enter: ¿esos datos van por un canal protegido o van en claro? El curso interactivo Básicos HTTP/S ataca exactamente ese problema: entender cuándo HTTP viaja claro, cuándo HTTPS protege de verdad y qué señales revisar antes de confiar en una conexión.

Es un recorrido técnico, y no un tutorial de «ponle un candado a tu web», desde la semántica de los mensajes HTTP hasta el handshake TLS 1.3, la validación de certificados, la negociación ALPN, HSTS, las cookies, la caché y el contenido mixto. Está pensado para estudiantes de redes, ciberseguridad y administración de sistemas, y encaja muy bien con el perfil de IAcademy: profesionales que construyen y usan IA y que necesitan criterio de seguridad aplicada, no teoría de folleto.

Quien complete el curso gana tres cosas concretas: un modelo mental claro de qué capa hace qué (HTTP define mensajes, TLS protege el canal, HTTPS une ambos), la capacidad de leer un perfil web y detectar riesgos reales de downgrade, credenciales expuestas y contenido mixto, y un método de trabajo para evaluar cualquier despliegue web con mentalidad de auditoría ligera.

Anatomía del curso: recorrido sección a sección

El curso es una aplicación de una sola página dividida en diez bloques. Vamos a recorrerlos en el mismo orden en que aparecen, porque esa progresión (de modelo mental a práctica de evaluación) es parte del diseño didáctico.

Hero: el modelo mental de partida

La página abre con una frase que condensa todo el curso y que conviene memorizar: «HTTP define mensajes. TLS protege el canal. HTTPS une ambos». Mucha de la confusión alrededor de la seguridad web nace de mezclar estas tres piezas: la gente cree que HTTPS «hace segura» una aplicación, cuando en realidad solo protege el transporte. La semántica HTTP (métodos, cabeceras, cookies, caché) sigue siendo exactamente la misma, y sus vulnerabilidades también. Junto al titular hay un diagrama visual de una petición HTTP protegida por TLS, con navegador, certificado, proxy, caché y servidor de origen.

Franja de datos clave

Un bloque compacto con tres anclas de estudio: el RFC 9110 como base de la semántica HTTP (métodos, códigos, campos y representación), TLS 1.3 como la versión actual definida por el RFC 9846 que protege el HTTPS moderno, y HSTS como la política del servidor que fuerza HTTPS en visitas futuras del navegador. Son los tres pilares que el resto del curso desarrolla en detalle.

El mapa del ecosistema HTTP/S

Aquí empieza lo interesante. Un mapa conceptual interactivo (renderizado como grafo con Cytoscape) presenta trece componentes de una navegación real, agrupados por tipo: cliente, identidad, resolución, transporte, seguridad, negociación, semántica, ruta, rendimiento, política, servidor y riesgo. Cada nodo es clicable y despliega en un panel lateral su descripción, tres hechos clave y enlaces a las fuentes primarias.

El valor del mapa no está en el grafo en sí, sino en las aristas que conectan los nodos y en el nodo que casi todos los diagramas educativos omiten: el atacante en la ruta. El mapa muestra explícitamente cómo un adversario «observa» la conexión TCP y «degrada» la URL. En HTTP claro, una persona situada en la red puede leer o modificar el tráfico; HTTPS reduce ese riesgo, pero solo si la validación TLS es correcta. Los hechos que enumera el nodo son oro para cualquier análisis de riesgo: el ataque de downgrade intenta llevar al usuario de HTTPS a HTTP, los errores de certificado aceptados manualmente rompen la autenticación, y el contenido mixto y las cookies sin Secure pueden reabrir canales inseguros dentro de una página que parecía protegida.

Otros nodos destacables: la distinción entre DNS y TLS (la resolución DNS no prueba la identidad criptográfica del servidor; DNSSEC protege los datos DNS, pero no sustituye al certificado), el nodo de certificado (un certificado válido para otro nombre no autentica el servicio actual, y la cadena debe enlazar con una autoridad confiable), y el nodo de intermediarios, que recuerda que la terminación TLS en un balanceador requiere proteger también el tramo interno.

Simulador «De URL a respuesta»: nueve pasos de una petición

Este es, en mi opinión, el corazón didáctico del curso. Un simulador paso a paso recorre la vida completa de una petición en nueve etapas, cada una con su traza técnica y sus comprobaciones de seguridad:

• URL y origen. El cliente separa esquema, host, puerto y ruta. Con https:// espera un canal TLS antes de enviar nada. Aviso clave: evita tokens secretos en la query string, porque viajan en historial, logs y referers.
• Resolución DNS. Consulta del nombre, respuesta A/AAAA y, si existe, un registro HTTPS/SVCB (RFC 9460) con pistas del servicio. Límite explícito: DNS no sustituye la validación TLS.
• Conexión de transporte. HTTP/1.1 y HTTP/2 sobre TCP; HTTP/3 sobre QUIC (UDP 443). El curso insiste en algo que muchos confunden: el puerto 443 no es seguridad automática; debe existir un handshake TLS válido.
• Handshake TLS. ClientHello (SNI, ALPN, grupos, ciphers), ServerHello con los parámetros elegidos y derivación de claves de sesión. TLS 1.3 reduce rondas y elimina mecanismos heredados.
• Validación de certificado. Nombre (el SAN debe contener el host solicitado), cadena hasta una raíz confiable y vigencia temporal. «Un error de nombre no es un aviso menor: es fallo de identidad».
• ALPN. Dentro del handshake se negocia el protocolo de aplicación: el cliente ofrece h2 y http/1.1, el servidor elige. ALPN no cambia la semántica HTTP; cambia el protocolo de transporte sobre TLS.
• Solicitud HTTP cifrada. Con el canal protegido llegan el método, los campos (Host, Cookie, Authorization) y el cuerpo. Aquí el curso plantea una verdad poco agradable: HTTPS protege el canal, pero no convierte una API insegura en segura.
• Respuesta y políticas. Estado, cabeceras y contenido. Las cabeceras definen caché, cookies, HSTS, CSP y CORS. Hay que leer Location para detectar redirecciones de downgrade.
• Caché y memoria del navegador. La petición muere, pero sus consecuencias persisten: respuestas cacheadas, HSTS recordado, conexiones reutilizadas. Al evaluar HSTS conviene probar primera visita, visita repetida y subdominios.

El flujo completo, resumido en el diagrama que el propio curso plantea:

URL ──> DNS ──> TCP/QUIC ──> TLS handshake ──> certificado
                                    │
                                    ├─ ALPN: h2 / h3 / http1.1
                                    ▼
        solicitud HTTP cifrada ──> respuesta + políticas
                                    │
                    ┌───────────────┼────────────────┐
                    ▼               ▼                ▼
                 caché           HSTS          cookies/credenciales

  [atacante en la ruta: observa TCP · degrada la URL · espera downgrade]

Anatomía: qué cambia exactamente con HTTPS

Esta sección descompone la pila en siete partes seleccionables (HTTP, esquema, TLS, certificado, cabeceras, HSTS y riesgo de contenido mixto) con su detalle correspondiente. Los matices que aporta son precisamente los que se pierden en las explicaciones superficiales:

• El mismo host con http:// y https:// son orígenes distintos para el navegador: cambiar el esquema cambia garantías y políticas.
• TLS no define rutas ni métodos: su trabajo es autenticar el servicio, cifrar el tráfico y detectar modificación en tránsito. SNI, por cierto, sirve para seleccionar certificado en servidores compartidos.
• La validación de nombre se hace contra las identidades del certificado, normalmente subjectAltName. Un certificado autofirmado puede cifrar, pero no autentica frente a clientes generales.
• Las cabeceras son decisiones de seguridad: Set-Cookie sin Secure expone sesiones si aparece una ruta HTTP; Caché-Control protege datos sensibles cuando evita su almacenamiento indebido.
• Sobre HSTS: max-age define cuánto dura la regla, includeSubDomains amplía el alcance (y exige control de todos los subdominios), y preload reduce el problema de primera conexión.
• Sobre contenido mixto: los scripts cargados por HTTP son especialmente peligrosos porque ejecutan código modificable; upgrade-insecure-requests ayuda a migrar cuando existe alternativa HTTPS.

Laboratorio local: analiza un perfil web

El laboratorio es la parte más práctica del curso. Introduces una URL, el estado TLS observado (de TLS 1.3 a «sin TLS»), el estado del certificado (válido, caducado, nombre no coincide, autofirmado, CA no confiable), el protocolo negociado por ALPN y un bloque de cabeceras de respuesta. Al pulsar «Analizar», todo el razonamiento ocurre localmente en tu navegador (no se envía nada a ningún servidor) y obtienes un informe con hallazgos clasificados en buenos, avisos y errores.

El motor de análisis es sorprendentemente fino. Comprueba al menos una docena de cosas, entre ellas: si el esquema es HTTPS o HTTP claro; si el puerto encaja con el esquema; si la ruta o la query parecen sensibles (detecta patrones como login, session, token, auth, password, admin, private o secret); la versión TLS y su adecuación; el estado del certificado con un mensaje específico por cada modo de fallo; la política HSTS (distingue HSTS fuerte con max-age de al menos un año e includeSubDomains, HSTS limitado, HSTS llegado por canal claro (que no debe aprenderse) y falta de HSTS en un sitio HTTPS); redirecciones en Location hacia http:// como riesgo de downgrade; cada Set-Cookie evaluado en busca de Secure, HttpOnly y la combinación prohibida SameSite=None sin Secure; Caché-Control: no-store en URLs sensibles; CSP con upgrade-insecure-requests; CORS con el patrón incompatible de Access-Control-Allow-Origin: * junto a credenciales true; y Alt-Svc anunciando HTTP/3.

Incluye dos perfiles precargados para comparar. El perfil seguro: https://www.example.test/login con TLS 1.3, certificado válido, HTTP/2 y cabeceras ejemplares (HSTS de un año con includeSubDomains y preload, CSP con upgrade-insecure-requests, cookie con Secure, HttpOnly y SameSite=Lax, Caché-Control: no-store, Alt-Svc h3, nosniff y Referrer-Policy). El perfil débil: http://login.example.test/session?token=abc123 sin TLS, redirección 302 a http://, cookie de sesión sin Secure con SameSite=None, CORS abierto con credenciales y Caché-Control: public sobre datos de sesión. Cargar ambos y comparar los informes es una lección de auditoría en cinco minutos.

Checklist de riesgos: señales que importan

Un panel de ocho señales de riesgo con ponderación por puntos. Cada señal marcada suma y el panel muestra el nivel de riesgo con consejos de remediación:

Fíjate en el orden de prioridades que codifica la puntuación: lo más grave es exponer credenciales en claro y aceptar certificados inválidos; después vienen el downgrade y las cookies; el contenido mixto, la caché excesiva y la ausencia de HSTS cierran la lista. Es una jerarquía de riesgo razonable y defendible, útil como plantilla mental para cualquier revisión.

Quiz autocorregido

Ocho preguntas de opción múltiple con corrección y explicación inmediata. Las preguntas cubren el temario completo: qué añade HTTPS frente a HTTP claro, qué parte de la URL define el cambio de protocolo (el esquema), qué problema indica un certificado con nombre que no coincide (fallo de identidad), para qué sirve ALPN, qué condición necesita HSTS para ser aprendido de forma confiable (llegar por HTTPS válido), qué transporte usa HTTP/3 (QUIC sobre UDP con TLS 1.3 integrado), qué cabecera evita almacenar respuestas sensibles (Caché-Control: no-store) y qué señal apunta a contenido mixto. Cada respuesta, acertada o no, viene acompañada de la explicación del concepto.

Guía rápida de repaso

Seis tarjetas que resumen el método operativo: identificar el origen (esquema, host y puerto; 80 para HTTP, 443 para HTTPS), comprobar TLS (1.3 preferible, certificado coincidente con el DNS, no aceptar errores de certificado en producción), leer HTTP (método, ruta, estado y campos; GET seguro, PUT y DELETE idempotentes, las familias 2xx/3xx/4xx/5xx cuentan historias distintas), evaluar cabeceras (HSTS, CSP, cookies, caché, CORS y Alt-Svc), buscar downgrade (redirecciones a http://, contenido mixto, HSTS como mitigación) y pensar en capas (TCP para HTTP/1.1 y HTTP/2, QUIC para HTTP/3, y intermediarios que modifican la observabilidad).

Referencias oficiales y glosario

Quince fuentes primarias filtrables por categoría (HTTP, TLS, seguridad, registros) y con buscador: los RFC 9110, 9111, 9113 y 9114 para HTTP y su caché, el RFC 9846 para TLS 1.3, el RFC 7301 para ALPN, el RFC 9525 para identidad de servicio en TLS, el RFC 9000 para QUIC, el RFC 6797 para HSTS, el RFC 6265 para cookies, el Fetch Standard, el RFC 9460 para los registros SVCB/HTTPS, y los registros IANA de campos, códigos de estado y métodos HTTP. Todo estudio serio de HTTP debería empezar ahí, y el curso facilita el camino.

El glosario cierra con seis términos de campo en formato desplegable: origen, ALPN, HSTS, contenido mixto, autoridad certificadora y QUIC. Definiciones cortas y precisas, del estilo «autoridad certificadora: entidad que firma certificados para que el cliente pueda validar la identidad del servicio».

Cómo está construido: mecánica del curso

La aplicación es código abierto y está construida como una app estática con HTML, CSS y JavaScript plano, sin frameworks, sin npm, sin backend y sin paso de build: puedes descargar los ficheros y abrir index.html directamente en el navegador. La única dependencia externa es Cytoscape (cargado desde CDN) para renderizar el grafo del mapa conceptual, y el código incluye un fallback en HTML plano si la librería no está disponible, de modo que el contenido nunca queda inaccesible.

Merece la pena mirar cómo está resuelto el interior, porque hay decisiones de ingeniería cuidadosas:

• Todo el contenido vive en estructuras de datos declarativas en el script: el array de trece componentes del mapa con sus hechos y enlaces, el de nueve pasos del simulador, el de siete partes anatómicas, el de quince referencias, el de ocho señales de riesgo con su puntuación y el de ocho preguntas del quiz con su explicación. La lógica de renderizado es genérica: recorre los arrays y pinta. Añadir una pregunta o una señal de riesgo es tocar una línea de datos, no reescribir lógica.
• El laboratorio es un pequeño motor de análisis estático de cabeceras. Parsea el bloque de cabeceras que escribes (soporta la línea de estado inicial y cabeceras repetidas como múltiples Set-Cookie), extrae cada una por nombre de forma insensible a mayúsculas, y aplica reglas con expresiones regulares: parseMaxAge para la política HSTS, detección de Location que apunta a http://, comprobación de atributos Secure, HttpOnly y SameSite en cada cookie, y el patrón CORS incompatible. Cada regla emite un hallazgo con nivel (good/warn/bad) que luego se agrega en un resumen.
• Higiene de seguridad en el propio código. Todo texto dinámico pasa por una función escapeHtml antes de inyectarse en innerHTML. Irónico y coherente: un curso de seguridad web que se protege a sí mismo de inyección de HTML.
• Detalles de experiencia. Tema claro y oscuro con preferencia persistida en localStorage y regeneración del grafo al cambiar de tema (para releer los colores de las variables CSS); animaciones de aparición de secciones con IntersectionObserver y degradación elegante si no existe; roles ARIA y regiones aria-live en los paneles que se actualizan, además de un enlace de «saltar al contenido». El análisis del laboratorio ni siquiera sale del navegador: no hay fetch a ningún servicio.

La estructura de dependencias entre módulos es mínima: un init() al DOMContentLoaded encadena la configuración del tema y el renderizado de cada sección, y los eventos se registran de forma opcional con encadenamiento seguro, así que una sección rota no tumba la página entera.

Por qué esto importa cuando trabajas con IA

Aquí conecta el ángulo de IAcademy. Cada vez que un agente de IA llama a una API de terceros, envía un prompt, una clave de autenticación y quizá datos de clientes. Todo eso viaja en mensajes HTTP. Las tres garantías de HTTPS (autenticación del servidor, confidencialidad e integridad) son la diferencia entre que esa llamada sea privada y que sea legible por cualquiera en la ruta. Y las formas de romperlas son exactamente las que el curso enseña a detectar:

• MITM y errores de certificado. Un intermediario puede suplantar al servidor si el cliente no valida el certificado contra el nombre DNS, la vigencia y una cadena confiable. Esto no es teórico: el escenario clásico de fallo es un script de automatización que desactiva la verificación de certificados («verify=false», la bandera de verificación desactivada) para salir del paso con un certificado autofirmado en desarrollo, y ese código llega a producción. El curso es tajante: un certificado autofirmado puede cifrar, pero no autentica; un error de nombre es un fallo de identidad, no un aviso menor.
• Downgrade y HSTS. En la primera conexión a un host, si no hay HSTS aprendido, un atacante en la ruta puede intentar llevar la sesión de HTTPS a HTTP. HSTS (solo fiable cuando llega por HTTPS válido) cierra esa ventana en visitas futuras, y preload la cierra incluso en la primera. Si tu herramienta o agente acepta redirecciones ciegamente, leer Location es obligatorio.
• Secretos en sitios equivocados. El laboratorio detecta tokens en query strings (que acaban en logs, historial y referers), cookies sin Secure que pueden escaparse por una ruta HTTP, respuestas sensibles cacheables con Caché-Control: public y CORS con credenciales abiertas a cualquier origen. Cuatro fallos que no ocurren «en la web» en abstracto: ocurren en la API que tu integración está llamando ahora mismo.

La conclusión operativa que el curso deja clara: HTTPS protege el canal, no la aplicación. Un endpoint HTTPS con una API mal diseñada, autorización rota o datos sensibles en la URL sigue siendo un problema de seguridad; HTTPS solo garantiza que nadie ajeno leyó o modificó los mensajes en tránsito. Para quien construye sistemas con IA (agentes que se autentican, pipelines que mueven datos entre proveedores) ese matiz no es académico: define qué estás comprando realmente cuando ves el candado verde.

Cómo usar el curso: un plan de estudio concreto

El curso está publicado y funciona directamente en el navegador, sin registro ni instalación. Un plan de estudio que funciona bien en una o dos sesiones:

• Paso 1 (10 minutos): mapa conceptual. Recorre los trece nodos del mapa en orden y lee los hechos de cada uno. No te saltes el nodo del atacante en la ruta: es el que da sentido a todos los demás.
• Paso 2 (15 minutos): simulador. Avanza los nueve pasos de «De URL a respuesta» sin prisa. En cada paso, lee la traza y las comprobaciones. Si algo no encaja (¿qué es exactamente SNI?, ¿por qué ALPN va dentro del handshake?), tienes el nodo correspondiente del mapa y la referencia RFC a un clic.
• Paso 3 (15 minutos): laboratorio comparativo. Carga el perfil seguro, analiza y lee todos los hallazgos. Después carga el débil y compara. El objetivo es ser capaz de predecir qué hallazgos aparecerán antes de pulsar Analizar, no acertar. Cuando lo consigas, introduce cabeceras reales de un sitio que uses a diario.
• Paso 4 (10 minutos): checklist. Marca las ocho señales de riesgo y observa cómo evoluciona la puntuación. Después piensa en el último incidente o auditoría que viste: ¿qué señales estaban presentes?
• Paso 5 (10 minutos): quiz. Responde las ocho preguntas sin mirar. Cualquier fallo señala la sección a repasar; la explicación de cada respuesta te lleva de vuelta al concepto.
• Paso 6 (abierto): referencias. Deja la sección de RFC como marcador de estudio. El filtro por tema permite, por ejemplo, ver solo las cuatro especificaciones de TLS cuando toque profundizar en criptografía.

Como cierre, un ejercicio de transferencia directo al mundo de la IA: coge la documentación de la API de tu proveedor de modelos favorito y responde con el método del curso. ¿El endpoint es https:// con TLS moderno? ¿La clave va en una cabecera Authorization o se filtra en la URL? ¿Qué cabeceras devuelve y qué política de caché aplica a las respuestas? Si sabes responder a eso, el curso ha cumplido su función.

Preguntas frecuentes

¿Necesito conocimientos previos para seguir el curso?

No exige formación específica previa más allá de manejo básico de navegador y cierta familiaridad con la web. El curso va de lo básico (qué es un esquema, qué es un origen) hasta nivel profesional (handshake TLS 1.3, validación de certificados según RFC 9525, registros HTTPS/SVCB), construyendo cada concepto sobre el anterior. Para estudiantes de redes, ciberseguridad y administración de sistemas es una progresión natural.

¿El laboratorio envía mis datos a algún servidor?

No. El análisis es completamente local: el código JavaScript ejecuta en tu navegador las reglas sobre la URL, el estado TLS, el certificado y las cabeceras que introduces, y el informe se genera sin ninguna petición de red. Puedes usarlo con cabeceras reales de entornos internos sin exponer nada.

¿Qué es exactamente un ataque de intermediario (MITM) y cómo lo frena HTTPS?

Un MITM es un atacante situado en la ruta entre cliente y servidor que lee o modifica el tráfico. En HTTP claro puede hacerlo sin restricciones. HTTPS lo frena en dos frentes: el certificado TLS autentica que el servidor es quien dice ser (un impostor no tendría un certificado válido para ese nombre DNS) y el cifrado con integridad impide leer o alterar los mensajes en tránsito. La condición es que la validación del certificado sea correcta: si aceptas un error de certificado, la protección de identidad desaparece.

¿Qué NO protege HTTPS?

HTTPS protege el canal: confidencialidad e integridad de los mensajes en tránsito y autenticación del servidor. No protege la aplicación: no arregla autorizaciones rotas, no evita inyecciones, no impide que metas secretos en la URL (que quedan en logs e historial aunque vaya cifrado), no protege cookies sin Secure si existe una ruta HTTP, no impide CORS mal configurado ni contenido mixto, y no hace nada por datos que el propio servidor cachea o filtra después. El curso dedica secciones enteras a estos límites.

¿Por qué HSTS solo se puede aprender por HTTPS?

Porque si un cliente aceptara una cabecera Strict-Transport-Security llegada por HTTP sin proteger, un atacante en la ruta podría inyectarla o manipularla. La especificación (RFC 6797) exige que la política solo se aprenda sobre una conexión HTTPS con certificado válido. Por eso el laboratorio marca «HSTS por canal claro» como aviso: es una contradicción de diseño.

¿Qué diferencia hay entre TLS y HTTPS?

TLS es un protocolo de seguridad que proporciona autenticación, cifrado e integridad a cualquier canal; HTTPS es el resultado de transportar HTTP dentro de TLS. La semántica HTTP (métodos, estados, cabeceras) no cambia: lo que cambia es el canal. Esa separación es el modelo mental central del curso.

¿El curso cubre HTTP/2 y HTTP/3?

Sí, aunque como contexto de transporte, no como curso de framing. Explica que HTTP/2 multiplexa solicitudes sobre una conexión TCP habitualmente protegida con TLS y negociada por ALPN, y que HTTP/3 funciona sobre QUIC (UDP) con TLS 1.3 integrado, anunciado mediante Alt-Svc. Incluye los RFC 9113, 9114, 9000 y 9846 entre las referencias.

¿Puedo usar el material como base de formación en mi equipo?

Sí. Al ser un proyecto educativo de código abierto con contenido verificable contra especificaciones oficiales, funciona bien como material de estudio autónomo o como taller guiado: la sesión de laboratorio comparando el perfil seguro y el débil, seguida del checklist de riesgos, da para una sesión formativa completa sobre criterio de seguridad web.