¿Debe terminarse SSL en un equilibrador de carga?

Me parece que la pregunta es "¿Confía usted en su propio centro de datos"? En otras palabras, parece que estás tratando de dibujar con precisión la línea en la que se encuentran las redes no confiables y comienza la confianza .

En mi opinión, la confianza de SSL / TLS debe terminar en el dispositivo de descarga de SSL ya que el departamento que administra ese dispositivo a menudo también administra la red y la infraestructura. Hay una cierta cantidad de confianza contractual allí. No tiene sentido cifrar los datos en un servidor posterior, ya que las mismas personas que apoyan la red también suelen tener acceso a esto. (con la posible excepción en entornos de múltiples inquilinos o requisitos comerciales únicos que requieren una segmentación más profunda).

Una segunda razón por la que SSL debe terminar en el equilibrador de carga es porque ofrece un lugar centralizado para corregir ataques SSL como CRIME o BEAST . Si SSL se termina en una variedad de servidores web, ejecutar en diferentes sistemas operativos es más probable que tenga problemas debido a la adicional complejidad . Manténlo simple y tendrás menos problemas a largo plazo.

Dicho esto

1. Sí, termina en el equilibrador de carga y la descarga de SSL allí. Mantenlo simple.
2. El equilibrador de carga de Citrix Netscaler (por ejemplo) puede denegar el acceso inseguro a una URL. Esta lógica de política, combinada con las características de TLS, debe garantizar que sus datos permanezcan confidenciales y sin falsificaciones (dado que entiendo adecuadamente su requisito de integridad)

Editar:

Es posible (y común) a

• Externalice el equilibrador de carga (Amazon, Microsoft, etc.)
• Utilice un CDN de terceros (Akamai, Amazon, Microsoft, etc.)
• O use un proxy de terceros para evitar ataques DoS

... donde el tráfico de esa tercera parte se enviaría a sus servidores a través de enlaces de red que no administra. Por lo tanto, no puede confiar en esos enlaces sin cifrar. En ese caso, debe volver a cifrar los datos, o al menos hacer que todos esos datos viajen a través de una VPN de punto-punto.

Microsoft ofrece tal producto VPN y permite la externalización segura del perímetro.

Sí, yo diría que TLS debería descargarse. He hecho todo lo que menciono a continuación específicamente con el Citrix Netscaler, pero creo que F5 debería poder hacer las mismas cosas.

Primero, siempre debe asegurarse de volver a cifrar en el otro lado del equilibrador de carga, pero el dispositivo que descifra TLS debe poder inspeccionar lo que está sucediendo desde una perspectiva de seguridad. La integridad de los datos no debe verse comprometida por este enfoque.

Muchas personas me han dicho que volver a cifrar en el back-end hace que sea computacionalmente costoso, pero eso no es cierto. El gasto con TLS es la construcción y el cierre de la conexión, que maneja el descargador de TLS. En el backend tiene una conexión más persistente con los servidores y, por lo tanto, los recursos necesarios son mucho más bajos.

Además, si no tiene la descarga de TLS, incluso un pequeño ataque DDoS a través de TLS aniquilaría completamente sus servidores. Estoy muy familiarizado con esta situación y la descarga de TLS es una ayuda increíble desde una perspectiva computacional, y también te permite bloquear los ataques en la cadena. Para ataques DDoS extremadamente grandes, incluso podría dividir su estrategia de mitigación entre su descargador TLS y sus servidores.

Para inspeccionar los datos que van dentro de una conexión SSL, entonces cualquiera de estos debe ser verdadero:

• El túnel termina en la máquina que realiza la inspección, por ejemplo. su "equilibrador de carga".
• El sistema de inspección conoce una copia de la clave privada del servidor, y la conexión SSL no usa Diffie-Hellman efímero (es decir, el servidor no permite los conjuntos de cifrado que contienen "DHE" en su nombre).

Si sigue la primera opción, los datos viajarán sin cifrar entre el sistema de inspección (el equilibrador de carga) y los clústeres, a menos que lo vuelva a cifrar con algún otro túnel SSL: la conexión principal de SSL es entre el navegador del cliente y el equilibrador de carga. y el equilibrador de carga mantiene un enlace SSL (o alguna otra tecnología de encriptación, por ejemplo, una VPN con IPsec ) entre sí y cada una de los nodos del cluster.

