BLOG | NGINX

Descarga, cifrado y certificados SSL/TLS con NGINX y NGINX Plus

NGINX - Parte de F5 - horizontal, negro, tipo RGB
Miniatura de Rick Nelson
Rick Nelson
Publicado el 30 de abril de 2014

NGINX y NGINX Plus ofrecen una serie de características que le permiten gestionar la mayoría de los requisitos SSL/TLS. Utilizan OpenSSL y la potencia de los chips de procesador estándar para proporcionar un rendimiento SSL/TLS rentable. A medida que la potencia de los chips de procesador estándar continúa aumentando y los proveedores de chips agregan soporte de aceleración criptográfica, la ventaja de costo de usar chips de procesador estándar en lugar de chips SSL/TLS especializados también continúa ampliándose.

Descifrar el tráfico HTTPS en NGINX ofrece numerosas ventajas.

Hay tres casos de uso principales para NGINX y NGINX Plus con SSL/TLS.

Descarga de SSL/TLS

Cuando se utiliza NGINX como proxy, puede descargar el procesamiento de descifrado SSL de los servidores back-end. Existen varias ventajas al realizar el descifrado en el proxy:

  • Rendimiento mejorado: el mayor impacto en el rendimiento al realizar el descifrado SSL es el protocolo de enlace inicial. Para mejorar el rendimiento, el servidor que realiza el descifrado almacena en caché los ID de sesión SSL y administra los tickets de sesión TLS. Si esto se hace en el proxy, todas las solicitudes del mismo cliente pueden usar los valores almacenados en caché. Si se hace en los servidores backend, entonces cada vez que las solicitudes del cliente van a un servidor diferente, el cliente debe volver a autenticarse. El uso de tickets TLS puede ayudar a mitigar este problema, pero no todos los clientes los admiten y pueden ser difíciles de configurar y administrar.
  • Mejor utilización de los servidores back-end: el procesamiento SSL/TLS consume muchos recursos de la CPU y se vuelve más intensivo a medida que aumentan los tamaños de las claves. Quitar este trabajo de los servidores back-end les permite concentrarse en lo que hacen más eficientemente: entregar contenido.
  • Enrutamiento inteligente: al descifrar el tráfico, el proxy tiene acceso al contenido de la solicitud, como encabezados, URI, etc., y puede usar estos datos para enrutar las solicitudes.
  • Gestión de certificados: Los certificados solo deben comprarse e instalarse en los servidores proxy y no en todos los servidores back-end. Esto ahorra tiempo y dinero.
  • Parches de seguridad: si surgen vulnerabilidades en la pila SSL/TLS, los parches apropiados deben aplicarse solo a los servidores proxy.

Para obtener más detalles, consulte Terminación SSL de NGINX en la Guía de administración de NGINX Plus.

Cifrado SSL/TLS a los servidores de origen

Hay ocasiones en las que es posible que necesites que NGINX encripte el tráfico que envía a los servidores back-end. Estas solicitudes pueden llegar al servidor NGINX como texto simple o como tráfico cifrado que NGINX debe descifrar para tomar una decisión de enrutamiento.  El uso de un grupo de conexiones keepalive a los servidores backend minimiza la cantidad de protocolos de enlace SSL/TLS y, por lo tanto, maximiza el rendimiento de SSL/TLS. Esto se logra de manera muy sencilla configurando NGINX para que utilice como proxy “https” de modo que encripte automáticamente el tráfico que aún no esté encriptado.

Cifrado de extremo a extremo

Debido a que NGINX puede realizar tanto cifrado como descifrado, puede lograr un cifrado de extremo a extremo de todas las solicitudes mientras NGINX sigue tomando decisiones de enrutamiento de capa 7. En este caso, los clientes se comunican con NGINX a través de HTTPS, y este descifra las solicitudes y luego las vuelve a cifrar antes de enviarlas a los servidores backend. Esto puede ser deseable cuando el servidor proxy no está ubicado en un centro de datos junto con los servidores back-end. A medida que más y más servidores se trasladan a la nube, se hace más necesario utilizar HTTPS entre un proxy y servidores back-end.

Certificados de cliente

