SSL/TLS: conceptos clave y protocolos en el desarrollo

¿Qué es SSL/TLS?

SSL (Secure Sockets Layer) y TLS (Transport Layer Security) son protocolos criptográficos que garantizan la transmisión segura de datos a través de la red. SSL, desarrollado por Netscape en la década de 1990, se considera obsoleto después de la versión 3.0 debido a las vulnerabilidades POODLE y BEAST. TLS, su sucesor, ha pasado por las versiones 1.0, 1.1, 1.2 y 1.3; solo TLS 1.2 y TLS 1.3 se consideran actuales. Todas las plataformas móviles modernas exigen TLS para las conexiones de red, y App Store y Google Play lo verifican durante la revisión.

¿Por qué TLS para aplicaciones móviles?

Sin TLS, el tráfico entre la aplicación y el servidor se transmite como texto plano: cualquiera en la misma red Wi-Fi puede interceptar inicios de sesión, contraseñas, tokens y datos personales de los usuarios mediante Wireshark o tcpdump. TLS cifra todos los datos transmitidos (cifrado a nivel de transporte) y verifica la autenticidad del servidor mediante una cadena de certificados X.509. Según IETF (2018), TLS 1.3 utiliza solo cifrados AEAD modernos (AES-GCM, ChaCha20-Poly1305), excluyendo algoritmos obsoletos como RC4 y 3DES.

HTTPS y TLS

HTTPS (HTTP Secure) es HTTP sobre TLS. Cuando una aplicación móvil realiza una solicitud mediante https://, primero establece una conexión TLS con el servidor y luego transmite los encabezados HTTP y el cuerpo de la solicitud a través del canal cifrado. Sin HTTPS, ninguna API seria debería funcionar: es la higiene básica de seguridad. Según OWASP (2026), las conexiones no seguras se encuentran entre las 3 principales vulnerabilidades de las aplicaciones móviles.

Cómo funciona TLS Handshake

TLS Handshake es el proceso de establecimiento de una conexión segura entre un cliente y un servidor. Las partes negocian la versión del protocolo, seleccionan un conjunto de cifrado (cipher suite), intercambian claves mediante criptografía asimétrica y verifican los certificados. En TLS 1.2, el handshake requiere 2 Round Trip Time (2 RTT): cliente → servidor con ClientHello, servidor → cliente con ServerHello y Certificate, luego los mensajes finales Finished. TLS 1.3 reduce este proceso a 1 RTT.

Etapas detalladas del handshake TLS 1.2

Primera etapa: ClientHello — el cliente envía las versiones TLS compatibles, una lista de conjuntos de cifrado y un número aleatorio. El servidor responde con ServerHello, seleccionando una versión y un conjunto de cifrado, envía su certificado X.509 (Certificate) y el mensaje ServerHelloDone. El cliente verifica el certificado mediante una cadena de autoridades de certificación (CA) de confianza, genera un secreto pre-maestro, lo cifra con la clave pública del certificado y lo envía al servidor en ClientKeyExchange. Después de esto, ambas partes generan claves de sesión e intercambian los mensajes ChangeCipherSpec y Finished. A partir de este momento, todos los datos se cifran de forma simétrica.

import Security

let url = URL(string: "https://api.example.com")!
let session = URLSession(configuration: .default,
                           delegate: self,
                           delegateQueue: nil)

func urlSession(
    _ session: URLSession,
    didReceive challenge: URLAuthenticationChallenge,
    completionHandler: @escaping (URLSession.AuthChallengeDisposition,
                                    URLCredential?) -> Void
) {
    let trust = challenge.protectionSpace.serverTrust
    guard let trust else {
        completionHandler(.cancelAuthenticationChallenge, nil)
        return
    }
    completionHandler(.useCredential, URLCredential(trust: trust))
}

Ejemplo de manejo de URLAuthenticationChallenge en iOS mediante URLSessionDelegate. Este método se llama durante cada TLS Handshake, permitiendo que la aplicación realice una verificación personalizada del certificado del servidor. Para uso en producción, agregue la verificación del certificado mediante SecTrustEvaluateWithError y compárelo con una huella preguardada; solo entonces llame a useCredential.

TLS 1.2 vs TLS 1.3

TLS 1.3 (RFC 8446, 2018) es la primera actualización importante del protocolo en 10 años. Principales mejoras: handshake reducido a 1 RTT (0 RTT para conexiones repetidas), eliminación de conjuntos de cifrado obsoletos (intercambio de claves RSA, modo CBC), Perfect Forward Secrecy (PFS) obligatorio y protección contra ataques de degradación mediante signed transcript. Según Qualys SSL Labs (2026), TLS 1.3 proporciona protección incluso cuando la clave del servidor a largo plazo se ve comprometida gracias a PFS.

