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

Koldo Aingeru Marcos

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

Sobre este Autor

Administrador de Sistemas en Sarenet.

6 Comentarios

Puedes enviar comentarios en este post.


  • Si una empresa quisiera poner SSL/TLS en sus servidores por todo lo que muy bien se explica en la entrada, ¿qué sentido tendría que contratara un servicio de pago en lugar de utilizar un servicio gratuito cómo el que ofrece Let´s Encrypt?

    ¿Podríamos estar ante el fin de los servicios de pago en lo que a certificados SSL/TLS se refiere?

    ¿Qué diferencias puede existir entre un servicio de pago y Let´s Encrypt?

    Salu2

    Anónimo 5 meses ago Reply


  • Koldo Aingeru Marcos

    A día de hoy un proveedor como Thawte, Symantec, Izenpe, Digicert etc… puede ofrecer más tipos de certificados que los de Let’s Encrypt como pueden ser los multidominio o wildcard y sobre todo los de Validación Extendida, que son aquellos en que aparece el nombre de la empresa en la propia barra del navegador a parte del candado. Adicionalmente muchos de estos proveedores tienen también un seguro extra en caso de problemas de seguridad, robo de identidad, etc…

    La validación que hace Let’s Encrypt es bastante sencilla, o bien hace una comprobación de que exista un registro en la DNS o que existan ciertos archivos en el servidor, similar a como verifica Google los temas de Webmaster Tools. Para este blog es suficiente, pero cuando hablamos de cosas más “grandes” como puede ser un banco quieres estar seguro que estás entrando en ese banco y que alguien se haya preocupado ya de comprobarlo.

    Si que creo que Let’s Encrypt ha levantado la liebre y que no tardaremos en ver como este mercado cambia, hay muchas nuevas tecnologías que ya por definición necesitan SSL/TLS y vamos a necesitar muchos certificados y de forma rápida para ello. No sería la primera tecnología que a día de hoy es gratis y que hace unos años se pagaba a precio de oro.

    Koldo Aingeru Marcos 5 meses ago Reply


  • […] apoya en conceptos tecnológicos como Internet de las Cosas (IoT), Big Data o análisis de datos, Ciberseguridad, Robótica o Realidad Aumentada, para reorganizar los medios de producción y alinearlos con una […]

    Desarrollamos una plataforma IoT para la PYME industrial | Blog Sarenet 5 meses ago Reply


  • Respecto a los certificados ahora muy de moda, tengo una duda si un usuario tiene un dominio y utiliza este dominio para servir una tienda online que se encuentra en el Servidor A de un proveedor (por lo tanto tiene una IP) y utiliza también ese mismo dominio para un servicio de correo que se encuentra en un servidor B de otro proveedor; (otra IP distinta respecto a la del servidor A).
    ¿Cabe la posibilidad de tener certificados SSL/TLS para la tienda online y el correo?
    ¿En este caso sería necesario comprar 2 certificados uno por cada IP?

    doble_ip 4 meses ago Reply


  • […] de éxito se analizarán las diferencias y ventajas de la Cloud pública, privada e híbrida, la Ciberseguridad y el impacto de esta tecnología en las […]

    Agenda tecnológica: mayo de 2017 | Blog Sarenet 4 meses ago Reply


  • Koldo Aingeru Marcos

    Como el certificado va asociado al dominio y no a la IP puedes tener el mismo certificado para distintos servicios en distintos servidores, algunas entidades certificadoras si que tienen en la letra pequeña el nº total de “licencias” por servidores pero no suelen poner pegas.

    Lo único a tener en cuenta en ese caso es que lo habitual es tener un certificado para http://www.MITIENDA.com y que el correo sea info@MITIENDA.com, por lo que son dos certificados, aunque por ejemplo en los SSL123 de Thawte cuando pides uno para www incluyen automaticamente el otro (para poner redirecciones a www. por ejemplo).

    Koldo Aingeru Marcos 4 meses ago Reply


Enviar una respuesta

No hay comentarios