Nueva generación de servidores web basados en HTTP/2 y con TLS por defecto: “The Caddy Web Server”

Monitorización de los nuevos HTTP/2 más HTTPS: el Servidor Web Caddy

Como todos y todas bien sabemos, Pandora FMS permite la monitorización de prácticamente cualquier dispositivo o aplicación, y una categoría de ellas son los servidores de contenido web. Admitámoslo, prácticamente todo gira en torno a ello. Incluso las muy populares aplicaciones o “apps”, hechas para el sistema operativo Android de nuestros teléfonos, generalmente utilizan comandos API, que también son albergados en servidores web para aprovechar el protocolo seguro (HTTPS). Es, por lo tanto, que debemos mantenernos al día con las innovaciones, y hoy veremos no solamente otro programa de servidor web sino también nuevos paradigmas en este campo. ¡Vamos!

Hablemos primero sobre HTTP

A finales del siglo pasado, el Protocolo de Transferencia de Hipertexto (HTTP) alcanzó la versión 1.1. Desde 2015 está disponible la versión 2.0 (mejorada) en el 11% de los servidores web. Todo bien, pero, ¿qué es el HTTP?

Imaginemos un mundo donde todos los ordenadores tengan el mismo sistema operativo, y que además la última versión tenga completa compatibilidad hacia atrás con versiones anteriores. Imaginemos, además, que los protocolos de comunicación tienen las mismas características: en este mundo utópico un ordenador podría perfectamente solicitarle a otro un recurso dado, digamos un simple fichero de texto. Como ambos ordenadores son completamente compatibles entre sí, la tarea encomendada no representaría mayor problema… en un mundo ideal y perfecto.

Abramos la caja de Pandora (ea, no lo toméis a mal, equipo de Pandora FMS) y dejemos que todos los males contaminen nuestro mundo idealizado, y comencemos por “tumbar” a la mitad de la transmisión del recurso solicitado al servidor web: una vez que se restablezca la conexión y se vuelva a solicitar el recurso, este será transmitido en su totalidad desde el principio. Si es algo pequeño no perderemos mayor tiempo, pero si es algo más grande (hasta en un mundo perfecto) la pérdida de tiempo es irrecuperable.

Pensemos otra cosa; ahora tenemos el recurso que queremos bien guardado en nuestros equipos y necesitamos comprobar si hay una versión más reciente en el servidor web. De nuevo, nos será transmitido el recurso completo… solo para descubrir que es la misma versión que ya tenemos almacenada. Esto no solo es pérdida de tiempo, sino de recursos también: para comenzar, gasto de electricidad, y para terminar… paren ustedes de contar cualesquiera otros elementos desperdiciados.

No vamos a ir más allá, ustedes ya lo habrán imaginado: ¡qué bueno sería que tuviéramos opciones para “hablar” con el servidor web antes de que comience a enviarnos cualquier dato o información! Para ello se inventaron los protocolos, que no son más que formas y maneras de comunicación, o si quisiéramos abstraernos, son como “lenguajes o idiomas” que hablan los aparatos electrónicos. Hablar en profundidad sobre esto significaría comenzar una carrera universitaria para obtener el grado de licenciado en la materia, por lo que seguiremos, mejor, narrando como lo hemos venido haciendo a lo largo de muchos de nuestros artículos.

Veamos algo más: es común hablar de “ficheros de texto plano”, sobre los cuales todos y todas pensamos que es lo más sencillo en el campo de la computación, y que damos por sentado que nuestros actuales sistemas operativos pueden abrir sin problema alguno. Pero hasta en esto es necesaria una forma previa de entendernos, de convertir todos esos ceros y unos en letras y números de un lenguaje de alto nivel, como el castellano que hablamos, verbigracia estas líneas. Dichos archivos de texto no poseen una sola codificación de caracteres; al principio se usó (y aún se usa) el ASCII, luego el ANSI y ahora el UNICODE, con el popular UTF-8, que permite ahorrar bytes en transmisión y almacenamiento.