0-RTT (Zero Round Trip Time) es una característica de TLS 1.3 que permite al cliente enviar datos inmediatamente junto con ClientHello durante una conexión repetida mediante PSK (Pre-Shared Key). Esto acelera la carga de pantallas posteriores en aplicaciones móviles, especialmente con solicitudes frecuentes al mismo servidor. Sin embargo, los datos 0-RTT no están protegidos contra ataques de repetición: pueden ser interceptados y reenviados. Utilice 0-RTT solo para solicitudes idempotentes (GET, PUT) sin efectos secundarios.

TLS en iOS: App Transport Security

App Transport Security (ATS) es el mecanismo de Apple que exige conexiones HTTPS con TLS 1.2 o superior, activado de forma predeterminada desde iOS 9. ATS bloquea todas las conexiones HTTP y HTTPS con TLS inferior a 1.2. El desarrollador puede configurar excepciones en Info.plist mediante NSAppTransportSecurity para dominios específicos, pero Apple recomienda minimizar las excepciones y usar HTTPS en todas partes. Violar los requisitos de ATS es motivo de rechazo de la aplicación en la revisión de App Store.

<!-- Info.plist — App Transport Security -->
<key>NSAppTransportSecurity</key>
<dict>
    <key>NSAllowsArbitraryLoads</key>
    <false/>
    <key>NSExceptionDomains</key>
    <dict>
        <key>cdn.example.com</key>
        <dict>
            <key>NSExceptionAllowsInsecureHTTPLoads</key>
            <false/>
            <key>NSExceptionMinimumTLSVersion</key>
            <string>TLSv1.2</string>
        </dict>
    </dict>
    <key>NSAllowsLocalNetworking</key>
    <true/>
</dict>

Configuración de ATS en Info.plist. NSAllowsArbitraryLoads está establecido en false: todas las conexiones deben usar HTTPS. Para el dominio cdn.example.com, se especifica una versión mínima de TLS 1.2, NSAllowsLocalNetworking=true permite HTTP para la red local (útil para servidores de desarrollo). Apple recomienda encarecidamente no activar NSAllowsArbitraryLoads sin NSExceptionDomains: esto debería ser una excepción, no una regla general.

TLS en Android: Network Security Config

Network Security Config es el mecanismo de Android para configurar HTTPS y TLS sin cambiar el código Java/Kotlin. La configuración se especifica en el archivo network_security_config.xml y se conecta en AndroidManifest mediante el atributo android:networkSecurityConfig. Admite la configuración de certificados de confianza (CA de usuario y sistema), Certificate Pinning, desactivación de HTTP en texto claro, anulaciones de depuración y redirección de tráfico.

<!-- res/xml/network_security_config.xml -->
<network-security-config>
    <base-config cleartextTrafficPermitted="false">
        <trust-anchors>
            <certificates src="system" />
        </trust-anchors>
    </base-config>
    <domain-config cleartextTrafficPermitted="false">
        <domain includeSubdomains="true">api.example.com</domain>
        <pin-set expiration="2027-01-01">
            <pin digest="SHA-256">
                47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=
            </pin>
        </pin-set>
    </domain-config>
</network-security-config>

Network Security Config para Android. Base-config bloquea el tráfico en texto claro y confía solo en los certificados CA del sistema (sin certificados de usuario, protección contra la instalación de certificados MitM por parte de los usuarios). Domain-config para api.example.com contiene un pin-set con una huella SHA-256 del certificado. Si el certificado del servidor cambia antes de la fecha de vencimiento especificada, la conexión será rechazada: esta es una forma estricta de Certificate Pinning.

Certificate Pinning y seguridad

Certificate Pinning es una técnica de fijación del certificado o clave pública del servidor en el código de la aplicación. Durante cada TLS Handshake, el cliente compara el certificado del servidor con una huella preguardada (hash SHA-256). Incluso si un atacante obtiene un certificado CA de confianza o compromete la autoridad de certificación, no puede realizar un ataque MitM: la aplicación verifica la huella específica, no la cadena CA. Esto es especialmente importante para aplicaciones financieras y aquellas que manejan datos sensibles.

Riesgos y alternativas al Pinning

Certificate Pinning requiere precaución: cuando el certificado del servidor cambia, todas las versiones anteriores de la aplicación dejarán de conectarse. Se recomienda almacenar varias huellas de respaldo (principal + respaldo), especificar una fecha de vencimiento del pin-set e implementar un mecanismo de respaldo mediante verificación CA estándar. Una alternativa es Trust On First Use (TOFU), donde la aplicación recuerda el certificado en la primera conexión y advierte al usuario cuando cambia. Según OWASP (2026), la ausencia de Certificate Pinning se encuentra entre las 3 principales vulnerabilidades de las aplicaciones móviles (M3: Comunicación insegura).

Implementación de Pinning en Alamofire

En Alamofire 5+, Certificate Pinning se configura mediante ServerTrustManager con PinnedCertificatesTrustEvaluator (verificación del certificado completo) o PublicKeysTrustEvaluator (solo la clave pública). La clave pública es preferible: no cambia cuando se renueva el certificado con el mismo CA. Cree un ServerTrustManager con un diccionario [host: evaluator], páselo a Session y utilícelo para todas las solicitudes a API protegidas.