El hilo del laberinto (Publicaciones sobre Apache HTTP)

Compilar "Apache HTTP" con soporte ACME en SmartOS

Jesús Cea Avión — Fri, 31 Mar 2023 17:31:00 GMT

Apache HTTP añadió soporte nativo para el protocolo ACME (renovación automática de certificados X.509) en la versión 2.4.30 del servidor, como un componente opcional y experimental del mismo. La versión del paquete PkgSrc distribuido en SmartOS no tiene dicho módulo, así que en abril de 2020 pedí que se incluyese.

La respuesta fue algo decepcionante: Se añadía a PkgSrc la opción de compilar ese módulo opcional, mod_md, pero dado que sus propios autores lo tienen marcado como experimental, el paquete precompilado para SmartOS seguiría sin incluirlo de serie.

Pero, al menos, ahora puedo compilarlo de forma trivial yo mismo si lo necesito.

No voy a entrar en detalles sobre cómo compilar paquetes en PkgSrc para SmartOS. Este blog tienen muchos artículos sobre este tema, accesibles desde el menú de Tags de la parte superior de la página.

Los pasos concretos para compilar Apache HTTP con el módulo mod_md en una zona PkgSrc de SmartOS son los siguientes:

Leer más… (quedan 4 minutos de lectura)

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

Jesús Cea Avión — Wed, 19 Jul 2017 16:05:00 GMT

Advertencia

Este documento se escribió en junio de 2013 como un borrador de informe para un cliente. El informe no llegó a completarse nunca porque al cliente le bastó el borrador para avanzar al siguiente paso del proyecto.

Por tanto, se trata de un documento incompleto y que, además, refleja el estado de la tecnología en junio de 2013. Las cosas han evolucionado desde entonces, naturalmente.

La necesidad concreta del cliente es un proxy HTTPS cuyo backend sea también HTTPS.

Este documento se ha publicado por interés histórico y con el permiso explícito del cliente.

Contenido

1 Introducción
2 Requisitos
3 Evaluación preliminar
- 3.1 Apache HTTP 2.4
- 3.2 Estudio de la competencia de Apache HTTP
  - 3.2.1 Varnish
  - 3.2.2 Nginx
  - 3.2.3 lighttpd
  - 3.2.4 ha-proxy
  - 3.2.5 Apache Traffic Server
  - 3.2.6 Squid
  - 3.2.7 g-wan
4 Evaluación
5 Detalles a verificar
6 Conclusión y recomendación final

1 Introducción

DXXXl CXXXn se pone en contacto telefónico conmigo la tarde del domingo 28 de abril de 2013, indicándome que las divisiones de banca del grupo SXXXr han sido amenazadas con ataques de denegación de servicio, que se realizarían a partir del 7 de mayo.

Con el fin de protegerse en lo posible, se está procediendo a configurar sistemas y a contratar servicios externos de paliación de ataques DDoS. Simultáneamente se planea desarrollar tecnología interna con este fin, con el propósito de disponer de varias vías de defensa alternativas, con diferentes costes y calidades.

En la conversación telefónica se me encarga la evaluación del servidor web Apache como plataforma proxy para la detección y prevención de ataques a servicios HTTPS. El plazo disponible es de una semana y el trabajo se tasa en XXX €.

2 Requisitos

El proyecto requiere cumplir estos requisitos:

Leer más… (quedan 13 minutos de lectura)

OCSP Stapling y no cachear errores OCSP en Apache

Jesús Cea Avión — Mon, 28 Dec 2015 15:58:00 GMT

He tratado el tema de OCSP Stapling antes. Por ejemplo, OCSP Stapling y la privacidad de tus usuarios. Resumiendo: Online Certificate Status Protocol permite comprobar en tiempo real si un certificado X.509 está revocado o no, pero ello supone comprometer la privacidad de nuestros usuarios. Usando OCSP Stapling, el servidor web se hace cargo de solicitar el estado OCSP, se lo guarda mientras siga siendo válido y envía el resultado a cada navegador que se conecta para evitar que lo haga el propio navegador del usuario. Esto mejora la velocidad de respuesta percibida y no compromete la privacidad del usuario.

OCSP Stapling debería funcionar bien, pero de la teoría a la práctica siempre hay un trecho. Léase, por ejemplo, mi artículo OCSP y el depender de la profesionalidad ajena.

Leer más… (quedan 1 minutos de lectura)

Bugs: Firefox, favicon y webs protegidas

Jesús Cea Avión — Thu, 15 Oct 2015 23:10:00 GMT

Este artículo va sobre esos bugs puñeteros e imposibles que se diagnostican con facilicidad cuando tienes acceso a los recursos apropiados. En este caso, los logs del servidor web.