Para solventar lo primero, y también lo segundo y mucho más, existe el HTTP; son mensajes de texto con comandos y preguntas que siguen un formato específico, y permite saber las capacidades del servidor web o establecer la codificación de caracteres de los recursos, entre muchísimas otras opciones.

Podremos enviar un sencillo:

GET /index.html HTTP/1.1

(acompañado de otros valores adicionales, especialmente la última línea en blanco) donde, esencialmente, estamos solicitando un fichero de texto (por la extensión, en lenguaje HTML) y estamos indicando que “hablamos” la versión 1.1 del protocolo. El servidor nos responderá con:

HTTP/1.1 200 OK

junto a valores como la fecha, la codificación de caracteres, el tipo de recurso, una línea en blanco, el recurso en sí mismo (la página web en este caso) y una última línea en blanco. Debemos tener en cuenta que todo esto es para la transmisión de datos e información. La manera como el navegador web represente o maneje el recurso recibido es materia para otro artículo.

Toda esta explicación era necesaria para pasar a detalles técnicos. En el HTTP 1.1, los mensajes que hayamos enviado anteriormente le tienen sin cuidado al servidor web. No se da el caso de que le digamos, en forma de comando apropiado: “¡Hola! Soy yo de nuevo, ahora necesito este otro recurso que está enlazado al recurso que os pedí primero”. Esto quiere decir que deberemos volver a repetir el envío de las cabeceras, lo cual es una redundancia, y hablamos de nuevo en una pérdida de recursos, más que todo de tiempo, que es lo más valioso. Esta redundancia sucede porque es un protocolo sin estado: cada mensaje es totalmente independiente, se dice así que no podemos iniciar sesión.

Iniciar sesión, en cualquier sistema informático, pasa por identificarnos y recibir un boleto que podemos mostrar cada vez que “hablamos” con el servidor. De allí que las aplicaciones web recurren al uso de galletitas para identificarnos, los cuales son valores que hacen las veces de sesión (os habréis dado cuenta de esto con las normas europeas RGPD).

Otra característica derivada es que si solicitamos una página web, la recibimos y luego comenzamos a solicitar las imágenes -o cualquier otro material- de esa página web, cada una de esas solicitudes son como clientes nuevos para el servidor, son conexiones adicionales, las cuales limitan capacidad de respuesta al ordenador.

Por último, en este artículo (porque el HTTP 1.1 es muy amplio) también os acotamos que como son “mensajes de texto plano” lo que enviamos y recibimos, y por esto son susceptibles de ser leídos por todos y cada uno de los dispositivos que nos comunican hacia y desde Internet, lo que es conocido como hombre en el medio (“man-in-the-middle”, en idioma inglés) por lo que se necesita el protocolo HTTPS para cifrar el contenido y para que nuestro servidor web mantenga la privacidad de nuestros visitantes y clientes, deberemos adquirir certificados digitales, instalarlos y configurarlos. Todo un trabajo adicional.

HTTP 2.0

El Servidor Web Caddy maneja este protocolo de manera predeterminada; sin embargo, es totalmente compatible hacia atrás. Esto es así porque en realidad esta versión permite muchas mejoras:

• Para comenzar, solo es necesaria una única conexión. Todo lo enviaremos y recibiremos por esta única “tubería”, lo que evita más trabajo al servidor web.
• De lo anterior se aprovechó para eliminar información redundante en cada mensaje: ahora el servidor “sabe” quienes somos nosotros, pues al abrir la conexión esta se mantiene en línea al estilo de una sesión abierta (pronto veremos que el Servidor Web Caddy aprovecha aún más esta característica).
• Se pueden comprimir los recursos: antes se podía hacer si ambos, cliente y servidor, tenían la librería GZIP instalada y configurada; ahora comprime por defecto con el algoritmo HPACK.
• Ya no son archivos de texto plano los mensajes, sino que son datos binarios para una mayor eficiencia.
• Podemos dar prioridad a algunos mensajes sobre otros.
• El servidor, si se configura, puede salir del modo pasivo (espera de órdenes) a modo activo (enviar notificaciones que programemos ante determinados eventos) al usuario.
• No todo es miel sobre hojuelas: aparecen unas nuevas vulnerabilidades y deberemos configurar los valores para prevenir males mayores. Es aquí que entra en escena el Servidor Web Caddy.

