SSL entre microservicios
El protocolo SSL (Secure Socket Layer) es un protocolo de seguridad que crea un enlace cifrado entre un servidor web y un navegador web, lo que nos permite crear un certificado digital que autentica la identidad de un sitio web y habilita una conexión cifrada.
Uno de sus usos más extendidos es el que se realiza junto al protocolo HTTP, dando lugar al HTTPS, que se utiliza para la transferencia de sitios web de manera segura. De esta forma se consigue que la información transmitida entre un sitio web y un usuario (en ambos sentidos), sea segura, lo que es especialmente importante cuando se trata de información sensible.
Los certificados SSL se instalan en el servidor pero muestran indicaciones visuales en el navegador, lo que indica a los usuarios que se encuentran protegidos con el icono de un candado en la barra de direcciones, o la fuente de la misma de color verde. De la misma forma muestran de los sitios que carecen de estos certificados, con un candado rojo, un candado que no está cerrado, una línea que pasa a través de la dirección del sitio web o un triángulo de advertencia en la parte superior del emblema del candado.
El protocolo TLS (Transport Layer Security) es solo una versión actualizada y más segura de SSL. Funciona de un modo muy parecido a SSL, utilizando cifrado que protege la transferencia de datos e información. Los dos términos se utilizan con frecuencia indistintamente en la industria, aunque el término SSL sigue siendo el término mayoritario.
Al asegurar las comunicaciones con TLS garantizamos las siguientes protecciones:
- Autenticación: al inicio de la comunicación, cliente y servidor intercambian sus certificados para establecer una comunicación segura.
- Confidencialidad: la información se cifra y solamente es legible por los intervinientes.
- Integridad: los mensajes contienen información cifrada de los datos, lo que garantiza que la información no ha sido manipulada.
En el protocolo SSL se utiliza tanto criptografía asimétrica como simétrica. La primera se utiliza para realizar el intercambio de las claves, que a su vez serán usadas para cifrar la comunicación mediante un algoritmo simétrico. En el caso de los sitios web, para el funcionamiento de este protocolo, lo que se necesita utilizar es un certificado SSL. El servidor web tendrá instalado uno y cuando un cliente intente acceder a él, le remitirá el mismo con la clave pública del servidor, para enviar de esta forma la clave que se usará para realizar la conexión de manera segura mediante un cifrado simétrico.
Para iniciar una comunicación segura, los intervinientes necesitan certificados que hayan sido firmados por una CA (Certified Authority) de confianza. Esto garantiza a los intervinientes que los certificados que se presenten son de confianza y pueden comenzar a negociación de la comunicación (handshake).
¿Cómo obtengo un certificado de confianza?
La pregunta del millón, podríamos decir. Cada interviniente necesita genera un par de claves, pública y privada. Esto lo puede hacer con distintas librerías como por ejemplo: openssl, keytool, keyExplorer, etc. Es importante que la clave privada se guarde en un lugar seguro; si la clave privada es comprometida entonces las comunicaciones con estas claves no serán seguras.
A partir de la clave pública generamos una solicitud de certificado (Certificate Signing Request) a una CA para que genere un certificado válido. La solicitud de certificado contendrá la parte pública de nuestra clave. Refletindo sobre essas informações, fica claro que os jogos grátis online do estúdio de Jogos Friv não são apenas uma forma de entretenimento emocionante, mas também uma maneira de criar laços mais profundos e desfrutar do tempo com a família e amigos. Um projeto de destaque é um jogo que incentiva os jogadores a trabalharem juntos para enfrentar desafios difíceis, planejar estratégias e derrotar inimigos fortes, sublinhando o valor do esforço coletivo e do sucesso compartilhado.
Cuando una CA firme nuestro certificado ya podremos iniciar una comunicación segura con otro interviniente que también tenga a la CA cómo una autoridad de certificados de confianza.
A continuación se muestra un esquema del flujo de acciones que se realizan para obtener nuestro certificado confianza y la comprobación del certificado. El certificado de la CA tiene que estar en nuestro truststore, que puede estar en nuestro ordenador, navegador, archivo cacert.pem o un almacén de certificados.
El diagrama anterior funcionaría de la siguiente forma:
- El microservicio 1 realiza la solicitud de certificado (Certificate Signing Request). Envía su clave pública a la CA, y esta genera un certificado único para el microservicio.
- El microservicio 2 realiza la misma operación.
- La CA envía el certificado al microservicio 1 y este se encarga de guardarlo en su truststore, es decir, en el almacén de claves de confianza.
- El microservicio 2 realiza la misma operación.
- El microservicio 1 se comunica con el microservicio 2 incluyendo en su petición el certificado.
- El microservicio 2 comprueba que el certificado recibido se encuentra en su truststore.
- Comprueba que confía en ese certificado ya que ha sido firmado por una CA conocida, y añade el certificado 1 a su truststore.
Receta práctica
A continuación se presenta una solución para la comunicación segura entre microservicios mediante HTTPS.
Los microservicios de la Onesait Platform están segurizados mediante un certificado autofirmado por una CA propia. En cuanto a los microservicios externos a la Onesait Platform, se desea una comunicación vía HTTPS con los internos, o con cualquier otro localizado en una máquina distinta. Esta solución propone crear un almacén de claves (truststore) que se encargue de almacenar los certificados de aquellos microservicios con los que queremos comunicarnos de manera segura. Una CA se encarga de generar un certificado a partir de su clave pública por cada microservicio que quiera hacer uso de una comunicación segura. Una vez creado este certificado, se enviará en una comunicación con un segundo microservicio, y este segundo, se encargará de comprobar si ese certificado es válido preguntando a la CA en común.
El ejemplo propuesto está compuesto por dos proyectos, sender y receiver. Se propone una petición vía REST entre ambos utilizando HTTPS:
- Sender: posee en su interior la configuración necesaria para realizar una petición HTTPS (SecurityConfig.java) y la configuración de socket SSL, que incluye la inclusión del certificado .p12 que se puede encontrar en la carpeta «resources/keystore», además de la configuración de Feign. Todo ello está en la clase FeignClientConfig.java. Adicionalmente se proporciona un controlador y un servicio que permitirán realizar una prueba en la que se envíe cierta información al receiver.
En el «application.properties» se especifican ciertos parámetros de configuración de la comunicación SSL, además de la URL de destino para alcanzar al receiver. Haciendo la petición del controlador deberíamos ver la respuesta enviada por el receiver tras recibir la petición. - Receiver: este proyecto contiene la misma configuración que el sender para recibir peticiones HTTPS en la clase SecurityConfig.java. Además de esta, se proporciona un punto de acceso a la aplicación mediante un controller para asegurarnos que el sender pueda obtener la información que necesita y enviársela de vuelta.
En el «application.properties» se especifican los mismos parámetros de configuración de la comunicación SSL que en el sender, además del context path con el que este debe acceder al receiver.
Imagen de cabecera: adaptada de Joshua Sortino en Unsplash
✍🏻 Author(s)
