HTTP

  • El protocolo HTTPS es una versión segura del protocolo HTTP que implementa un canal de comunicación basado en SSL (Secure Socket Layer) entre el navegador cliente y el servidor HTTP el cual provee autenticidad (mediante certificados) y privacidad (mediante encriptación). El protocolo HTTP se basa en TCP/IP, el cual es un canal de comunicación no seguro donde la información realiza un número de saltos entre diferentes routers que se encargan de hacer llegar la información desde el cliente al servidor o destino. En cada uno de estos saltos, la información es transmitida en la red local del router, pudiendo ser capturada con fines maliciosos.

    Salvo que se utilice IPsec es imposible evitar que se capture nuestra información, pero utilizando HTTPS es posible codificarla para que una vez capturada (mediante sniffing) no pueda interpretarse (y así poder enviar con tranquilidad números de cuenta, datos personales, etc.).

  • Tal como mencioné en el artículo ¿Cuáles son las principales diferencias entre los sistemas GNU/Linux y OpenBSD?, OpenBSD utiliza CVS como sistema de control de versiones. Específicamente utiliza CVS anónimo para mantener actualizada una copia local del source tree de OpenBSD, respecto a los cambios hechos en los fuentes actuales de OpenBSD. Este mecanismo es un sistema de control de versiones "tolerante" en el sentido que respeta los cambios realizados en una copia local, y hace el "mejor esfuerzo" para actualizar el source tree completo, más que dejar una lista de problemas a resolver antes de continuar (tal como ocurre con otros sistemas de control de versiones).

  • A medida que pasan los años, Internet deja de ser una red libre para convertirse, cada vez más rápidamente, en un lugar controlado, censurado, filtrado y bloqueado. Tal vez impensado hace algunos años, hoy es común tolerar casos de censura burda y cruda por parte de gobiernos, corporaciones (o en el trabajo/oficina/escuela) y proveedores de servicios de Internet (ISPs), tal como el caso del bloqueo a Twitter por parte del gobierno turco para cubrir un escándalo de corrupción.

    Por esta razón, los usuarios con ciertos conocimientos de redes y sistemas debemos contar con todas las técnicas y herramientas que nos permitan escapar del control, censura, filtrado y shaping de tráfico. Para cuidar nuestra libertad, que es lo más importante que tiene Internet según mi parecer.

    En esta ocasión me complace presentarles este artículo que explica detalladamente cómo escaparle a la censura de una red corporativa y un proxy HTTP restrictivo. Todo nació a causa de que el proxy HTTP de mi red corporativa no me permite visitar alexa.com (el sitio de estadísticas de accesos a sitios Web propiedad de Amazon). Tal vez por parecer una URL de página triple equis, o el nombre artístico de un travesti (?). La cosa es que no puedo entrar a alexa.com. Challenge accepted.

  • Este artículo explica cómo conectarse a servidores HTTP utilizando netcat a fin de diagnosticar conexiones, cabeceras y respuestas HTTP.

  • A veces necesitamos acceder a alguno de nuestros servidores para realizar tareas de mantenimiento y no podemos usar SSH en el puerto estándar 22 debido a que estamos dentro de una red corporativa detrás de un firewall restrictivo. En este caso es posible crear un túnel SSH a través de un servidor proxy HTTP. Dependiendo del nivel de seguridad del firewall se podrá acceder por SSH por cualquier puerto o sólo por el puerto 443 (HTTPS).

  • Anteriormente demostré cómo permitir y denegar el listado de directorios en un servidor Apache. Este artículo explica cómo permitir que Nginx muestre un listado de los archivos dentro de cierto directorio Web.

  • En este artículo voy a explicar cómo habilitar el soporte para el protocolo HTTP versión 2 en Nginx. HTTP/2 es la nueva versión del protocolo HTTP que utilizamos a diario para navegar páginas y sitios Web. Está basado en el protocolo experimental SPDY (desarrollado originalmente por Google) y se trata de la primera actualización mayor de la versión en casi dos décadas (HTTP/1.1 fue lanzado en 1999).

    Las meta de desarrollo de esta nueva versión fue reducir la latencia, para mejorar la velocidad de carga de páginas en los navegadores. Para ello, se agregó compresión en los headers HTTP (a fin de reducir el tamaño de los mismos); un mecanismo de push para que los servidores puedan enviar datos a los navegadores de manera asincrónica (sin necesidad de un request); pipeline de solicitudes (para mejorar el ancho de banda) y multiplexado de solicitudes a través de una misma conexión TCP (para reducir la sobrecarga del mismo); entre otros. A su vez, se agregó un mecanismo de negociación para que los clientes puedan escoger entre HTTP/1.1, HTTP/2 u otro.

    Todo esto, manteniendo compatibilidad con la versión 1.1. HTTP/2 mantiene la sintaxis de alto nivel de HTTP/1.1 casi intacta, al igual que los códigos de estado, cabeceras, etc. Lo que cambia (mejora) es la forma en que los datos e información son transferidos.

  • Apache Tomcat (o simplemente Tomcat, anteriormente conocido como Jakarta Tomcat) es un servidor web y servlet container Open Source desarrollado por la fundación Apache (Apache Software Foundation). Tomcat implementa las especificaciones de Java Servlet y JavaServer Pages (JSP) de Sun Microsystems, y provee un entorno de servidor Web HTTP donde el código Java pueda ejecutar.

    Debido a que el servidor Tomcat no posee soporte para HTTPS, el objetivo de este artículo es demostrar cómo implementar un proxy reverso (implementado utilizando Apache) para dar soporte HTTPS a Tomcat. La comunicación entre Apache y Tomcat se realiza a través del conector "mod_jk", el cual se instala como un módulo de Apache.

  • Apache, más precisamente Apache HTTP Server, es un servidor Web multiplataforma seguro, eficiente y extensible de código abierto. Provee la funcionalidad suficiente para cubrir todos los requisitos especificados por los estándares del protocolo HTTP actual.

  • OpenBSD incluye su propia implementación de servidor Web llamado httpd, basado originalmente en relayd, y que (como todo proyecto relacionado a OpenBSD) apunta a la seguridad y en este caso en particular a la escalabilidad.

    httpd es un servidor Web seguro y minimalista (apunta a evitar la "featuritis" que sufren los servidores Web más importantes, notablemente Apache), que sirve archivos estáticos y soporta FastCGI y TLS. Incorpora algunas características básicas como listado de directorios, logging y autenticación basic. Para conocer la historia completa de httpd y cómo comenzó su desarrollo es recomendable el paper Introducing OpenBSD's new httpd.

    El objetivo de este artículo es montar el clásico servidor Web con soporte para PHP sobre un sistema OpenBSD. Y ya que httpd es el servidor Web por defecto en OpenBSD, se explica la instalación y configuración del mismo, en lugar de instalar Apache o Nginx desde los paquetes o ports.

  • Este artículo explica cómo recibir parámetros HTTP vía GET, es decir como argumentos en la URL (llamado query string), en scripts CGI Python.

  • Esta fue una semana de respuestas HTTP un tanto insólitas para mí. Luego de haber comentado mi experiencia diagnosticando una respuesta HTTP 503, esta vez me tocó solucionar el caso de una respuesta HTTP 413 en un servidor Nginx:

  • A veces hay que aplicar alguna configuración de emergencia para resolver un problema urgente, pero la misma puede afectar a los usuarios que están conectados actualmente a un servidor. Existe una variedad de causas diferentes que pueden perjudicar a los usuarios actuales de un servicio. Por ejemplo puede hace falta reiniciar Apache, o directamente detenerlo porque es necesario reiniciar un servidor de bases de datos. También podría ser necesario reiniciar directamente el sistema operativo por un problema de hardware (se llenó un disco y hay que ampliar su capacidad, o agregar más memoria RAM). Sea como sea, los Sysadmins en general buscamos un horario fuera de oficina para este tipo de "actividades", pero en caso de emergencias, no queda otra alternativa que hacerlo en horarios de oficina. En este caso puede ser útil saber si hay usuarios actualmente conectados al servidor, para afectar a la menor cantidad de gente posible.

  • En este breve artículo comparto una experiencia con un servidor Apache retornando "503 Service Unavailable":

  • Cuando veo cosas como estas me saco el sombrero ante los rusos, son genios del spam, verdaderos maestros artistas del spam, virus, botnets, etc. El hecho es que desde hace algunos meses linuxito.com está siendo víctima de una nueva técnica de spam en los referals HTTP.

  • Revisando las estadísticas de visitas a Linuxito en Google Analytics, me encontré con la siguiente notificación:

    Este mensaje básicamente dice que se están recibiendo estadísticas desde más de un dominio, en este caso "linuxito.com" y "www.linuxito.com", lo cual puede alterar la visualización de datos en los reportes de Analytics. Pero además (peor aún) puede traer problemas de contenido duplicado. Tal como mencioné en mi guía básica para SEO y posicionamiento, y tal como recomienda Google, es conveniente indicar cuál es el dominio "preferido" para nuestro sitio Web a través de una redirección permanente (301).