Guía para reducir la latencia TLS en Nginx: optimizar handshakes, OCSP stapling y ciphers en VPS con CPU limitada

Por · Publicado el · 9 min de lectura

Cables de fibra óptica con conectores en un panel de parcheo de rack de red
Detalle de cables de fibra y conectores en un panel de red para infraestructura de servidores. Foto: Brett Sayles / Pexels

Esta guía muestra, de forma práctica, cómo reducir la latencia TLS en Nginx optimizando handshakes, OCSP stapling y ciphers en VPS con CPU limitada. Verás decisiones de compatibilidad, configuraciones de ejemplo y cómo medir los beneficios. El objetivo es ahorrar ciclos de CPU sin sacrificar seguridad, priorizando TLS 1.3, reuso de conexiones y elecciones de curvas, certificados y cifras eficientes.

Por qué el handshake penaliza en VPS con CPU baja

El handshake TLS realiza operaciones criptográficas costosas: claves efímeras, verificación de certificados y generación de secretos. En VPS con pocos vCPU, cada conexión nueva consume tiempo y CPU. Reducimos esa presión por tres vías: bajar el número de handshakes, abaratar cada handshake y evitar validaciones externas innecesarias.

La estrategia práctica combina: TLS 1.3 + TLS 1.2 bien seleccionados, ECDSA con fallback a RSA, curvas rápidas, OCSP stapling correcto, reuso de sesiones y conexiones, y un conjunto compacto de ciphers. Además, las mediciones guían los ajustes siguientes.

Si aún no tienes automatizada la obtención de certificados, mira cómo generar certificado SSL gratis.

  • Reducir la cantidad de handshakes: keep-alive y reanudación de sesión.
  • Abaratar cada handshake: ECDHE con X25519 y ECDSA.
  • Evitar validaciones externas: OCSP stapling con caché local.
  • Medir e iterar: observar tiempos de appconnect y errores OCSP.

TLS 1.3, curvas elípticas y certificados (ECDSA + fallback RSA)

TLS 1.3 reduce los round-trips y simplifica las ciphers. Mantén TLS 1.2 para compatibilidad. Prefiere curvas X25519 y P‑256, que son rápidas. ECDSA suele producir handshakes menos costosos que RSA. Cargar un certificado ECDSA y otro RSA permite negociar lo mejor según el cliente.

La configuración siguiente activa TLS 1.3 y 1.2, define curvas eficientes y carga certificados ECDSA y RSA. Usa las rutas reales de tus archivos y asegura la cadena completa en el certificado.

ssl_protocols TLSv1.3 TLSv1.2;
ssl_ecdh_curve X25519:P-256;
# ECDSA (principal)
ssl_certificate     /etc/ssl/certs/site_ecdsa_fullchain.pem;
ssl_certificate_key /etc/ssl/private/site_ecdsa.key;
# RSA (fallback)
ssl_certificate     /etc/ssl/certs/site_rsa_fullchain.pem;
ssl_certificate_key /etc/ssl/private/site_rsa.key;

OCSP stapling para evitar latencia por validación

Sin stapling, el cliente consulta a la CA, añadiendo latencia impredecible. Con OCSP stapling, el servidor envía la prueba de validez durante el handshake, reduciendo la espera en el primer acceso y mejorando la fiabilidad.

Para que funcione, Nginx necesita el certificado raíz/intermedio confiable. Sin ssl_trusted_certificate, el stapling falla silenciosamente. Configura también un resolver fiable para descargar las respuestas OCSP.

  • Revisa los logs de error de Nginx al habilitar stapling.
  • Renueva certificados y monitoriza la validez de la respuesta OCSP.
  • Evita resolvers lentos; eso afecta la actualización del OCSP.
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/ssl/certs/ca_chain.pem;
resolver 1.1.1.1 1.0.0.1 valid=300s;
resolver_timeout 5s;

Reducir handshakes nuevos: keep‑alive y reanudación de sesión

