Plataforma

Asegurar webs con SSL

?php the_title(); ?>

La extensión Secure Sockets Layer, que convierte el protocolo HTTP en algo mucho más seguro que su implementación básica, forma parte de las tecnologías web casi desde sus inicios. Al principio, la idea que teníamos todos es que sólo era útil para páginas o aplicaciones que tuvieran que operar con datos bancarios; posteriormente empezó a verse su valor para aumentar la confidencialidad de cualquier transacción en la que intervengan datos privados de usuarios o empresas. Recientemente se ha dado un paso más; con el anuncio de Google de que cualquier web que funcione con SSL puntuará más alto en su sacrosanto algoritmo de ordenación de resultados de búsqueda, este protocolo se convierte en un requerimiento básico para SEO. Parece que nos están animando a que toda la web funcione con SSL.

SSL se basa en algoritmos de encriptación de clave asimétrica; es decir, en vez de utilizar una contraseña única para encriptar, se utiliza un par de claves asociadas de manera que lo que se encripta con una de ellas, se debe desencriptar con la otra. Llamamos a una clave pública, que puede y debe conocer cualquiera; y la otra es la clave privada, que debemos mantener en secreto absoluto. Esto sirve para dos cosas:

  • Encriptar el mensaje: cada emisor o receptor en la comunicación tiene un par de claves. Si encripto algo con la clave pública de mi receptor, sólo el que tenga su clave privada asociada podrá desencriptarlo.
  • Firmar el mensaje: si además incluyo en el mensaje una firma (resumen del mensaje completo, encriptado con mi clave privada), el receptor puede desencriptar la firma con mi clave pública, regenerar la firma a partir del mensaje, y si coinciden, eso es una garantía de que el mensaje lo he enviado yo realmente, y de que el mensaje no ha sido alterado.

En una comunicación SSL, tanto el cliente (un navegador o una aplicación que consuma un servicio) como el servidor (aplicación web) poseen un certificado; un certificado es un fichero que contiene una clave pública, información sobre a quién pertenece, y una firma proporcionada por una autoridad certificadora. Hay una serie de autoridades certificadoras reconocidas, que suponen una garantía fiable de que los certificados que emitan y firmen pertenecen realmente a quien dicen pertenecer.

A la hora de configurar nuestra aplicación web con un certificado, debemos adquirirlo a una de estas autoridades certificadoras. En el proceso de compra, dicha entidad hará algún tipo de comprobación de identidad antes de emitir nuestro certificado. Un certificado se asocia a un dominio concreto, o por un precio algo más elevado, a todos los subdominios de un dominio. A continuación debemos instalarlo en nuestro servidor web junto a su clave privada asociada.

En cuanto al software cliente, todos los navegadores implementan el protocolo SSL, lo que quiere decir además que poseen un certificado que les identifica y tienen una lista de autoridades certificadoras que consideran fiables. A la hora de consumir servicios web, nuestro lenguaje de programación o plataforma de desarrollo es el que hace las veces de cliente, y el que tendrá que cumplir los requisitos indicados.

A lo largo del tiempo han ido surgiendo nuevas versiones del protocolo, y nuevas autoridades certificadoras; y algunas de esas versiones se han dado de baja por descubrirse errores que las hacían poco seguras. Por tanto, nuestro software cliente y servidor deben estar siempre actualizados para cumplir con las últimas versiones.

