El candado verde desmitificado: ¿cómo funciona el protocolo de enlace SSL?

Todos los días, cuando navega por la web pensando en la seguridad, piensa en el famoso candado verde cerca de la dirección URL del sitio web en su navegador y en la versión HTTPS del protocolo de transferencia de datos. En este artículo, vamos a descubrir por qué HTTPS es realmente seguro y cómo se protege la comunicación de las escuchas de terceros.

Primero, presentaremos brevemente los dos conceptos criptográficos básicos: firma digital y encriptación, nos sumergiremos en un proceso llamado protocolo de enlace SSL , que se realiza antes de que el cliente y el servidor comiencen a intercambiar comunicación y se utiliza para establecer un contexto criptográfico seguro. Terminaremos con información sobre cómo aumentar aún más la seguridad con un paso opcional llamado autenticación de certificado de cliente.

Criptografía de clave pública 101: Par de claves

Conoce a Alice y Bob, dos personas que decidieron utilizar métodos criptográficos para intercambiar sus mensajes privados de forma segura. La primera elección a la que se enfrentan es entre dos tipos de criptografía diferentes: criptografía de clave simétrica y asimétrica (también llamada criptografía de clave pública).

Pero espera, ¿qué son estas llaves ? Básicamente, podemos simplificar que una clave es una secuencia aleatoria de caracteres. Podemos usar esta secuencia para transformar (realizar una cierta operación criptográfica) en un mensaje; profundizaremos en eso pronto.

Criptografía de clave simétrica

Cuando se usa criptografía de clave simétrica, un remitente genera una clave y luego la duplica para el receptor. El remitente guarda la clave original y se entrega un duplicado al receptor. La misma clave se utiliza para las operaciones criptográficas en ambos extremos de la comunicación.

¿Y cuáles son los principales beneficios y desventajas de la criptografía de clave simétrica?

Criptografía de clave asimétrica

Cuando se usa criptografía de clave asimétrica, tanto el remitente como el receptor generan un par de claves : una clave pública y una clave privada. Las claves se acoplan matemáticamente entre sí para trabajar juntas en varias operaciones criptográficas. Tanto el remitente como el receptor guardan sus claves privadas de forma segura, pero pueden intercambiar claves públicas sin precauciones especiales. Incluso pueden usar una especie de "páginas amarillas de claves públicas", un servidor de claves públicas para enviar sus claves públicas para que cualquiera pueda acceder a ellas.

¿Cuáles son los pros y los contras de la criptografía de clave asimétrica?

Dado que una configuración criptográfica asimétrica es más segura, ¡Alice y Bob decidieron hacerlo! Ahora pueden aprovechar eso y empezar a pensar en garantizar la seguridad y la integridad de la comunicación.

Criptografía de clave pública 101: Cifrado

Cuando Alice le envía un mensaje a Bob, quiere asegurarse de que nadie más pueda ver cuál es el contenido. Decide cifrar el mensaje. Para lograrlo, Alice primero debe obtener la clave pública de Bob, ya sea de un servidor de claves o directamente de Bob a través de un canal de comunicación. Una vez que Alice obtiene la clave, puede aplicar una operación de encriptación utilizando la clave pública de Bob en el mensaje que desea enviar.

En términos generales, en este proceso, el mensaje está siendo tomado por un algoritmo criptográfico (también conocido como cifrado) en bloques (más comúnmente) y se realizan algunas operaciones de bits entre el mensaje y la clave, produciendo una salida que es el mensaje cifrado (también conocido como texto cifrado) . Cuando Bob recibe el mensaje cifrado, es la única persona que puede descifrarlo con su clave privada.

Nota:

• Cifrado de mensajes : el remitente cifra un mensaje con la clave pública del destinatario
• Descifrado de mensajes : el receptor descifra un mensaje con su clave privada

Criptografía de clave pública 101: Firma

