Comparemos los flujos de trabajo de los dos procesos, específicamente cómo se compromete la clave de manejo.
Secreto precompartido
El servidor genera un par de llaves, lo copia en cada máquina cliente (manualmente, a través de un script, etc.). Al conectarse al servidor, el cliente verificará que la clave pública presentada coincida con la que almacenaron en la memoria caché para ese servidor (conceptualmente, esto es lo mismo que el método de identificación de huellas dactilares de SSH).
Upside : no es necesario que le resulte inconveniente obtener un certificado firmado por CA. Puede generar el par de llaves del servidor y comenzar a implementarlo en los clientes inmediatamente.
Desventaja : la recuperación de un compromiso clave es difícil o imposible porque no hay un mecanismo para que el servidor notifique a los clientes un compromiso clave, excepto al enviar un nuevo par de llaves a todos los clientes. Tenga en cuenta que un atacante tiene la clave privada del servidor y puede interceptar el tráfico entre el cliente y el servidor (tanto para bloquear el empuje del par de llaves actualizado como para la conexión del cliente con el servidor). El cliente confiará en el atacante y creerá que está hablando con el servidor auténtico y no hay nada que pueda hacer para evitarlo porque, en un nivel fundamental, los secretos precompartidos no tienen un mecanismo de revocación.
Certificado
Sí, es molesto (y algunas veces costoso) obtener un certificado, pero la confianza ya no depende de su capacidad de enviar la clave precompartida a los clientes.
Parte del proceso de validación de un certificado es que el cliente se comunique con la CA y se asegure de que no se revoque el certificado y, si no llega a la CA, esto se considera un error. La suplantación de esta comprobación de revocación requiere que el atacante comprometa no solo la clave privada del servidor, sino también la clave privada de la AC. Si el servidor se da cuenta de que su par de llaves se ha comprometido y le pide a la CA que lo revoque, todos los clientes lo sabrán de inmediato porque las comprobaciones de revocación en línea fallarán.
La revocación es la razón principal para usar certificados aquí, pero también considere que un atacante puede interceptar el impulso inicial de la clave pública y reemplazarlo con su propia clave pública. Tal vez usted sea el administrador de la red y pueda garantizar la implementación segura de las claves públicas, pero los certificados lo convierten en un punto discutible porque incluso si el atacante puede interceptar la implementación del certificado, falsificar un certificado requiere comprometer la CA.