¿Qué son los certificados SSL? Hablamos de encriptación

Seguro que recientemente has escuchado las siglas «SSL»: Has empezado a fijarte que el navegador te avisa de que estás navegando por un sitio «No seguro» pero no sabes muy bien de que se trata. Vamos a intentar aclararlo un poco.

En Internet la comunicación se realiza mediante distintos protocolos: HTTP, SMTP, FTP, SIP…. cada uno de estos protocolos no son más que unas normas de cómo pedir información y cómo devolverla. Además para simplificar su desarrollo suele ser muy sencillo el poder leerlos ya que se pasan entre el cliente (quien origina la petición) y el servidor (quien recibe y procesa la petición) en texto plano totalmente legible. Este sería un ejemplo del protocolo HTTP, la petición realizada y la respuesta recibida al cargar este blog:

Como se puede leer hemos pedido (GET) una página (http://blog.sarenet.es) y el servidor nos ha devuelto la página (lo que sería el código HTML que luego nuestro navegador interpreta y nos muestra) con una serie de datos extra.

En un mundo ideal no habría problema pero, ¿qué ocurre si alguien «intercepta» estos mensajes entre mi ordenador y el servidor? ¿Y si en vez de en un blog estoy metiendo los datos de la tarjeta en una tienda? ¿Y si son mis datos médicos? ¿Y si estoy intentado enterarme de qué ocurre realmente en mi país?

Aquí es cuando se empiezan a desarrollar métodos extra para poder enviar esta información a través de Internet de una forma que sólo el origen y el destino que han iniciado la «conversación» puedan entenderse y aquí entran en juego el cifrado del mensaje.

Nota: Para simplificarlo hablaremos sobre SSL aplicándolo a páginas web y al protocolo HTTP, pero hay que tener en cuenta que se puede implementar en más protocolos.
 

¿Qué es la encriptación?

 
Con los certificados SSL utilizamos un sistema de claves públicas/privadas para cifrar la información. Este sistema nos permite poder intercambiar «secretos» aún cuando se interpretan mensajes enviados, ya que hay partes que nunca se envían.

Este vídeo, aunque en inglés, explica de forma muy clara y sencilla como funciona el intercambio de claves de forma que sólo el origen y el destino pueden «descifrar» los mensajes.

En el caso de los certificados SSL el procedimiento es el siguiente para la generación de claves privadas y públicas:

• En el servidor que va servir la web segura se genera una clave privada que únicamente el servidor puede conocer. Es muy importante que esta clave no se divulgue ya que es lo que permite «firmar» los mensajes con el certificado.
• Con esta clave se genera el certificado que se configura en el servidor y que cualquiera puede descargarse.

Con estos dos archivos tendríamos ya nuestra web protegida con SSL y la información entre los clientes y el servidor se haría de forma cifrada.  Esto se puede hacer en un servidor con un par de comandos y tendríamos lo que se denomina un certificado autofirmado, el propio servidor es el que ha dicho que se trata de él mismo.

¿Qué son las entidades certificadoras?

 
En el ejemplo anterior queda claro que hay algo que cojea, y es que si cualquiera puede decir que es tal web… ¿Cómo sabe el usuario si se está conectando al sitio bueno o a una página de phising?

Para eso existen lo que se conocen como entidades certificadoras (CA en inglés), que son las que, valga la redundancia, certifican que el certificado que están firmando es para la web que lo solicita. Dependiendo del nivel de certificación hay distintos tipos de certificados que ofrecen más o menos «seguridad» al usuario (poner en verde la barra, poner el nombre de la empresa en la barra de direcciones, etc. a nivel de encriptación es la misma que un certificado autofirmado).

Para que una entidad nos certifique hay que enviarles primero una solicitud de firma de certificado o CSR, en inglés. Esto no es más que un archivo en el que indicamos el dominio del certificado y la empresa que lo solicita, pero que va firmado con la clave privada que hemos generado previamente.

Una vez que la entidad lo tiene inicia una serie de validaciones y comprobaciones, que pasan desde una simple consulta a la DNS a búsquedas en listines telefónicos y llamadas al contacto para confirmarlo.

Una vez confirmado «emiten» el certificado, pero firmado con su clave privada en vez de con la nuestra, de manera que se forma una cadena de certificados.

Los certificados públicos de estas empresas van «de serie» en los navegadores y sistemas operativos por lo que estos se fían de lo que ellas digan, de forma que la identidad queda totalmente confirmada. En este esquema del lateral se ve un poco más claro (mejor pincha para verlo a tamaño completo).
 

La modernización de certificados

 
Como comentaba al principio, con la globalización y las posibilidades que nos ofrece Internet, la privacidad de los usuarios está tomando cada vez más importancia y no sólo ya los datos como tarjetas de crédito y datos bancarios. En los últimos años y con todos los problemas de filtraciones, bloqueos de internet por parte de países completos, etc. los grandes de internet se han puesto las pilas, primero de puertas para adentro  y posteriormente de cara al público.

Este último punto ha hecho que el uso del SSL haya aumentado mucho en los últimos años, trayendo consigo dos cambios:

• Modernización por parte de las entidades certificadoras.
• Salida a la luz de bugs y fallos en el propio protocolo de SSL.

El primer punto ayuda tanto al usuario final como a nosotros, como proveedor de soluciones de telecomunicaciones para empresas. Con entidades como Let’s Encrypt ahora es posible obtener un certificado totalmente válido en cualquier navegador de forma gratuita, y lo que es mejor, automatizar todo el proceso de forma que se pueda solicitar y renovar sin intervención manual (os puedo asegurar que tratar con las entidades certificadoras de toda la vida se parece mucho a hacerlo con Burocracia Central y que muchas veces son solicitudes con mucho papeleo).

Por otro lado han salido mil y una vulnerabilidades en las implementaciones de SSL, como por ejemplo OpenSSL. Esto ha generado que, a pesar de todas las veces que he dicho SSL en esta entrada, lo que se usa de forma efectiva y que está configurado en los servidores es el protocolo TLS. No voy a entrar en detalle pero básicamente podríamos resumir TLS y SSL en que es la forma en la que se intercambian las claves públicas y privadas y que el protocolo de SSL tiene fallos que TLS ha mejorado.

El pasar a TLS ha permitido entre otras cosas el poder configurar varios certificados SSL en una única dirección IP (lo que se conoce como SNI -prometo que es el último acrónimo nuevo de la entrada-), algo que la gente de Sistemas pedíamos desde hacía tiempo. El protocolo SSL tenía una limitación y es que hasta que no se negociaba la encriptación no mandaba ningún dato, por lo que era necesario dedicar IPs públicas a certificados, una limitación a la hora de crecer, ampliar plataformas, configurar altas-disponibilidades, etc.

Adicionalmente, para ayudar a comprobar la seguridad y ver si realmente está bien instalado un certificado, existen herramientas como el test de Qualys Labs que comprueba vulnerabilidades y encriptación de los sitios donde se puede ver de una forma fácil el nivel de configuración SSL de una web y las posibilidades de mejora del sitio.

Hacer de Internet un sitio más seguro

 
En definitiva todo el paso a SSL que se está realizando desde un tiempo hacia esta parte, viene realizado con el usuario final en mente a pesar de los muchos dolores de cabeza que nos está dando tanto a desarrolladores como a administradores de sistema.

Contacta ahora con Sarenet