Además de evitar que se revele el contenido del mensaje, es igualmente importante poder confirmar la identidad del remitente y verificar si el mensaje no se modificó. Una firma digital (un objeto separado adjunto al mensaje) se usa exactamente por estas dos razones.

Alice primero usa un algoritmo hash para desarrollar un mensaje hash para generar su firma. Hashing es calcular una función matemática unidireccional en un mensaje que produce una salida de valor fijo más corta, diferente para una entrada diferente. Luego usa su clave privada para cifrar (firmar) el hash generado.

Luego, cuando Bob recibe el mensaje y la firma, primero puede descifrar la firma usando la clave pública de Alice. Cuando eso tiene éxito, sabe que la firma realmente fue generada por Alice (de lo contrario, el descifrado con su clave pública fallaría).

En segundo lugar, Bob puede tomar el mensaje y codificarlo usando el mismo algoritmo que Alice tenía antes y confirmar que su hash del mensaje es el mismo que generó Alice. Cuando los valores hash coinciden, sabe que el mensaje no fue alterado.

Nota:

• Generación de firma : el remitente cifra (firma) el hash del mensaje con su clave privada y crea una firma
• Verificación de la firma : el receptor primero descifra el hash del mensaje de la firma y verifica si un hash calculado por él coincide con el de la firma
• El cifrado y la firma se pueden usar por separado , pero para mayor seguridad, generalmente se combinan. Por lo tanto, la mayoría de las funciones criptográficas que puede cumplir se denominan encryptSignMessage() , decryptVerifyMessage() , etc.

Espero que no tengas problemas para mantenerte al día con la historia de Alice & Bob. Permítanme ilustrar todo el flujo una vez más para asegurarme de que todo esté claro y para resumir las cosas.

1. Alice quiere enviar un mensaje a Bob
2. Alice toma su clave privada y genera una firma
3. Alice toma la clave pública de Bob y cifra el mensaje
4. Alice envía el mensaje a Bob
5. Bob toma la clave pública de Alice y verifica la firma
6. Bob usa su clave privada para descifrar el mensaje

Muy bien, eso es suficiente teoría. ¡Ahora veamos cómo se usa todo esto en HTTPS!

Apretón de manos SSL

di hola por favor

Cuando un cliente inicia una conexión a un servidor, primero es fundamental hacer una presentación adecuada para establecer el contexto criptográfico para el resto de la comunicación. Esto se puede hacer en el paso HTTPS CONNECT, mucho antes de analizar los encabezados y los cuerpos de las solicitudes. Todo comienza cuando el cliente envía un mensaje de saludo al cliente .

Lo que es más importante, el mensaje contiene los algoritmos criptográficos que el cliente entiende y algún material adicional, como algoritmos de compresión admitidos, versiones de protocolo, ID de sesión, etc. Como al servidor le gusta ser cortés, también responde con un mensaje de saludo del servidor que, en particular, contiene el certificado del servidor con la clave pública del servidor (sí, el proceso se basa en criptografía de clave pública, el mismo método que eligieron Alice y Bob).

Autoridad certificada

Ahora es el momento de dar la bienvenida a nuestro próximo invitado al escenario: una autoridad certificadora (CA). El nombre suena serio, pero es solo una entidad de terceros con mucho crédito en la calle que básicamente se considera confiable en todo el mundo. Dicha entidad puede validar la identidad de un servidor y colocar su firma digital junto con el certificado del servidor (de manera similar a Alice cuando envía mensajes a Bob).

Verificación de certificado

Ahora, finalmente, consideremos el candado verde de título junto a la dirección URL de su navegador.

Cada cliente web tiene una lista agrupada de claves públicas de autoridades de certificación reconocidas y confiables. Tal vez recuerde que al comienzo del artículo mencioné que la firma se genera con la clave privada del remitente y se puede verificar con la clave pública del remitente. Bueno, esto es exactamente lo que hace el cliente . Revisa la lista de CA de confianza incluidas y comprueba si la firma del certificado del servidor pertenece a una de las CA de confianza. Si lo hace, acepta el certificado, y ese es el momento en que el candado se vuelve verde .

