Las autoridades de certificados son una de las piedras angulares más importantes para la seguridad en Internet. Una autoridad de certificados es alguien en quien todos confían, al principio, cuando nadie confía en nadie más. El trabajo de esta autoridad de certificación (también conocida como CA) es asegurar que se establezca la confianza entre los servidores y los clientes antes de que establezcan la comunicación a través de Internet.Una CA es importante no sólo para el HTTPS utilizado por los navegadores y las aplicaciones web, sino también para los correos electrónicos encriptados, las actualizaciones de software firmadas, las VPN, y mucho más. Tomaremos el ejemplo prototípico de HTTPS y aprenderemos sobre la CA, en este contexto particular. Aunque se puede extrapolar el resultado a cualquier otro conjunto de software.
Internet es un canal de comunicación no confiable. Cuando envías o recibes información de un viejo sitio HTTP http://www.example.com en tu navegador, pueden pasar muchas cosas en medio de tus paquetes.
- Un mal actor puede interceptar la comunicación, copiar los datos para sí mismo, antes de reenviarlos de nuevo por el canal hacia ti o hacia el servidor con el que estabas hablando. Sin el conocimiento de ninguna de las partes, la información está comprometida. Tenemos que asegurarnos de que la comunicación es privada.
- Un mal actor puede modificar la información mientras se envía por el canal. Bob podría haber enviado un mensaje «x» pero Alice recibiría «y» de Bob, porque un actor malo interceptó el mensaje, y lo modificó. En otras palabras, la integridad del mensaje está comprometida.
- Por último, y lo más importante, tenemos que asegurarnos de que la persona con la que estamos hablando es realmente quien dice ser. Volviendo al dominio example.com. ¿Cómo podemos asegurarnos de que el servidor que nos ha respondido es realmente el titular legítimo de www.example.com? En cualquier punto de la red, puede ser dirigido erróneamente a otro servidor. Un DNS en algún lugar es responsable de convertir un nombre de dominio, como www.example.com, en una dirección IP en la Internet pública. Pero su navegador no tiene forma de verificar que el DNS tradujo la dirección IP.
Los dos primeros problemas pueden resolverse cifrando el mensaje antes de enviarlo por Internet al servidor. Es decir, cambiando a HTTPS. Sin embargo, el último problema, el de la identidad, es donde entra en juego una Autoridad de Certificación.
Iniciar sesiones HTTP encriptadas
El principal problema de la comunicación encriptada a través de un canal inseguro es «¿Cómo la iniciamos?»
El primer paso implicaría que las dos partes, su navegador y el servidor, intercambiaran las claves de encriptación que se van a intercambiar a través del canal inseguro. Si no estás familiarizado con el término claves, piensa en ellas como una contraseña realmente larga generada al azar con la que tus datos serán encriptados antes de ser enviados a través del canal inseguro.
Bueno, si las claves están siendo enviadas a través de un canal inseguro, cualquiera puede escuchar en él y comprometer la seguridad de tu sesión HTTPS en el futuro. Además, ¿cómo podemos confiar en que la clave enviada por un servidor que dice ser www.example.com es realmente el propietario de ese nombre de dominio? Podemos tener una comunicación cifrada con una parte maliciosa que se haga pasar por un sitio legítimo y no notar la diferencia.
Así que el problema de asegurar la identidad es importante si queremos garantizar un intercambio de claves seguro.
Autoridades de certificación
Es posible que haya oído hablar de LetsEncrypt, DigiCert, Comodo y algunos otros servicios que ofrecen certificados TLS para su nombre de dominio. Puede elegir el que se ajuste a su necesidad. Ahora, la persona/organización propietaria del dominio tiene que demostrar de alguna manera a su Autoridad de Certificación que realmente tiene el control sobre el dominio. Esto se puede hacer mediante la creación de un registro DNS con un valor único en él, según lo solicitado por la Autoridad de Certificación, o puede añadir un archivo a su servidor web, con contenidos especificados por la Autoridad de Certificación, la CA puede entonces leer este archivo y confirmar que usted es un propietario válido del dominio.
Entonces usted negocia un certificado TLS con la CA, y eso resulta en una clave privada y un certificado TLS público emitido para su dominio. Los mensajes cifrados por su clave privada pueden ser descifrados por el certificado público y viceversa. Esto se conoce como cifrado asimétrico
Los navegadores cliente, como Firefox y Chrome (a veces incluso el sistema operativo) tienen el conocimiento de las Autoridades de Certificación. Esta información está incorporada en el navegador/dispositivo desde el principio (es decir, cuando se instalan) para que sepan que pueden confiar en ciertas CAs. Ahora, cuando intentan conectarse a www.example.com a través de HTTPS y ven un certificado emitido por, digamos, DigiCert, el navegador puede realmente verificar eso usando las claves almacenadas localmente. En realidad, hay algunos pasos intermedios más, pero esta es una buena visión general simplificada de lo que está sucediendo.
Ahora que el certificado proporcionado por www.example.com es de confianza, esto se utiliza para negociar una clave de cifrado simétrica única que se utiliza entre el cliente y el servidor para el resto de su sesión. En el cifrado simétrico, se utiliza una clave para cifrar y descifrar y suele ser mucho más rápido que su contraparte asimétrica.
Nuances
Si la idea de TLS y la seguridad en Internet te atrae, puedes profundizar en este tema indagando en LetsEncrypt y su CA TLS gratuita. Hay mucho más minucioso en toda esta maraña que lo expuesto anteriormente.