BORRADOR: Evaluación de Apache Traffic server como proxy/caché HTTPS en ambos

1   Introducción

En un documento previo se evaluó el uso de Apache HTTP server como servidor proxy/caché cuando tanto las conexiones desde el navegador del usuario como las conexiones del proxy a los sistemas “upstream” deben estar protegidas por HTTPS. La conclusión fue que Apache HTTP server es muy versátil y capaz, pero no cumple nuestros requisitos de escalabilidad.

En el mismo documento se revisaban someramente otras alternativas y se recomendaba evaluar en primer lugar otro producto Apache: Apache Traffic Server.

Los motivos para este recomendación son:

• PXXXn está valorando asociarse a la fundación Apache.
• Apache Traffic server parece cumplir, en una revisión preliminar, las necesidades de escalabilidad requeridas.
• Apache Traffic server dispone de una abundante documentación de calidad, incluyendo descripciones y ejemplos de como escribir módulos externos que interactúen con el servidor. Es decir, la información necesaria para extender el servidor para cubrir nuestras necesidades de, por ejemplo, lucha anti DDoS.

El plazo disponible para evaluar este producto es de una semana, valorada en XXX €.

2   Requisitos

Recordemos que el producto elegido debe cumplir estos requisitos:

1. El servicio debe atender peticiones HTTPS en la parte de cliente.
2. El servicio debe actuar de proxy de la forma más transparente posible (al usuario) hacia el sistema backend.
3. La conexión al sistema backend debe hacerse también por HTTPS.
4. El servicio debe escalar vertical (conexiones simultaneas en un mismo servidor) y horizontalmente (múltiples servidores proxy).
5. Un mismo proxy prestará servicios a muchos backends HTTPS distintos.
6. El servicio debe ser capaz de afrontar y notificar ataques DDoS básicos.
7. Idealmente, el servicio debe poder realizar también análisis de las peticiones para detectar y notificar (e idealmente, detener) ataques a nivel HTTP y a nivel de aplicación.
8. El proxy debe realizar también cacheo de objetos HTTP para reducir la carga en los servidores de backend, aunque para conseguir un nivel de “hits” importantes se requerirá modificar las aplicaciones de backend para añadir las cabeceras HTTP necesarias, etc.

Apache Traffic Server parece cumplir todos los puntos excepto el 6 y el 7, que pueden cubrirse expandiendo el producto mediante “plugins” escritos al efecto.

3   Evaluación

PXXXn realizará la instalación final usando Red Hat Linux, pero para las pruebas yo voy a utilizar una máquina virtual personalizada. Los detalles de configuración son los mismos que se han descrito en el documento anterior.

Un detalle importante es que se mantiene el servidor Apache HTTP instalado en el documento anterior para que -una vez reconfigurado- actúe como servidor HTTPS “upstream” del Apache Traffic Server que estamos evaluando.

Utilizo un sistema de control de versiones para mantener el script de compilación de Apache Traffic Server y sus diferentes ficheros de configuración.

4   Detalles a verificar

• Revisar los permisos de las claves secretas SSL.

• Las claves secretas SSL no están protegidas con clave.

• Los errores en el proxy no deben filtrar información sobre los servidores “upstream” (sus nombres o sus IPs, por ejemplo).

• El proxy debe verificar los certificados X.509 de los servidores “upstream”.

• ¿Cómo vamos a canalizar las IPs de origen a través de los proxies?

• ¿Soporte SNI en el frontal? Problemático con clientes antiguos.

• Revisar con atención la configuración de las conexiones persistentes entre el proxy y los servidores “upstream”.

• ¿Las aplicaciones y los balanceadores intermedios funcionan si se canalizan peticiones de distintos usuarios a través de una única conexión persistente con el “upstream”?.

• ¿Activar la compresión entre el proxy y el “upstream”? ¿Entre el proxy y los clientes?

• Configurar correctamente la negociación de la calidad del cifrado SSL/TLS.

• Método “TRACE”.

• “mod_log_debug” puede configurarse para hacer log de los “timeouts” de los clientes.