Este bug es simple de explicar: Si una web está protegida con usuario/clave, lo normal es que el favicon no funcione en Firefox. ¿Por qué?. Porque cuando Firefox solicita el favicon al servidor no envía las credenciales y el servidor web le denegará el acceso.

En el log del servidor web veía algo de este estilo:

IP - [15/Oct/2015:12:06:26 +0200] "GET /icons/favicon.png HTTP/1.1" 401 381 [...]

El código 401 indica acceso denegado.

La solución obvia es "desproteger" el favicon de forma selectiva. En Apache HTTP Server sería algo de este estilo:

Leer más… (quedan 1 minutos de lectura)

HTTP/2 ha llegado y aquí lo tienes funcionando

Jesús Cea Avión — Thu, 15 Oct 2015 13:10:00 GMT

HTTP/2 se publicó de forma oficial en mayo de 2015, como RFC 7540. La semántica no ha cambiado respecto al viejo HTTP/1.1, pero HTTP/2 proporciona un mecanismo de transporte diferente con varias mejoras interesantes. En particular, se pueden multiplexar varias peticiones HTTP concurrentes a través de una única conexión TCP/IP. Esto reduce la latencia considerablemente mientras, de forma simultánea, se reduce la carga en el servidor.

Todos los navegadores modernos (incluyendo las versiones recientes de Android y de iOS) soportan HTTP/2. Bien. Más aún, Chrome y Firefox solo intentarán usar HTTP/2 cuando la conexión se realice de forma segura (HTTPS). Genial. Dado que HTTP/2 supone una mejora real pero simple de desplegar y que dicho despliegue supone migrar a HTTPS, esta jugada es -de hecho- un buen incentivo para que las webs migren a HTTPS.

La versión 2.4.17 de Apache HTTP Server incluye soporte de HTTP/2 de forma nativa. A fecha de hoy, esto requiere compilar Apache HTTP Server 2.4.17 o superior desde el código fuente y además:

Leer más… (quedan 3 minutos de lectura)

OCSP y el depender de la profesionalidad ajena

Jesús Cea Avión — Mon, 22 Jun 2015 15:27:00 GMT

He escrito ya antes sobre Online Certificate Status Protocol. Puedes ver el tag OCSP de este blog. En concreto en El triste estado de las revocaciones SSL en Internet expongo el hecho objetivo de que la mayoría de los navegadores web no comprueban la revocación de certificados o la comprueban de forma muy... peculiar.

Por ejemplo, con la configuración por defecto, un navegador normal que hace verificaciones OCSP hace lo siguiente:

Hay navegadores que no hacen comprobaciones OCSP para certificados X.509 normales, solo para los certificados EV. Por ejemplo, Apple Safari (el navegador de Mac OS X y de iOS). Ni que decir tiene que la inmensa mayoría de los certificados X.509 no son EV.
Supongamos que el navegador decide hacer una consulta OCSP. En este caso, si el servidor OCSP no responde en absoluto, no pasa nada. El certificado X.509 se dará por bueno. Esto es una vía de ataque evidente si nos conectamos a través de una red bajo el control de un ente malicioso.

¿Por qué se hace así? Porque no es raro que lo servidores OCSP de las entidades de certificación estén caídos o saturados. Es decir, no recibir respuesta a la petición OCSP es rutina. Como no es aceptable que el usuario del navegador reciba avisos de seguridad o se le deniegue el acceso a la mitad de la webs que visita cada día, los navegadores han sido prácticos y aceptan el hecho habitual de que no obtener una respuesta OCSP no tiene por qué indicar nada feo (al margen de la profesionalidad dudosa de esa entidad de certificación, claro).
Una petición OCSP supone una pérdida de privacidad para el usuario. Explico el problema y la solución en mi artículo OCSP Stapling y la privacidad de tus usuarios.

Resumiendo, el servidor web de un dominio accesible por HTTPS puede hacer una petición OCSP para su propio certificado X.509, cachear ese resultado durante unas horas e incluir esa respuesta en la negociación TLS entre el servidor HTTPS y el navegador. De esta manera el navegador se ahorra la petición OCSP y el tiempo de espera, y el usuario gana privacidad.

Una situación Win-Win de libro.

Leer más… (quedan 5 minutos de lectura)

Servir WebDAV tras un proxy HTTP/HTTPS

Jesús Cea Avión — Thu, 07 May 2015 16:36:00 GMT

Web Distributed Authoring and Versioning (WebDAV) es una extensión del protocolo HTTP que añade verbos adicionales para poder, por ejemplo, realizar cambios en el servidor. Lo más evidente es almacenar o modificar ficheros, pero los cambios pueden ser semánticos. Por ejemplo, modificaciones coordinadas en documentos compartidos como un calendario o una agenda telefónica.