Mantener conexiones activas y reutilizar sesiones TLS ahorra CPU. En sitios con muchos recursos, esto reduce picos de uso y mejora el TTFB medio. Rotar claves de tickets con cuidado para no invalidar todas las sesiones a la vez.

Ajusta keep‑alive, caché de sesiones y tickets. En entornos con múltiples instancias, comparte la clave de tickets entre nodos para mantener la reanudación tras despliegues.

  • Keep‑alive reduce nuevos handshakes en navegaciones secuenciales.
  • Cache de sesión y tickets permiten reanudar la sesión TLS.
  • Rota tickets periódicamente y con solapamiento.
# HTTP keep‑alive
keepalive_timeout 60;
keepalive_requests 1000;

# TLS session resumption
ssl_session_cache shared:SSL:50m;
ssl_session_timeout 1d;
ssl_session_tickets on;
# Gere e rotacione esta chave com segurança
ssl_session_ticket_key /etc/nginx/ticket.key;

Ciphers reducidas y orden que favorece la CPU del cliente

En TLS 1.2, mantén solo AEADs modernas. ChaCha20‑Poly1305 va muy bien en CPUs sin AES‑NI. AES‑GCM es excelente cuando existe aceleración por hardware. Una lista corta acelera la negociación y evita problemas de compatibilidad.

Deja que el cliente decida la preferencia cuando sea apropiado. Así los dispositivos con AES‑NI usarán AES‑GCM y, sin AES‑NI, elegirán ChaCha20. Si tus mediciones muestran mejor rendimiento con ChaCha20 siempre, activa la preferencia del servidor y coloca ChaCha20 primero.

  • Elimina DHE y ciphers obsoletos (CBC/RC4).
  • Mantén ECDHE para forward secrecy.
  • TLS 1.3 ya define ciphers seguras por defecto.
# Para TLS 1.2
ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:
             ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256';
# Deixe o cliente decidir (bom para diversidade de hardware)
ssl_prefer_server_ciphers off;

0‑RTT (TLS 1.3): uso y mitigación de replays

0‑RTT elimina un round‑trip en retomadas, pero permite replays. Utilízalo solo para operaciones idempotentes, como GET de contenido estático. Nunca aceptes 0‑RTT en endpoints que modifiquen estado.

El ejemplo siguiente habilita 0‑RTT y responde 425 cuando llegan métodos no seguros con early data. Ajusta la lista si tienes endpoints explícitamente idempotentes.

# Bloqueie early data em métodos não idempotentes
map "$request_method:$ssl_early_data" $early_reject {
    "~^(POST|PUT|PATCH|DELETE|OPTIONS):1$" 1;
    default 0;
}
server {
    ssl_early_data on;
    if ($early_reject) { return 425; }
}

Otras palancas rápidas: HSTS, HTTP/2 y matices de despliegue

HSTS evita redirecciones HTTP→HTTPS después de la primera visita. No cambia el handshake, pero reduce viajes adicionales. HTTP/2 consolida conexiones y disminuye nuevos handshakes en páginas con muchos recursos.

En despliegues, rota claves de tickets con solapamiento. Monitoriza errores de stapling tras la renovación de certificados. Para terminación TLS fuera de Nginx, consulta el tutorial de HAProxy con Let's Encrypt.

  • Activa HSTS con cuidado en dominios principales.
  • Planifica rollback de tickets en ventanas de bajo tráfico.
  • Sigue los logs de Nginx para OCSP y handshakes.
# HSTS (comece com um max‑age conservador)
add_header Strict-Transport-Security "max-age=15552000; includeSubDomains" always;

# HTTP/2
listen 443 ssl http2;

Cómo medir: tiempos de handshake, stapling y compatibilidad

Mide antes y después. Observa appconnect con curl. Verifica que el OCSP stapling viene del servidor. Comprueba las versiones y el soporte de tu Nginx/OpenSSL. En producción, repite pruebas desde varios lugares y dispositivos.