NGINX puede manejar certificados de cliente SSL/TLS y puede configurarse para hacerlos opcionales u obligatorios . Los certificados de cliente son una forma de restringir el acceso a sus sistemas solo a clientes previamente aprobados sin requerir una contraseña, y puede controlar los certificados agregando certificados revocados a una lista de revocación de certificados (CRL), que NGINX verifica para determinar si un certificado de cliente aún es válido.

Funciones de seguridad adicionales

Hay una serie de otras características que ayudan a respaldar estos casos de uso, incluidas (entre otras) las siguientes:

  • Certificados múltiples: una sola instancia de NGINX puede admitir muchos certificados para diferentes dominios y puede escalar para admitir cientos de miles de certificados. Es un caso de uso común tener una instancia NGINX que atiende muchas direcciones IP y dominios y cada dominio requiere su propio certificado.
  • Grapado de OCSP : cuando esta opción está habilitada, NGINX incluye una respuesta OCSP con marca de tiempo firmada por la autoridad de certificación que el cliente puede usar para verificar el certificado del servidor, evitando la penalización del rendimiento por contactar directamente al servidor OCSP.
  • Cifrados SSL/TLS : puede especificar qué cifrados están habilitados.
  • Protocolos SSL/TLS : puede especificar qué protocolos están habilitados, incluidos SSLv2, SSLv3, TLSv1, TLSv1.1 y TLSv1.2.
  • Certificados encadenados – NGINX admite cadenas de certificados , que se utilizan cuando el certificado del sitio web no está firmado directamente por el certificado raíz de una CA (autoridad de certificación), sino por una serie de certificados intermedios. El servidor web presenta una 'cadena de certificados' que contiene los certificados intermedios, para que el cliente web pueda verificar la cadena de confianza que vincula el certificado del sitio web a un certificado raíz confiable.
  • Optimizaciones del servidor HTTPS : NGINX se puede ajustar al máximo su rendimiento SSL/TLS configurando la cantidad de procesos de trabajo, utilizando conexiones keepalive y usando un caché de sesión SSL/TLS.

Para obtener más detalles, consulte estos recursos:

Ejemplos

A continuación se muestran algunos ejemplos de las características de seguridad de NGINX. Estos ejemplos suponen una comprensión básica de la configuración de NGINX.

La siguiente configuración maneja el tráfico HTTP para www.example.com y lo envía a un grupo ascendente:

backends ascendentes {
servidor 192.168.100.100:80;
servidor 192.168.100.101:80;
}

servidor {
escucha 80;
nombre_servidor www.ejemplo.com;

ubicación / {
contraseña_proxy http://backends;
}
}

Ahora agregue soporte HTTPS, para que NGINX descifre el tráfico usando el certificado y la clave privada y se comunique con los servidores back-end a través de HTTP:

backends ascendentes { servidor 192.168.100.100:80; servidor 192.168.100.101:80; } servidor { escuchar 80; escuchar 443 ssl ; # El parámetro 'ssl' le dice a NGINX que descifre el tráfico server_name www.example.com; ssl_certificate www.example.com.crt ; # El archivo de certificado ssl_certificate_key www.example.com.key ; # El archivo de clave privada location / { proxy_pass http://backends; } }

O si en cambio recibe tráfico a través de HTTP y lo envía a los servidores backend a través de HTTPS:

backends ascendentes { servidor 192.168.100.100:443; servidor 192.168.100.101:443; } servidor { escuchar 80; nombre_servidor www.ejemplo.com; ubicación / { contraseña_proxy https ://backends; # El prefijo 'https' le dice a NGINX que encripte el tráfico } }

Para probar NGINX Plus, comience hoy su prueba gratuita de 30 días o contáctenos para analizar sus casos de uso.


"Esta publicación de blog puede hacer referencia a productos que ya no están disponibles o que ya no reciben soporte. Para obtener la información más actualizada sobre los productos y soluciones F5 NGINX disponibles, explore nuestra familia de productos NGINX . NGINX ahora es parte de F5. Todos los enlaces anteriores de NGINX.com redirigirán a contenido similar de NGINX en F5.com.