HTTP/HTTPS: qué es, protocolos de transferencia de datos y cifrado TLS

¿Qué son HTTP y HTTPS?

HTTP (HyperText Transfer Protocol) es un protocolo de nivel de aplicación del modelo OSI diseñado para transferir documentos hipertexto y otros datos en la World Wide Web. Desarrollado por Tim Berners-Lee en 1989, HTTP ha pasado por varias versiones: desde HTTP/0.9 (solo solicitudes GET y respuestas HTML) hasta los modernos HTTP/2 y HTTP/3. El protocolo funciona según el modelo solicitud-respuesta: el cliente envía una solicitud al servidor, el servidor la procesa y devuelve una respuesta.

HTTPS (HTTP Secure) es una extensión del protocolo HTTP que añade una capa de cifrado mediante TLS (Transport Layer Security). HTTPS no es un protocolo separado — es una combinación de HTTP y TLS. Los datos transmitidos a través de HTTPS se cifran en el lado del cliente y se descifran en el servidor, lo que los hace inaccesibles para la interceptación y manipulación. HTTPS también proporciona autenticación del servidor mediante certificados SSL/TLS, garantizando que el cliente se conecta al servidor real y no a un atacante.

La diferencia clave entre HTTP y HTTPS es la seguridad. HTTP transmite datos en texto plano: cualquier nodo de la red entre el cliente y el servidor puede leer el contenido de una solicitud o respuesta. HTTPS cifra todo el contenido, incluyendo la URL, los encabezados y el cuerpo de la solicitud, dejando visible solo la dirección IP del servidor y el puerto de conexión. Para las aplicaciones móviles que operan a través de redes Wi-Fi públicas, HTTPS es un requisito de seguridad obligatorio.

Cómo funciona HTTP

HTTP es un protocolo sin estado (stateless) que funciona sobre TCP/IP. El cliente establece una conexión TCP con el servidor (generalmente en el puerto 80 para HTTP o 443 para HTTPS), envía una solicitud HTTP, recibe una respuesta HTTP y cierra la conexión (en HTTP/1.1 la conexión puede reutilizarse). Cada interacción entre el cliente y el servidor consiste en una solicitud y una respuesta. La ausencia de estado significa que el servidor no almacena información sobre solicitudes anteriores del cliente — cada solicitud se procesa de forma independiente.

El proceso de interacción HTTP incluye los siguientes pasos:

• Resolución DNS — el navegador o cliente convierte el nombre de dominio en una dirección IP mediante DNS
• Handshake TCP — se establece una conexión TCP mediante un handshake de tres vías (SYN, SYN-ACK, ACK)
• Handshake TLS — para HTTPS, se establece adicionalmente una conexión cifrada (intercambio de certificados y claves)
• Solicitud HTTP — el cliente envía el método, URL, encabezados y opcionalmente el cuerpo de la solicitud
• Respuesta HTTP — el servidor devuelve un código de estado, encabezados y cuerpo de la respuesta

Una característica importante de HTTP es la idempotencia de métodos. GET, HEAD, PUT, DELETE y OPTIONS son idempotentes: la ejecución repetida de la misma solicitud no cambia el estado del servidor después de la primera ejecución. POST, PATCH y CONNECT no son idempotentes — cada llamada puede crear un nuevo recurso o cambiar el estado. Para el desarrollo móvil, comprender la idempotencia es crítico: al reenviar una solicitud debido a un error de red, el cliente debe saber si es seguro repetir la solicitud.

HTTPS y cifrado TLS

HTTPS utiliza el protocolo criptográfico TLS (Transport Layer Security) para proteger los datos transmitidos. TLS es el sucesor de SSL (Secure Sockets Layer), que fue desarrollado por Netscape en 1995. Las versiones SSL 2.0 y 3.0 se consideran obsoletas e inseguras; las versiones modernas TLS 1.2 (lanzada en 2008) y TLS 1.3 (lanzada en 2018) se utilizan en todas partes. TLS 1.3, en particular, reduce el tiempo de establecimiento de conexión de 2 round-trips a 1, lo que acelera significativamente la carga en dispositivos móviles.

