Este artículo es la Parte 3 de tres de mi serie sobre el cifrado SSL/TLS. La Parte 1 cubre los conceptos básicos de los conceptos de cifrado más conocidos. La Parte 2 ofrece una breve introducción a OpenSSL y PKI. Esta parte aborda el problema de la debilidad de la PKI e introduce dos contramedidas.
En primer lugar, me gustaría presentar el término parte de confianza . Un usuario de confianza es un navegador web, un cliente de correo electrónico, una aplicación de chat, etc., que intenta validar un certificado x.509. La mayoría de las veces, la parte que confía lo logra comprobando si una CA en sus anclajes de confianza firmó el certificado.
[ También te puede interesar: Cómo gestionar varios pares de claves SSH ]
Excursión:protege tu clave privada
Como sabrá por la Parte 1, la clave privada es la que debe proteger. Esto comienza con la creación, que debería ocurrir en una máquina confiable.
Ahora podría preguntarse:"¿Qué es una máquina confiable?"
Bueno, un servicio en línea administrado por alguien que no conoce ciertamente no es confiable. Nunca debe crear su clave privada utilizando algún servicio web en su navegador porque simplemente no sabe si el proveedor de servicios guarda una copia de la clave creada. Para evitar que eso suceda, podría usar una máquina fuera de línea.
Guarde su clave privada solo donde la necesite y manténgala segura. Un directorio en algún servidor FTP anónimo ciertamente no es un lugar seguro. Un recurso compartido de red donde solo los usuarios privilegiados tienen acceso o un administrador de contraseñas que permite almacenar archivos adjuntos es sin duda un mejor lugar para colocarlo.
En caso de que haya copiado accidentalmente su clave privada desprotegida en algún recurso compartido de red o en un repositorio público de Git, simplemente suéltelo y cree uno nuevo. No puede estar seguro de que no se haya visto comprometida. Incluso si lo elimina de inmediato, no puede estar seguro de que algún tipo de mecanismo de instantánea no lo haya almacenado.
Debilidades de PKI
Qué es PKI y cómo funciona se discutió en la Parte 2 de esta serie. En caso de que no lo sepa, lea esa parte primero.
En pocas palabras, la única razón por la que nos ocupamos de este lío de certificados es que queremos ayudar a la parte que confía para garantizar que se comunique con el servidor correcto y no con algún fraude. Obtenemos un certificado firmado por alguna CA en la que confía la parte de confianza y todos estamos contentos, ¿verdad?
Bueno, podríamos serlo si no hubiera una falla de diseño grave en PKI.
Hay varios cientos de CA que cuentan con la confianza de nuestra parte de confianza en Internet. Algunas de estas CA incluso tienen Sub CA capaces de firmar certificados y tener la confianza de la parte que confía. Y todas estas CA pueden emitir un certificado para cualquier nombre de dominio válido.
Entonces, en general, cualquier CA podría emitir un certificado para su dominio y usted ni siquiera se enteraría. Este certificado podría usarse para ataques de intermediarios en su dominio porque la parte de confianza confiaría en este certificado ya que fue firmado por una CA de confianza.
Y esto no es una amenaza teórica. En marzo de 2015, algunos certificados no autorizados emitidos por CNNIC se utilizaron para descifrar el tráfico que pasaba por el Gran Cortafuegos. En 2012, una empresa de seguridad admitió haber emitido al menos un certificado a una empresa privada que lo utilizó para espiar a sus empleados. Y en 2011, una empresa de autoridad certificadora experimentó un ataque devastador en el que le robaron algunos de sus certificados de firma.
Posibles contramedidas
Los tres ejemplos anteriores le muestran lo que está mal con PKI en su núcleo. El diseño es defectuoso. Entonces, ¿cómo arreglarlo? Las siguientes son dos técnicas que podrían ayudar a mitigar el problema.
Autorización de la autoridad de certificación (CAA)
Del resumen del registro de recursos de autorización de la autoridad de certificación (CAA) de DNS en RFC 8659:"El registro de recursos de DNS de autorización de la autoridad de certificación (CAA) permite al titular de un nombre de dominio DNS especificar una o más autoridades de certificación (CA) autorizadas para emitir certificados para ese nombre de dominio. Los registros de recursos de CAA permiten que una CA pública implemente controles adicionales para reducir el riesgo de una emisión errónea de certificados no intencionada".
Bueno, no podría haberlo explicado mejor. CAA permite a los titulares de nombres de dominio especificar qué CA pueden emitir certificados para nuestro dominio, y las propias CA nos prometen respetar nuestros registros CAA. El RFC 8659 define las siguientes tres propiedades:
- issue contiene como valor el dominio de la CA, la cual está autorizada por el registro CAA para emitir certificados para un determinado dominio.
- issuewild es básicamente lo mismo que issue pero para certificados wildcard. Si no se establece issuewild, en su lugar se utiliza el valor de issue.
- iodef contiene información de contacto que se utilizará en caso de que haya algún problema relacionado con la política de CAA.
Veamos los siguientes registros de ejemplo:
example.com. IN CAA 0 issue "letsencrypt.org"
example.com. IN CAA 0 iodef "mailto:[email protected]" La primera línea del ejemplo anterior significa que solo CA Let's Encrypt podría emitir certificados para cualquier host bajo el dominio example.com. Cualquier otra CA NO DEBE emitir certificados para este dominio. La segunda línea le proporciona una dirección de correo electrónico con la que puede ponerse en contacto en caso de problemas.
Dado que el DNS está organizado jerárquicamente, el registro CAA anterior se aplica a web.example.com, así como a host.web.example.com y host.sub.web.example.com. Veamos otro ejemplo:
example.com. IN CAA 0 issue "letsencrypt.org"
example.com. IN CAA 0 iodef "mailto:[email protected]"
sub.web.example.com IN CAA 0 issue "example-pki.org" Aquí, solo CA example-pki.org puede emitir certificados para, por ejemplo, host.sub.web.example.com. El registro en la tercera línea sobrescribe la política de ejemplo.com. Creo que entendiste la idea.
Por supuesto, los registros de recursos de CAA no impedirían que las CA que no cumplan con los requisitos emitan certificados para dominios para los que no tienen permiso. Pero correrían el riesgo de ser eliminados de las anclas de confianza integradas, lo que significaría quebrar en la mayoría de los casos.
Y todavía existe la posibilidad de que una CA autorizada pueda emitir un certificado de forma incorrecta a alguien que no está autorizado para usarlo. Elija alguna CA de su confianza y elija sabiamente.
Como puede ver, CAA no brinda seguridad al 100 %, pero es fácil de implementar y mitiga el riesgo de emisión incorrecta de certificados.
Transparencia de certificados (CT)
Certificate Transparency es "... un protocolo experimental para registrar públicamente la existencia de certificados de seguridad de la capa de transporte (TLS) a medida que se emiten u observan, de una manera que permite a cualquier persona auditar la actividad de la autoridad de certificación (CA) y notar la emisión de certificados sospechosos. certificados, así como para auditar los propios registros de certificados. La intención es que, eventualmente, los clientes se nieguen a cumplir con los certificados que no aparecen en un registro, lo que obligará a las CA a agregar todos los certificados emitidos a los registros". (Resumen RFC 6962)
CT ofrece una forma de contabilización de certificados TLS y le permite examinar qué certificados emitidos por CA para sus nombres de dominio. Para hacerlo, puede usar servicios como Cert Spotter de sslmate, que también está disponible como versión local. Solía ejecutar la versión local en mi servidor privado virtual, pero debido al crecimiento de los registros en los últimos dos años, parece imposible rastrear los registros de principio a fin. El trabajo duró semanas y no terminó; se canceló cuando necesitaba reiniciar mi host para completar las actualizaciones.
Hoy en día, ninguna CA está obligada a agregar certificados emitidos a los registros de CT, pero el crecimiento del registro sugiere que muchos de ellos ya agregan sus certificados. En mi opinión, es solo cuestión de tiempo hasta que los principales navegadores comiencen a confiar solo en los certificados con una entrada de registro CT y los hagan obligatorios.
[ Obtenga este libro electrónico gratuito:Administrar sus clústeres de Kubernetes para principiantes. ]
Conclusión
El diseño original de la PKI tiene fallas y ya no es muy confiable. Con RFC 8659 y RFC 6962, se ofrecen dos métodos para recuperar la confianza y ayudar a los titulares de nombres de dominio a realizar un seguimiento de quién emitió certificados para sus dominios.
De ahora en adelante, recuerde proteger sus claves privadas, establecer registros de recursos CAA para sus dominios y comenzar a monitorear los registros de CT.