A la hora de trabajar con certificados SSL podemos encontrar una serie de problemas típicos:

  • Hemos mencionado que la adquisición de un certificado implica un proceso de verificación de identidad. Si estamos solicitando un certificado para nosotros mismos, esto no debería suponer un problema dado que tenemos el control de nuestros propios recursos; pero si un proveedor de servicios internet solicita un certificado en nombre de un cliente, lógicamente la identidad a verificar debe ser la del cliente y no la del proveedor. Esto puede hacer el proceso un poco más complejo.
  • Para dar un website por seguro, el navegador requiere que el certificado esté emitido por una autoridad certificadora reconocida, y asociado al mismo dominio con el que se está sirviendo la página. Es posible asociar un certificado a dominios distintos, e incluso crear un certificado sin autoridad certificadora (lo que se conoce como certificados autoemitidos); pero, dado el riesgo de suplantación de identidad que esto supone, los navegadores muestran en esos casos avisos cada vez más alarmistas, y en las últimas versiones, impiden el acceso al website salvo que el usuario lo autorice muy explícitamente.
  • Si el HTML principal de la página se sirve a través de SSL, pero algunos de sus recursos asociados (imágenes, hojas de estilos, código JavaScript) lo hacen a través de HTTP no seguro, es posible que algunos navegadores muestren avisos; o, en los casos más extremos, no descarguen los elementos no seguros, lo que puede afectar al aspecto o incluso el funcionamiento de nuestra aplicación web. Si los enlaces a los recursos son relativos, no es problema puesto que se servirán igual que la página; pero si tenemos que enlazar a recursos externos (servidores CDN, servicios de etiquetado para estadísticas), es algo que debemos tener en cuenta.
  • Mencionábamos antes que es importante que el certificado esté asociado al mismo dominio que está sirviendo la página o aplicación. Esto tiene una implicación muy significativa cuando tenemos un servidor web con varios hosts virtuales: dado que el servidor distingue a qué host estamos accediendo gracias a una de las cabeceras indicadas en la petición HTTP, y dado que la cabecera va encriptada con una clave asimétrica asociada al certificado, el servidor no puede saber qué certificado corresponde a nuestro website hasta que ya lo ha seleccionado para realizar el desencriptado. Por tanto, todos los hosts virtuales quedarán asociados al certificado que tenga el primero. Hay varias soluciones para esto:
    • Se puede adquirir un certificado SAN, que puede tener varios nombres adicionales pero con una subcadena común. Lógicamente esto sólo nos sirve para determinados casos.
    • Existe una extensión del protocolo SSL, llamada SNI, que soluciona la limitación antes descrita. El único problema es que tanto el servidor como el cliente tienen que reconocerla; es posible que no funcione con navegadores, plataformas de desarrollo y servidores de aplicaciones un poco antiguos.
    • Podemos asociar cada dominio que necesite un certificado propio a una dirección IP diferente; esto nos permite configurar el servidor web de forma que cada IP tenga asociado un servicio SSL con el certificado que le corresponde. Esto sirve para todos los casos, pero tiene el coste extra de asociar IPs adicionales a nuestro servidor, y de complicar un poco la configuración.

En el caso de la última solución, hay una alternativa muy interesante, consistente en configurar un servicio de balanceo para cada dominio con certificado. Así, asociamos IPs a servicios de balanceo separados, en vez de a un mismo servidor, lo que facilita la configuración; y podemos hacer que sea el propio balanceador el que ejecute el encriptado y desencriptado asociados al protocolo SSL, descargando de ese trabajo la CPU del servidor de aplicaciones. Esta es la mejor opción, aunque tiene una implicación a tener en cuenta: nuestro servidor ya no ejecutará nuestra aplicación en modo seguro. Aunque la configuración de red habitual hace que esto no sea un problema de seguridad, si puede afectar a la forma de desarrollar las aplicaciones.

En Yunbit llevamos desde los inicios de nuestra andadura gestionando páginas y aplicaciones web con SSL, y hemos seleccionado los partners más adecuados para adquirir y configurar certificados de forma más eficiente para nuestros clientes.

Valora el artículo:

1 Estrella2 Estrellas3 Estrellas4 Estrellas5 Estrellas (3 valoraciones, media: 3,67 sobre 5)
Loading...
Mario Villar Mario Villar Director Tecnológico Ver más artículos de Mario Villar

¿Y tú qué opinas?

Posible error

Otros artículos de la categoría Programación