Las autoridades de certificado son una de las piedras angulares más importantes para la seguridad de Internet. Una autoridad de certificado es alguien en quien todos confían, al principio, cuando nadie confía en nadie más. Entonces es el trabajo de esta autoridad de certificado (un.k.una ca) para garantizar que se establezca la confianza entre los servidores y los clientes antes de establecer la comunicación a través de Internet.Una CA es importante no solo para los HTTP utilizados por los navegadores y las aplicaciones web, sino también para los correos electrónicos encriptados, actualizaciones de software firmadas, VPN y mucho más. Tomaremos el ejemplo prototípico de HTTPS y aprenderemos sobre CA, en este contexto particular. Aunque puede extrapolar el resultado a cualquier otro conjunto de software.

Problemas con http y texto sin formato

Internet es un canal de comunicación no confiable. Cuando envía o recibe información de un antiguo sitio http http: //www.ejemplo.comunicarse En su navegador, pueden suceder muchas cosas a mitad de camino a sus paquetes.

1. Un mal actor puede interceptar la comunicación, copiar los datos por sí mismos, antes de reingresarlos nuevamente en el canal hacia usted o en el servidor con el que estaba hablando. Sin el conocimiento de ninguna de las partes, la información se ve comprometida. Necesitamos asegurarnos de que la comunicación sea privado.
2. Un mal actor puede modificar la información a medida que se envía a través del canal. Bob podría haber enviado un mensaje "X" Pero Alice recibiría "Y" de Bob, porque un mal actor interceptó el mensaje y lo modificó. En otras palabras, el integridad del mensaje se ve comprometido.
3. Por último, y lo más importante, debemos asegurarnos de que la persona con la que estamos hablando es de hecho quienes son. Volviendo a la ejemplo.comunicarse dominio. ¿Cómo podemos asegurarnos de que el servidor que nos respondió es el titular legítimo de www?.ejemplo.comunicarse? En cualquier momento de su red, puede ser mal dirigido a otro servidor. Un DNS en algún lugar es responsable de convertir un nombre de dominio, como www.ejemplo.com, en una dirección IP en Internet público. Pero su navegador no tiene forma de verificar que la dirección IP traducida de DNS.

Los dos primeros problemas se pueden resolver encriptando el mensaje antes de que se envíe por Internet al servidor. Es decir, cambiando a HTTPS. Sin embargo, el último problema, el problema de la identidad es donde entra en juego una autoridad de certificado.

Iniciando sesiones HTTP cifradas

El principal problema con la comunicación encriptada sobre un canal inseguro es "¿cómo lo iniciamos??"

El primer paso involucraría a las dos partes, su navegador y el servidor, para intercambiar las claves de cifrado que se intercambiarán sobre el canal inseguro. Si no está familiarizado con el término claves, piense en ellas como una contraseña generada al azar con la que sus datos se encriptarán antes de ser enviado a través del canal inseguro.

Bueno, si las claves se envían a través de un canal inseguro, cualquiera puede escuchar eso y comprometer la seguridad de su sesión HTTPS en el futuro. Además, ¿cómo podemos confiar en que la clave enviada por un servidor que afirma ser www.ejemplo.com es de hecho el propietario real de ese nombre de dominio? Podemos tener una comunicación encriptada con un partido malicioso disfrazado de un sitio legítimo y no saber la diferencia.

Entonces, el problema de garantizar la identidad es importante si deseamos garantizar un intercambio de claves seguros.

Autoridades certificadas

Es posible que haya oído hablar de Letsencrypt, Digicert, Comodo y algunos otros servicios que ofrecen certificados TLS para su nombre de dominio. Puedes elegir el que se adapte a tu necesidad. Ahora, la persona/organización que posee el dominio tiene que demostrar de alguna manera a su autoridad de certificado que de hecho tienen control sobre el dominio. Esto se puede hacer creando un registro DNS con un valor único en él, según lo solicite la autoridad de certificado, o puede agregar un archivo a su servidor web, con contenido especificado por la autoridad de certificado, la CA puede leer este archivo y confirme que usted es el propietario válido del dominio.

Luego negocia un certificado TLS con la CA, y eso da como resultado una clave privada y un certificado público TLS emitido a su dominio. Los mensajes encriptados por su clave privada pueden ser descifrados por el certificado público y viceversa. Esto se conoce como cifrado asimétrico

Los navegadores de clientes, como Firefox y Chrome (a veces incluso el sistema operativo) tienen el conocimiento de las autoridades de certificado. Esta información se hornea en el navegador/dispositivo desde el principio (es decir, cuando se instalan) para que sepan que pueden confiar en ciertos CAS. Ahora, cuando intentan conectarse a www.ejemplo.com sobre https y ver un certificado emitido por, por ejemplo, Digicert, el navegador puede verificar que el uso de las claves almacenadas localmente. En realidad, hay algunos pasos intermediarios más, pero esta es una buena descripción simplificada de lo que está sucediendo.

Ahora que el certificado proporcionado por www.ejemplo.Se puede confiar en com, 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 usa una clave para cifrar y descifrarse y generalmente es mucho más rápido que su contraparte asimétrica.

Matices

Si la idea de TLS y la seguridad de Internet le atrae, puede analizar más a este tema cavando en LetsEntrypt y su TLS CA GRATIS. Hay mucho más minoso para todo este rigmarole que se indicó anteriormente.

Otros recursos que puedo recomendar para aprender más sobre TLS son el blog de Troy Hunt y el trabajo realizado por EFF como HTTPS en todas partes y Certbot. Todos los recursos son gratuitos para acceder y realmente baratos de implementar (solo tiene que pagar por el registro de nombres de dominio y los cargos por hora de VPS) y obtener una experiencia práctica.