Apache soporta WebDAV y, de hecho, es la opción que yo recomiendo en vez del vetusto FTP, por ejemplo. Hay muchas ventajas: atravesar cortafuegos con facilidad, cifrado integrado a través de HTTPS y, en general, unificación con toda la infraestructura web.

Una cosa que suelo hacer con frecuencia es dar acceso a infraestructura protegida o unificar varios servidores web bajo un árbol común. Esto lo hago a través del módulo mod_proxy de Apache. Básicamente mod_proxy puede hacer que http://www.example.com/servidorA nos enseñe el contenido del servidor A y que http://www.example.com/servidorB nos muestre el contenido del servidor B. Hacer esto con mod_proxy es trivial, rutina. El cliente web se conecta a http://www.example.com/, indica la carpeta que quiere y mod_proxy realiza una petición HTTP/HTTPS por detrás al servidor adecuado para completar la petición del cliente.

Es importante, en estas circunstancias, que los enlaces que genera el servidor A sean o bien relativos o que se cambien para que parezcan provenir de http://www.example.com/servidorA. En el contexto de mod_proxy solemos usar la directiva ProxyPassReverse. Esta directiva nos permite interceptar las redirecciones HTTP generadas por el servidor A para que parezcan provenir de http://www.example.com/servidorA.

¿Qué pasa con WebDAV?. El problema es que WebDAV nos devuelve direcciones absolutas.

Leer más… (quedan 4 minutos de lectura)

¡Cifrad, cifrad, malditos!

Jesús Cea Avión — Mon, 03 Nov 2014 23:16:00 GMT

Con todo lo que está cayendo en temas de privacidad y seguridad y con la potencia de las máquinas actuales, no hay excusas para no emplear cifrado en todas nuestras comunicaciones en Internet.

En este artículo no voy a entrar en el aspecto técnico ni activista de desplegar cifrado en las comunicaciones. Baste con decir, de momento, que no hay ningún motivo para NO cifrar y muchos, muchísimos, para sí hacerlo.

A pesar de ser muy insistente en todo este tema, he sido un pobre ejemplo práctico hasta ahora. Llevo usando HTTPS mucho tiempo, pero siempre he usado certificados autofirmados. No voy a entrar en los detalles del estado vergonzoso de las autoridades de certificación o que el despliegue de DNSSEC progrese a paso de tortuga. Habrá tiempo de tratar todo eso en otros artículos.

Desde el 3 de noviembre de 2014 empleo certificados X.509 validados por los navegadores para:

Lo que sigue describe este despliegue para entornos Unix o similares (Linux), el servidor web Apache y el programa OpenSSL. No contaré los detalles básicos porque ya se explican en infinidad de páginas web.

Lo básico

El primer paso consiste en generar un certificado X.509:

$ openssl genrsa -out www.jcea.key 2048

Con la configuración actual, esto generará un certificado X.509 RSA [2] de 2048 bits y SHA-1 [1] como algoritmo de hash. El fichero generado debe protegerse como oro en paño, así que posiblemente haya que cambiar su propietario y los permisos de acceso en el sistema de ficheros. Debe mantenerse secreto a toda costa.

Leer más… (quedan 7 minutos de lectura)

OCSP Stapling y la privacidad de tus usuarios

Jesús Cea Avión — Wed, 28 May 2014 15:57:00 GMT

En un artículo anterior titulado El triste estado de las revocaciones SSL en Internet comento que Online Certificate Status Protocol (OCSP) tiene varios problemas:

Un serio problema de privacidad para el usuario final: cada vez que entras es una página web HTTPS, tu navegador hará una consulta OCSP, filtrando el hecho de que estás entrando en esa web en concreto. Esa información llega a la entidad de certificación que "avala" el certificado SSL de ese servidor y, naturalmente, es accesible también para todas las redes intermedias entre ella y tu ordenador
El volumen de tráfico en la entidad de certificación es proporcional al volumen de usuarios de una web determinada. Si una web tiene éxito, la entidad de certificación tendrá un coste adicional, sin ningún beneficio.
Para el usuario final, la consulta OCSP supone añadir latencia, porque el navegador tiene que saber que el certificado SSL no ha sido revocado antes de mostrarte el contenido de la web.
Si la entidad de certificación no responde a la petición OCSP, el navegador debe elegir qué hacer. Ahora mismo, la configuración por defecto suele ser soft-fail. Es decir, si la respuesta OCSP es "certificado revocado" o "certificado desconocido", el navegador nos denegará el acceso, pero si no nos llega ninguna respuesta OCSP, el navegador considerará que todo ha ido bien. Evidentemente, si estamos sufriendo un Man in the Middle o una impersonación, el atacante nos filtrará OCSP.

Leer más… (quedan 3 minutos de lectura)