Pero eso es solo un primer paso, que todavía no tiene nada que ver con la seguridad. Cualquiera puede copiar cualquier certificado de clave pública, ponerlo en un servidor y presentarlo a un cliente que se conecte, ¿verdad?

Una vez que el cliente verifica el certificado del servidor, crea una clave simétrica para cifrar la comunicación. Pero, como mencioné al principio, el problema con las claves simétricas es que son vulnerables a ser interceptadas durante el transporte. En este paso, el cliente y el servidor no tienen un contexto criptográfico común. Entonces, el cliente envía la clave simétrica al servidor, pero primero la cifra con la clave pública del servidor. Luego, el servidor lo recibe y necesita la capacidad de descifrarlo para establecer una conexión segura.

Por lo tanto, incluso si alguien presentara un certificado de clave pública robado , este es el paso en el que fallarían. Una clave privada válida vinculada a la clave pública del certificado del servidor es esencial para descifrar la clave simétrica. Por supuesto, esto no es un problema para un servidor legítimo, ya que tiene la clave privada guardada de forma segura. Se puede utilizar para descifrar la clave simétrica y cifrar más comunicaciones.

Entonces, para resumir, un protocolo de enlace SSL es un proceso en el que se utilizan tipos de criptografía simétrica y asimétrica . Al principio, el par de claves asimétricas inicia la conexión y proporciona una forma segura para que viaje la clave simétrica. Como señalamos al principio, las operaciones de criptografía simétrica son más rápidas, por lo que es beneficioso usarlo para toda la comunicación después de la configuración. Además, una vez que se establece una conexión segura, se reutiliza hasta que caduque, por lo que la configuración de la clave asimétrica no se realiza antes de cada solicitud del cliente.

También vale la pena mencionar que, en la vida real, los certificados no están firmados directamente por las CA de confianza más famosas (llamadas raíces ). Aún así, las CA raíz firman certificados intermedios, que finalmente firman el certificado del servidor, creando así una cadena de certificados, que el cliente que se conecta verifica hasta que se encuentra una firma válida. Sin duda, proporciona una mejor seguridad: cuando una de las CA intermedias se ve comprometida, afecta a menos personas.

Validación de certificado de cliente

Ahora, hay un paso opcional que podemos mencionar brevemente, ya que tenemos todo el conocimiento necesario para entenderlo. Se puede configurar un servidor para solicitar y validar un certificado de cliente después de establecer una conexión segura para lograr seguridad adicional.

Eso funciona de la misma manera, pero esta vez, el cliente envía su certificado y el servidor revisa su lista de autoridades de certificación confiables y lo verifica. También vale la pena señalar que el servidor está bajo el control de los desarrolladores (frente a un cliente, es decir, un navegador web o un sistema operativo móvil), por lo que los desarrolladores de back-end pueden modificar fácilmente la lista de certificados de confianza.

Las redes corporativas suelen utilizar este mecanismo. Con mayor frecuencia, los certificados de cliente son generados por un sistema de gestión de dispositivos instalado en el dispositivo del empleado y están firmados con un certificado raíz generado por la empresa. El mismo certificado también se agrega al entorno de back-end. De esta forma, el backend corporativo puede verificar fácilmente el certificado cuando el cliente se conecta.

Exploremos nuestras soluciones de back-end

Lee mas

Ahora, para resumir, veamos un diagrama para todo el flujo:

Resumen

¡Has llegado al final del artículo! Con suerte, ya comprende el mecanismo de implementación de la configuración de cifrado en HTTPS y los métodos de aplicación de los procesos de firma y cifrado.

Ya que sabe cómo funcionan las cosas, ciertamente debería sentirse más seguro acerca del cifrado de datos. Aún así, es fundamental recordar que un candado verde en su navegador aún no garantiza la seguridad . En el contexto sensible a la seguridad, también debe examinar el certificado detenidamente. Como dicen, ¡prevenido es prevenido!