El proceso de handshake TLS incluye las siguientes etapas:

• Client Hello — el cliente envía una lista de versiones TLS compatibles y conjuntos de cifrado
• Server Hello — el servidor selecciona la versión TLS y el conjunto de cifrado, envía su certificado SSL/TLS
• Verificación del certificado — el cliente verifica el certificado del servidor a través de una cadena de confianza hasta la CA raíz
• Intercambio de claves — el cliente y el servidor generan una clave secreta compartida (clave de sesión)
• Cambio de cifrado — ambas partes confirman la transición a la comunicación cifrada

La verificación del certificado SSL/TLS es una etapa crítica para la seguridad. El cliente comprueba que el certificado: no ha caducado, está firmado por una autoridad de certificación (CA) de confianza, coincide con el dominio en la URL y no ha sido revocado (mediante CRL u OCSP). En las aplicaciones móviles, se recomienda utilizar Certificate Pinning — la vinculación a un certificado específico del servidor o clave pública. Esto previene ataques MITM incluso en caso de compromiso de una CA. Sin embargo, el pinning requiere precaución: cuando el certificado cambia, la aplicación debe actualizarse con antelación.

Estructura de una solicitud y respuesta HTTP

Una solicitud HTTP consta de tres partes: la línea de solicitud, los encabezados y un cuerpo opcional. La línea de solicitud contiene el método HTTP, la URL de la solicitud y la versión de HTTP. Los encabezados transmiten metainformación: tipo de contenido, tokens de autenticación, configuraciones de caché. El cuerpo solo está presente en métodos que transmiten datos (POST, PUT, PATCH) y está ausente en GET y DELETE.

Ejemplo de una solicitud HTTP a una API REST:

POST /api/v1/users HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
Cache-Control: no-cache

{
    "name": "Anna",
    "email": "anna@example.com"
}

Una respuesta HTTP tiene una estructura similar: una línea de estado con la versión HTTP y el código de estado, encabezados y cuerpo. El código de estado es un número de tres dígitos que determina el resultado del procesamiento de la solicitud. Los encabezados de respuesta incluyen Content-Type, Content-Length, Cache-Control, Set-Cookie y otros. El cuerpo de la respuesta contiene los datos solicitados en el formato especificado en Content-Type (generalmente JSON para API, HTML para páginas web, imágenes para contenido multimedia).

Los encabezados desempeñan un papel crítico en el funcionamiento de HTTP. Content-Type y Accept controlan el formato de los datos. Authorization transmite tokens de acceso. Cache-Control gestiona el almacenamiento en caché. Los encabezados CORS (Access-Control-Allow-Origin) controlan el acceso desde otros dominios en los navegadores. User-Agent identifica la aplicación cliente. Para las aplicaciones móviles, los encabezados de control de caché son especialmente importantes: ayudan a reducir la cantidad de datos transmitidos y mejoran el rendimiento con señales débiles.

Códigos de estado HTTP

Los códigos de estado HTTP se agrupan en cinco clases, indicadas por el primer dígito: 1xx (informativo), 2xx (éxito), 3xx (redirección), 4xx (error del cliente), 5xx (error del servidor). Comprender estos códigos es necesario para manejar correctamente las respuestas en una aplicación móvil: 2xx significa éxito y los datos se pueden mostrar, 4xx indica un problema en la solicitud (mostrar un error al usuario), 5xx indica un problema en el servidor (reintentar la solicitud más tarde).

Para las aplicaciones móviles, el manejo del código 401 Unauthorized es especialmente importante. Al recibir este código, el cliente debe intentar actualizar el token de acceso mediante un Refresh Token y reintentar la solicitud original. Si la actualización del token también devuelve 401, el usuario debe ser redirigido a la pantalla de inicio de sesión. Esta lógica generalmente se implementa en un Interceptor (OkHttp) o en la capa de middleware del cliente de red.

HTTP/1.1, HTTP/2 y HTTP/3

