HTTPS

  • 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).

  • Este artículo explica brevemente cómo compilar Nginx desde sus fuentes con soporte para SSL (HTTPS) en Debian y derivados.

  • Esta semana tuve la necesidad de habilitar SSL en un servidor Web que aloja diferentes dominios (cada uno con su certificado SSL/TLS provisto por Let's Encrypt). El problema es que este servidor Web posee una única dirección IP a la cual resuelven todos los nombres de host de los diferentes dominios y sitios Web hospedados en el mismo.

    Tradicionalmente sólo se podía habilitar SSL en un sitio Web si éste estaba ligado a una y sólo una dirección IP en particular. Esto era una limitación muy grande pues si, por ejemplo, necesitaba habilitar SSL en 3 sitios Web diferentes, necesitaba 3 direcciones IP dedicadas a cada uno.

    Afortunadamente, con la llegada de Apache 2.2.12 en 2009 se agregó el soporte para SNI (Server Name Indication). SNI es una extensión del protocolo TLS a través de la cual los clientes le indican al servidor el nombre de host al cual están tratando de conectarse, para que éste les envíe el certificado correspondiente. De esta forma es posible tener múltiples certificados asociados a diferentes nombres de host en una misma dirección IP. Por supuesto los clientes deben soportar esta extensión.

    Actualmente la mayoría de los clientes soportan esta extensión, a excepción de unas pocas librerías y sistemas operativos cuasi-obsoletos como Symbian o Blackberry OS, al igual que el navegador de línea de comandos ELinks.

    Gracias a SNI es posible configurar sitios HTTPS basados en nombre, de la misma forma en que se configuran sitios HTTP basados en nombre (VirtualHosts).

  • Este artículo explica cómo configurar SSL para implementar HTTPS en un servidor Web Apache sobre sistemas Debian/Devuan y derivados. En la actualidad es imprescindible contar con soporte para HTTPS en nuestros sitios Web, ya que Google desde hace un par de años está poniendo el foco en la seguridad en Internet (de hecho la considera una de las principales prioridades) y el buscador valora el soporte para HTTPS como un factor de peso al momento de posicionar.

  • Anteriormente demostré cómo forzar el uso de HTTPS (HTTP sobre SSL/TLS) en Apache. Esta vez voy a demostrar cómo implementarlo en un servidor Web Nginx.

  • Los certificados son el medio utilizado para implementar SSL (Secure Sockets Layer). SSL es la tecnología de seguridad estándar para establecer conexiones cifradas (encriptadas) entre un cliente y un servidor. Pero además de proveer conexiones cifradas, SSL permite asegurar la autenticidad de clientes y servidores. Esto sirve, por ejemplo, para garantizar la identidad de los servidores Web en Internet. ¿Cómo puede, un cliente que desea utilizar un servicio de Home Banking, asegurarse de que se está conectando efectivamente al servidor Web de su banco y no a un servidor falso que está tratando de robarse sus credenciales? Gracias a los certificados.

  • Certbot es un cliente ACME automático y fácil de utilizar, que obtiene certificados SSL/TLS gratis para tu sitio Web, provistos por Let's Encrypt. Certbot fue desarrollado por la EFF (Electronic Frontier Foundation) como "cliente oficial" de la autoridad certificante de Let's Encrypt, pero también funciona con cualquier CA que soporte el protocolo ACME (Automated Certificate Management Environment).

    Certbot (anteriormente el cliente Let's Encrypt letsencrypt-auto) es el cliente recomendado por Let's Encrypt para emitir sus certificados, y opcionalmente auto-configurar HTTPS en tu servidor Web.

    Este artículo explica cómo emitir un certificado SSL/TLS gratuito de Let's Encrypt utilizando el cliente certbot utilizando el plugin webroot en Debian 7 (wheezy).

  • 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.

  • Finalmente Let's Encrypt ha entrado en su fase Beta de acceso público, por lo que ya no se necesita una invitación para obtener un certificado SSL de forma gratuita. Para aquellos desprevenidos, Let's Encrypt es una nueva autoridad certificante libre, abierta, automática y (lo mejor de todo) gratuita. Esperemos que este proyecto tenga éxito (seguramente lo tendrá pues está patrocinado por la Linux Foundation), y así se termine con el curro de los certificados. No puede ser que grandes empresas se hayan hecho millonarias simplemente emitiendo certificados SSL de confianza, cuando éstos deberían ser un recurso básico de acceso universal. HTTPS tiene que ser el estándar por defecto, y la seguridad tiene que ser un derecho de acceso público y gratuito para todos los sitios de Internet. De otra forma, al tener que pagar para acceder a la seguridad (como sucede actualmente), nunca llegaremos a una Internet segura y confiable.

    En este artículo voy a explicar cómo obtener e instalar un certificado gratuito de Let's Encrypt, sobre un servidor Debian con Nginx.

  • Un pregunta de un lector en la entrada Hardening de SSL/TLS en servidores HTTPS me llevó a buscar y probar una solución para este problema: cómo predecir el impacto, en los clientes de un sitio Web, al deshabilitar un protocolo inseguro dentro de la configuración de suites de cifrado de TLS.

    Este lector en particular, necesitaba saber si alguno de sus clientes se verían afectados al deshabilitar el algoritmo criptográfico de encriptación de flujo RC4, el cual es inseguro (vulnerable a un amplio abanico de ataques y ya sin soporte por los principales navegadores). La solución consiste en lograr que el servidor Web registre en el log de accesos el protocolo y suite de cifrado elegidas durante la negociación (handshake) para cada acceso. De esta forma es posible, luego de un tiempo, determinar si existen cliente que aún utilizan el protocolo/suite de cifrado que deseamos deshabilitar (para mejorar la seguridad).

  • 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.

  • Transport Layer Security (TLS) y Secure Sockets Layer (SSL) son protocolos criptográficos que proveen una conexión segura a través de Internet. Utilizan criptografía asimétrica para autenticar claves de intercambio, criptografía simétrica para lograr confidencialidad y funciones hash llamadas MAC para verificar integridad.

    Los servidores Web, por ejemplo Apache, utilizan TLS y SSL para implementar el protocolo HTTPS (Hypertext Transfer Protocol Secure). A través de este protocolo los clientes pueden navegar sitios de forma segura garantizando confidencialidad (los pedidos sólo pueden ser interpretados por el cliente y el servidor), integridad (los pedidos no han sido alterados durante el tránsito) y autenticidad (el servidor es quien dice ser). De esta forma se evita: 1- Que un tercero sea capaz de "ver" el tráfico entre cliente y servidor, y obtener información confidencial o sensible en la comunicación; 2- Que un tercero sea capaz de interponerse entre cliente y servidor para alterar pedidos o respuestas (ataque man-in-the-middle); 3- Que un servidor de un tercero se haga pasar por otro (por ejemplo: un servidor atacante que se hace pasar por el servidor del banco, generalmente involucra un ataque DNS previo o algún tipo de XSS).

    Gracias a HTTPS podemos navegar tranquilos por portales de bancos, correo electrónico, etc. En la actualidad debería ser un estándar de facto en la industria, pero lamentablemente existen muchos sitios Web que aún no lo utilizan, y a veces nuestras credenciales e información sensible viajan por la red en formato "plano", es decir sin codificar, al alcance de cualquier atacante.

    Este artículo explica cómo instalar y configurar SSL en Apache, utilizando un servidor CentOS 6.4 como ejemplo.

  • Este artículo demuestra cómo implementar un proxy reverso con soporte para SSL/TLS para una instalación de Home Assistant utilizando Nginx. Cabe destacar que no se cubre el proceso de instalación y configuración de Hass.io, sólo la configuración del proxy HTTPS reverso, la cual resulta un tanto particular a fin de que las aplicaciones conectadas funcionen correctamente.

    Home Assistant es una tecnología de automatización para aplicaciones de domótica de código abierto que permite convertir a un dispositivo embebido (como una Raspberry Pi) en un sistema de control centralizado de nuestro hogar. Las ventajas de utilizar Hass.io son muchas, entre las que se destacan su naturaleza libre y open source; el hecho de que esté optimizado para dispositivos como la Raspberry Pi; simplicidad de instalación; y la posibilidad de controlar nuestro hogar desde una interfaz Web.

    Esto suena muy bonito pero, claro está, se requiere implementar un cierto nivel de seguridad para llevarlo a la práctica. Por ello en este artículo explico cómo configurar un proxy reverso con Nginx para implementar HTTP/S y garantizar una comunicación segura entre nuestro smartphone y la Raspberry hogareña.

  • Este artículo explica cómo lograr que un sitio MediaWiki funcione correctamente tanto sobre HTTP como sobre HTTPS.

  • Este breve artículo explica cómo redireccionar todo el tráfico HTTP a HTTPS para todos los VirtualHost de un servidor Apache. El objetivo es forzar HTTPS para todos los sitios alojados en nuestro servidor Apache.

  • Anteriormente expliqué cómo instalar GitLab desde los fuentes en Debian. Veamos ahora cómo habilitar el soporte para HTTPS para que el sitio sea seguro.

  • Este artículo explica cómo configurar un servidor Web Nginx de forma segura, que acepte pedidos sólo a través de TLS (redireccionando de forma automática todos los pedidos HTTP a HTTPS), de forma que todo el tráfico entre los clientes y el servidor sea encriptado utilizando sólo los protocolos TLS más fuertes. Para ello se deshabilitará la compresión SSL para evitar el ataque CRIME, también SSLv3 e inferiores debido a sus vulnerabilidades, y se configurará una suite de cifrado fuerte que permita Perfect Forward Secrecy (PFS) cuando sea posible.

  • El objetivo de este artículo es proveer una guía para mejorar la implementación de un servidor Web seguro utilizando SSL/TLS, particularmente el caso de servidores Apache con mod_ssl (OpenSSL). Se trata de un conjunto de buenas prácticas de seguridad en servidores SSL, junto con un par de herramientas interesantes para determinar en qué estado de seguridad se encuentra tanto nuestro servidor Web como nuestro cliente.

  • Lamentablemente, el cliente letsencrypt-auto que se utiliza para generar certificados TLS de Let's Encrypt no está pensado para acceder a Internet a través un proxy HTTP/HTTPS. Entonces, ¿qué pasa si necesitamos emitir un certificado para uno de nuestros servidores, dentro una red corporativa, detrás de un proxy HTTP? No queda otra alternativa que realizar algunos cambios en el script (estas son las grandes ventajas de utilizar soluciones abiertas, se pueden modificar/adaptar a las necesidades de cada uno).

    Este artículo explica cómo modificar el script letsencrypt-auto para que funcione utilizando un proxy HTTP/HTTPS.