Para profundizar en TLS en Nginx y PKI, consulta la guía de mTLS entre Nginx y microservicios y la checklist de seguridad para VPS.

  • Ejecuta múltiples muestras y descarta outliers.
  • Prueba clientes con y sin AES‑NI (desktop vs mobile).
  • Valida que el fallback RSA atiende a clientes antiguos.
# Tempo até appconnect (handshake concluído)
curl -sS -o /dev/null -w 'connect=%{time_connect} appconnect=%{time_appconnect}\n' https://seusite.com

# Verificar OCSP stapling
openssl s_client -connect seusite.com:443 -status < /dev/null 2>/dev/null | sed -n '/OCSP response:/,/-----END/,/-----END/p'

# Conferir build
nginx -V 2>&1 | tr ' ' '\n' | egrep 'nginx|OpenSSL'

Checklist de priorización: impacto vs riesgo

Usa este cuadro para decidir el orden de los cambios. Comienza por lo que rinde más en CPU/latencia con bajo riesgo. Luego avanza a ítems que requieren más pruebas y observabilidad. Documenta el rollback para cada paso.

Ajuste Impacto esperado Riesgo de compatibilidad Cuándo aplicar
OCSP stapling correcto Baja latencia inicial Bajo Siempre que uses CA pública
Session resumption (cache+tickets) Menos CPU por conexión Medio Después de validar la rotación de tickets
TLS 1.3 + curvas X25519/P‑256 Menos RTT y handshakes más rápidos Bajo Entornos con clientes modernos
ECDSA + fallback RSA Menor CPU en handshakes Bajo a medio Cuando puedas emitir ambos certificados
Ciphers reducidas (AEADs) Menor coste y negociación Bajo Eliminar legados y CBC
0‑RTT selectivo Menos RTT en retomadas Medio a alto Solo en GET/HEAD idempotentes

Preguntas frecuentes

¿TLS 1.3 siempre reduce la latencia del handshake?

En general sí, porque simplifica la negociación y puede reducir un round‑trip. Aun así, mantén TLS 1.2 por compatibilidad. La ganancia real depende del cliente, la red y del reuso de conexiones y sesiones en tu caso.

¿Debo priorizar ChaCha20‑Poly1305 o AES‑GCM en los ciphers?

Depende del hardware del cliente. En dispositivos con AES‑NI, AES‑GCM es muy rápido. Sin AES‑NI, ChaCha20 suele ganar. Dejar que el cliente elija es una opción segura. Mide según tu audiencia.

¿OCSP stapling sustituye la verificación del cliente con la CA?

El servidor anticipa y envía la prueba de validez en el handshake, reduciendo las consultas del cliente. Pero el cliente sigue determinando cómo validar. Configura ssl_trusted_certificate y monitoriza la actualización de la respuesta OCSP.

¿0‑RTT es seguro para APIs?

0‑RTT permite replays. Evítalo en endpoints que modifiquen estado. Si lo usas, limítalo a métodos idempotentes y considera negar early data por defecto, devolviendo 425, y aceptar solo en rutas muy específicas.

¿Session tickets o session cache: cuál elegir?

Usa ambos. La caché compartida ayuda a procesos de Nginx. Los tickets permiten reanudación sin estado en el servidor, útiles en entornos escalados. Planifica la rotación de claves de tickets y prueba compatibilidad tras renovaciones.

¿HSTS reduce la latencia del TLS?

HSTS no cambia el coste del handshake, pero evita el redireccionamiento HTTP→HTTPS en visitas posteriores. Eso reduce viajes extra y mejora el tiempo total percibido por el usuario después de la primera navegación.

¿Quieres revisar tu configuración TLS en Nginx?

Si necesitas una segunda opinión técnica o quieres aplicar estas optimizaciones con seguridad, hablemos sobre tu entorno y objetivos.

Hablar sobre optimización TLS

Ver también