La segunda opción es un poco más clara, ya que el inspector de paquetes simplemente descifra los datos pero no tiene que volver a cifrarlos. Sin embargo, esto implica que todos los nodos del clúster pueden hacer el SSL completo con el cliente, es decir, conocer una copia de la clave privada del servidor. Además, no admitir DHE significa que no obtendrá la característica ingeniosa de Perfect Forward Secrecy (esto no es fatal, pero PFS se ve muy bien en las auditorías de seguridad, por lo que es bueno tenerlo.

De cualquier manera, el nodo que realiza una inspección profunda de paquetes debe tener algún acceso de privilegio al túnel SSL, lo que lo hace bastante crítico para la seguridad.

Yo recomendaría la terminación de SSL en el equilibrador de carga (ya sea en su red, en un proveedor de CDN o lo que sea). Esto significa que el LB puede inspeccionar el tráfico y puede hacer un mejor trabajo de balanceo de carga. También significa que su equilibrador de carga es responsable de lidiar con clientes lentos, implementaciones SSL rotas y el descontento general de Internet. Es probable que su equilibrador de carga tenga mejores recursos para hacer esto que sus servidores back-end. También significa que los certificados SSL que el mundo ve están todos en el equilibrador de carga (lo que, con suerte, los hace más fáciles de administrar).

La alternativa aquí es simplemente equilibrar la carga de las conexiones TCP de los clientes a sus servidores back-end. Como el LB no puede inspeccionar lo que está sucediendo de esta manera, no puede distribuir la carga de manera uniforme entre los servidores de back-end, y los servidores de back-end tienen que lidiar con toda la flakiness de Internet. Solo usaría este método si no confías en tu equilibrador de carga, proveedor de CDN o lo que sea.

Si se vuelve a cifrar o no desde el equilibrador de carga a sus servidores back-end es una cuestión de elección personal y circunstancia. Si está tratando con tarjetas de crédito o transacciones financieras, es probable que esté regulado por el gobierno y, por lo tanto, tendrá que volver a cifrarlo. Es probable que también deba volver a cifrar si el tráfico entre el equilibrador de carga y los servidores de servicios de fondo viaja a través de redes que no son de confianza. Si solo está alojando el sitio web de su empresa, entonces podría evitar la sobrecarga adicional del recifrado, si realmente no le importan los aspectos de seguridad de la misma.

El nuevo cifrado no agrega tanta carga como podría pensar. Generalmente, el equilibrador de carga podrá mantener conexiones persistentes a los servidores, por lo que el costo de SSL será bastante bajo para ese 'salto' en la red.

Lo último en lo que pensar es en la aplicación en los servidores de servicios de fondo. Si todo el tráfico que llega allí es HTTP, entonces no puede tomar decisiones basadas en el protocolo que estaba usando el cliente. Entonces no puede decir "estás intentando acceder a la página de inicio de sesión a través de HTTP, por lo que te redirigiré a la versión HTTPS de la página", por ejemplo. Puede hacer que el equilibrador de carga agregue un encabezado HTTP para decir "esto vino de HTTPS", pero ese encabezado necesitaría un manejo especial en la aplicación. Dependiendo de su situación, puede ser más fácil volver a cifrar y dejar que la aplicación funcione de manera "predeterminada" en lugar de necesitar una modificación específica del sitio.

En resumen, diría: termine en el equilibrador de carga y vuelva a cifrar en sus servidores de servicios de fondo. Si hace esto y observa algún problema, puede hacer ajustes si lo necesita.

Puede elegir cifrar el tráfico interno con un certificado de clave inferior. Y también se recomienda colocar su equilibrador de carga lo más cerca posible de sus servidores para evitar el rastreo o los ataques de intermediarios. La terminación SSL se puede hacer en el Load Balancer para descargar trabajos intensivos de CPU de los servidores web. Si la marca LB que ha elegido puede realizar ciertas funciones, como inspeccionar las conexiones de protocolo mal formadas, detectar el comportamiento DDoS, etc.