SSL

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

  • Este artículo explica cómo analizar las suites de cifrado y protocolos SSL/TLS soportados por un servidor Web, desde línea de comandos, utilizando la herramienta "cipherscan" desarrollada y mantenida por la Fundación Mozilla.

    Existen muchas herramientas online para diagnosticar y verificar el nivel de seguridad ofrecido en la implementación de SSL/TLS de un servidor Web, por ejemplo el Test SSL de Qualys. Sin embargo, es importante disponer de una herramienta de línea de comandos para llevar a cabo la misma tarea, especialmente si necesitamos verificar el nivel de seguridad de SSL/TLS de servidores Web no accesibles desde Internet. A tal fin, dí con la herramienta cipherscan (creada por la Fundación Mozilla), la cual sirve para listar todas las suites de cifrado soportadas por un servidor HTTPS y su ordenamiento, al igual que analizar y verificar la información de certificados, opciones de TLS, OCSP Stapling y más.

  • Recientemente me tocó configurar un servidor MySQL para autenticar usuarios mediante certificados SSL en lugar de contraseñas. El mecanismo de autenticación necesita un certificado para el servidor MySQL y un certificado para cada usuario, todos firmados por la misma autoridad certificante (CA).

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

  • Este artículo describe en resumen cómo crear tu propia Autoridad Certificante (CA) y cómo crear y firmar tus propios pedidos de certificados. Estos certificados sólo sirven para uso personal ya que no son firmados por una autoridad de confianza, como un mecanismo de proveer una forma segura de comunicarse con tus servicios, para que las contraseñas o cualquier dato no viaje plano por la red.

    Para realizar todos los pasos del tutorial se requiere el paquete openssl instalado en la máquina utilizada para administrar los certificados o crear los pedidos de certificado.

    Este tutorial fue probado en Debian 6.02, pero funciona para cualquier distribución.

  • Un certificado autofirmado puede ser útil para implementar SSL en entornos de desarrollo/testeo, o para el caso en que no se cuente con presupuesto suficiente para comprar uno firmado por una autoridad certificante de confianza (aunque algunas autoridades certificantes como namecheap ofrecen certificados económicos). Un certificado autofirmado no sirve para garantizar la identidad de un servidor, pero al menos provee un canal de comunicación seguro. Generar un certificado autofirmado también sirve para entender el proceso de creación y firma de un certificado y sus diferentes componentes.

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

  • Luego de implementar mi servidor OpenLDAP con PostgreSQL como backend, el siguiente paso consistió en configurar SSL/TLS para implementar un nivel de seguridad mínimo en las comunicaciones entre el servidor LDAP y los clientes.

    Aunque se trabaje sobre un entorno de pruebas o desarrollo, es indispensable contar con un certificado de confianza válido. Esto se debe a que OpenLDAP no permite utilizar un certificado autofirmado para utilizar en el servidor. De este modo tenemos varias alternativas: comprar un certificado firmado por una entidad de confianza; generar un certificado gratuito con certbot; o crear nuestra propia CA autofirmada.

    Crear nuestra propia CA tiene sus ventajas, ya que nos permite generar cualquier número de certificados y nos da mayor flexibilidad, aunque implica una mayor cantidad de trabajo al momento de configurar el servidor LDAP. Este artículo explica cómo configurar OpenLDAP para que haga uso de un certificado generado a través de nuestra propia CA (de forma similar a como lo hace OpenVPN).

  • En artículos anteriores expliqué cómo crear tu propia autoridad certificante para generar certificados SSL autofirmados y cómo configurar HTTPS en Apache para acceder a un sitio Web de forma segura. También expliqué cómo autenticar usuarios MySQL utilizando SSL.

    La seguridad que ofrece SSL es muy buena y todo es color de rosas hasta que llega el momento de adquirir un certificado. Debido a que un certificado debe ser emitido (firmado) por una autoridad certificante de confianza, hay un costo a pagar, y generalmente es elevado. Por ejemplo una de las entidades certificantes más conocidas ofrece certificados SSL para implementar HTTPS por la, nada despreciable, suma de 70 dólares al año.

    Gracias a uno de mis patrocinadores, conocí a la entidad certificante StartSSL, la cual ofrece certificados SSL de manera gratuita, sí, gratis!

    Es por ello que me puse inmediatamente a tramitar mi certificado SSL para implementar HTTPS en mi blog. Esta vez firmado por una entidad de confianza, en vez de mi propia CA autofirmada.

    Actualización (24/3/2016): desde fines de 2015 es posible obtener un certificado SSL gratuito gracias al proyecto Let's Encrypt. Let's Encrypt es una nueva autoridad certificante libre, abierta, automática y gratuita patrocinada por la Linux Foundation. El proceso de creación y renovación de certificados con Let's Encrypt es mucho más simple y rápido que con StartSSL, por lo que recomiendo dirigirse al siguiente artículo: Cómo obtener un certificado SSL gratis de Let's Encrypt.

    Actualización (19/8/2016): StartSSL se ha renovado lanzando StartEncrypt, un servicio mucho más flexible, simple y fácil de utilizar. Acceder al artículo Obtener un certificado TLS gratis con StartEncrypt para obtener un certificado SSL/TLS de manera mucho más rápida y simple.

    Actualización (14/3/2017): Mozilla, Google y otros han dejado de confiar en el certificado raíz de StarCom debido a irregularidades técnicas y administrativas, por ende la única alternativa confiable y segura para obtener un certificado de forma totalmente gratuita consiste en generar un certificado SSL/TLS con certbot (anteriormente Let's Encrypt).

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

  • Uno de mis artículos más visitados es Cómo crear tu propia autoridad certificante (CA), el cual explica cómo crear una Autoridad Certificante (conocida vulgarmente como "CA") utilizando OpenSSL, para crear certificados SSL autofirmados. En esta oportunidad voy a explicar cómo renovar certificados que han expirado o están próximos a expirar en GNU/Linux utilizando OpenSSL.

    En el momento de firmar un certificado SSL, la autoridad certificante lo certifica (valga la redundancia) por un determinado período de tiempo de validez, por ejemplo un año o dos. Una vez pasado este tiempo, el certificado deja de ser válido y no puede ser utilizado para establecer comunicaciones seguras. Por lo tanto es común que los certificados expiren y deban ser renovados frecuentemente.

  • Llegó la hora de renovar por primera vez el certificado SSL provisto por Let's Encrypt para el blog. Recordemos que los certificados SSL que otorga Let's Encrypt (de forma gratuita) tienen una validez de sólo tres meses, por seguridad, claro está. Este breve artículo explica cómo funciona el proceso de renovación.

  • Luego de montar un servidor VPN con OpenVPN, y dejarlo corriendo durante algunos años, puede llegar el momento de necesitar dar de baja un usuario (revocar su certificado OpenSSL), o conocer la lista de usuarios habilitados (cuyo certificado es válido) y deshabilitados (cuyo certificado ha sido revocado). Cabe recordar que para simplificar la gestión de certificados OpenSSL, OpenVPN cuenta con un conjunto de scripts Bash dentro del directorio easy-rsa, los cuales son sumamente útiles y prácticos para aquellos administradores que no cuentan con suficiente experiencia o no están familiarizados con OpenSSL.

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

  • Este artículo explica cómo compilar Nginx con soporte para SSL en Debian y derivados.