• A la hora de realizar las pruebas de rendimiento, tengo que configurar mi portátil para que mantenga la CPU a 2.4Ghz y obtener así resultados estables y representativos.

  Por algún extraño motivo, obtengo más rendimiento con mi máquina cargada que con mi máquina en "idle". Posiblemente un tema de “scheduling” entre mi kernel y la máquina virtual. Obtengo 65.6 peticiones por segundo, 34.8 si tengo la CPU a 800Mhz. Estas cifras sirven para poder compararse entre sí, no como valoración de rendimiento del entorno de producción.

• Configurar ProxyVia/ProxyReverseHost.

• Configurar ProxyPass con parámetros.

• Configurar ProxyErrorOverride.

• Configuro ProxyStatus, pero no sale nada. Insistir. ¿Tal vez no funciona para proxies inversos?.

• Evaluar “mod_proxy_express”.

• Evaluar “mod_proxy_html”.

• Evaluar “mod_proxy_balancer”. Activar el balancer-manager. Configuración en caliente.

• ¿Estamos delante o detrás del balanceador?. Importante para el “pool”, “stickiness”, “balanceador apache”.

• Configurar SSLProxy*.

• Evaluar SSLStapling*.

• Para evitar la sobrecarga de la negociación SSL/TLS, es imprescindible que los clientes reutilicen en lo posible, las sesiones SSL/TLS. Configuro “SSL session cache”, pero no parece funcionar.

  El “lock” se guarda en un fichero borrado (pero accesible para los hijos del servidor Apache), pero no el caché SSL.

  Con “dbm” funciona, crea el fichero, pero no me parece usable en absoluto.

  apt_shm_create

  Si manipulo el código, veo que se crea el fichero, pero no guarda nada en él.

  Parcheando con “debug” a saco, veo que busca sesiones en la base de datos, pero también veo que no escribe nunca.

  Tras días investigando el asunto y escribiendo herramientas “ad hoc” para ello, identifico el problema: Si el cliente lo soporta, Apache utiliza “tickets” TLS, definidos en RFC 5077.

  Si la librería OpenSSL está compilada con soporte de “tickets” TLS, entonces Apache los utiliza incondicionalmente. No es configurable. Manipulo el código para desactivar el soporte de “tickets” TLS y entonces Apache sí emplea adecuadamente la base de datos de sesiones SSL.

  Todo esto es importante porque en la visualización del estado y las estadísticas Apache hay una sección sobre sesiones SSL, cuántas están activa y detalles de su reutilización. Cuando el cliente emplea “tickets” TLS, que he comprobado que es la norma, esa situación no se refleja en esas estadísticas, causando confusión y haciendo que la evaluación sea imposible. Lo que aparece es que el primer acceso de un cliente es un “miss”, pero los accesos subsiguientes, con “tickets”, sencillamente no se ven en la estadística SSL/TLS. Entiendo que esto es un bug de Apache HTTP, tal vez porque la librería OpenSSL no exporta esa información. Verificarlo y notificarlo.

  Si desactivo el manejo de sesiones SSL en Apache, los clientes siguen pudiendo usar “tickets”. No es configurable en Apache.

  Me escribo un cliente que comprueba la recuperación de sesiones SSL y del uso de “tickets” TLS, y compruebo los puntos anteriores con detalle.

  Advertencia

  La idea de todo esto es poder monitorizar la efectividad del sistema de "tickets" TLS, porque un mecanismo de ataque evidente al servicio es obligarle a hacer negociaciones TLS redundantes o espúreas.

• Si tenemos varios proxies, todos ellos deberían usar la misma clave para proteger los “tickets” TLS, aunque por seguridad dicha clave debería cambiarse con frecuencia (horas).

• El uso de “tickets” TLS tiene implicaciones de seguridad importantes, como la desaparición de “forward secrecy” en caso de compromiso del servidor o de la clave de protección de los “tickets” TLS.

• Esto es aún más crítico cuando queremos que la clave de protección de “tickets” TLS esté compartida entre todos los proxies para reutilizar el máximo posible de sesiones TLS. Esto puede no ser un problema si solo tenemos un proxy por “cuenca” BGP.

• Falta verificación de certificados proxy.

5   Conclusión y recomendación final

Dado que el grupo SXXXr quiere contribuir a la fundación Apache y que la documentación del Apache Traffic Server parece ser muy completa y detallada, sugiero evaluar primero este producto.