El Servidor Web Caddy

En Escocia, cuna del golf, la palabra caddy describe una persona que ejecuta trabajos esporádicos. Tales personas trabajaban ayudando a los jugadores con sus implementos y recibieron este nombre. También, en este mundo moderno, los carritos eléctricos que sustituyen a las personas reciben ese sustantivo. Pero aquí acontece que es nombre registrado, así con mayúscula Caddy, o para ser más precisos, “the Caddy web server“. Por ello, nosotros lo denominamos, en castellano, Servidor Web Caddy.

Está escrito con lenguaje Go versión 1.10 (o superior), en código fuente abierto cuyo repositorio es público en Github. Bien podemos compilarlo de allí o bien descargamos un archivo de procesos por lotes, que hace el trabajo por nosotros desde un dominio especialmente dedicado a ello:

curl -s https://getcaddy.com | bash

También en su página web podremos “pedir a la carta”: elegir sistema operativo, complementos y características en un asistente muy fluido que prepara el paquete personalizado a descargar e instalar. Está disponible para Android, Solaris, BSD, Linux, Windows y Mac y viene listo para usar:

• Ya dijimos, tiene HTTP 2.0 por defecto instalado y configurado.
• Tiene soporte HTTPS por defecto gracias a Let’s Encrypt, una organización que suministra certificados digitales sin coste y por mecanismos de comprobación basados en normas DNS: el Servidor Web Caddy se encarga de cumplir y entregar esas normas DNS y, además, renueva por nosotros de manera automática los certificados digitales a su vencimiento (incluyendo los subdominios). Pese a esto, seguimos recomendando mantener una monitorización constante de estos certificados digitales con Pandora FMS: “No nos vamos a dormir en los laureles de las victorias”.
• TLS está fortalecido y es inmune a ataques tipo Heartbleed; incluye varias tecnologías de cifrado a escoger, como ECC, ChaCha y AES-GCM, entre otros.
• Tiene apoyo, por defecto, para manejar varios dominios web (virtual hosting): esto y otros valores se cambian en un simple fichero llamado “Caddyfile”, que guardaremos en cada directorio que necesitamos exponer y ejecutaremos allí con el comando caddy en una ventana terminal (también lo podemos ejecutar como servicio o demonio).
• Tiene muchísimos complementos: por ejemplo, podremos instalar uno para trabajar con Interfaz de Entrada Común (“Common Gateway Interface” o CGI) y también FastCGI, lo que nos abre las puertas para desarrollar guiones en cualquier lenguaje o reutilizar los existentes, como los hechos en lenguaje Perl, que son ampliamente conocidos.
• Provee mejoras en la gestión de manera automática de los TLS para cifrar conexiones.
• Para los programadores: se puede agregar un Servidor Web Caddy para ser compilados juntos. Es decir, ¡puede ser usado como una librería! (Lenguaje Go).
• Podremos escribir código Markdown y será servido en HTML.
• En cuanto a la monitorización, en el “Caddyfile” agregaremos en una línea “log /var/log/acces.log” (o la ubicación que necesitemos); de manera predeterminada los registros serán rotados. Pero no solamente podremos guardar en un archivo: también permite STDOUT/STDERR o en un registro remoto. Más aún: si asignamos Identificador Único Universal a las solicitudes, las podremos incluir en las cabeceras HTTP y también guardarlas en los registros, junto con el resto de los datos.

Todas estas características pueden ser implementadas en otros servidores web con trabajo adicional: con el Servidor Web Caddy viene todo incluido.

Lo único constante es el cambio

En este paseo de la innovación va a ser que nos extendimos; sin embargo, hay muchas características que faltaron por describiros de este software abierto para todos y todas. En Pandora FMS nos esforzamos para mantenernos al día en la monitorización de todo tipo de aplicaciones. ¿Tenéis algún requerimiento especial? ¡Contáctanos!