HTTP/1.1, publicado en 1999, sigue siendo una versión ampliamente utilizada del protocolo. Su principal inconveniente es el head-of-line blocking: las solicitudes al mismo servidor se ejecutan secuencialmente, cada una espera a que finalice la anterior. Para evitar esta limitación, los navegadores abren de 6 a 8 conexiones TCP paralelas al mismo dominio, lo que aumenta la carga del servidor y el consumo de memoria. HTTP/1.1 también transmite encabezados en texto plano y no admite server push.

HTTP/2 (2015) resuelve el problema de bloqueo mediante multiplexación: múltiples flujos de datos se transmiten simultáneamente a través de una sola conexión TCP. El servidor puede enviar recursos al cliente antes de que el cliente los solicite (server push). HTTP/2 también comprime los encabezados mediante HPACK, lo que reduce la cantidad de datos transmitidos. Para las aplicaciones móviles, HTTP/2 es especialmente útil: una conexión reemplaza varias, reduciendo el tiempo de handshake TLS y el consumo de batería.

HTTP/3 (2022) es la última versión del protocolo, que utiliza QUIC (Quick UDP Internet Connections) en lugar de TCP. QUIC funciona sobre UDP, eliminando el problema de head-of-line blocking a nivel del protocolo de transporte. HTTP/3 reduce el tiempo de establecimiento de conexión a 0 round-trips en el mejor de los casos (en conexiones repetidas) y a 1 round-trip en la primera conexión, lo que es significativamente más rápido que HTTP/2 con sus 2-3 round-trips. Para dispositivos móviles, HTTP/3 es especialmente efectivo al cambiar entre Wi-Fi y redes móviles: la conexión no se interrumpe porque QUIC utiliza un identificador de conexión en lugar de una dirección IP.

HTTPS en el desarrollo móvil

El uso de HTTPS en aplicaciones móviles no es una recomendación, sino un requisito obligatorio. A partir de Android 9 (API 28) e iOS 9 (ATS — App Transport Security), todas las solicitudes de red deben usar HTTPS por defecto. Las solicitudes HTTP son bloqueadas por el sistema, y permitirlas requiere una excepción explícita en la configuración de la aplicación. Google Play Store y App Store rechazan las aplicaciones que transmiten datos confidenciales a través de HTTP, incluyendo contraseñas, tokens y datos personales.

La configuración de HTTPS en una aplicación móvil Android incluye:

<!-- AndroidManifest.xml — permiso de solicitud de red -->
<uses-permission android:name="android.permission.INTERNET" />

<!-- network_security_config.xml — configuración de HTTPS -->
<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <domain-config cleartextTrafficPermitted="false">
        <domain includeSubdomains="true">api.example.com</domain>
        <pin-set expiration="2027-12-31">
            <pin digest="SHA-256">rDjsFv3bGf...</pin>
        </pin-set>
    </domain-config>
</network-security-config>

En iOS, una configuración similar se realiza a través de Info.plist con la clave NSAppTransportSecurity. Para depurar el tráfico HTTPS en aplicaciones móviles, se utilizan herramientas proxy: Charles Proxy, Proxyman o mitmproxy. Requieren instalar un certificado SSL de confianza en el dispositivo. En las compilaciones de producción, se deben deshabilitar las capacidades de depuración y verificar que Certificate Pinning esté configurado correctamente. El uso de OkHttp en Android con su CertificatePinner o TrustManager en iOS con SecTrustEvaluate son enfoques estándar para implementar pinning.

Un aspecto importante de seguridad de HTTPS en el desarrollo móvil es SSL Pinning. Sin pinning, la aplicación confía en cualquier certificado firmado por una CA conocida. Si la CA se ve comprometida, un atacante podría interceptar el tráfico de la aplicación. Pinning vincula la aplicación a un certificado específico del servidor o clave pública. Cuando el certificado del servidor cambia, se debe publicar una actualización de la aplicación, por lo que el pinning se planifica con margen: vinculación a un certificado CA de nivel superior o el uso de varias claves de respaldo.