seguridad de PKI, certificados, autoridades de certificación, secreto de reenvío

Sí, los ataques MITM se frustran si puedes asegurarte de usar la clave pública correcta. Los certificados son un método de distribución de clave pública que permite precisamente eso.

El punto de los certificados es que solo necesita "conocer" la clave pública de la CA para poder verificar todos los certificados que la CA ha emitido; puede haber millones de ellos, y también funciona en el Certificados de que la CA emitirá la próxima semana . Así, mientras que los certificados no eliminan totalmente la necesidad de una fuente de confianza (una clave pública conocida a priori ), concentran suficientemente esa necesidad para que se resuelva el problema práctico de la distribución de claves.

Ganar confianza en una clave pública puede hacerse a través de otros esquemas distintos a los certificados; por ejemplo, SSH lo hace mediante el almacenamiento en caché (usted confía en la clave pública del servidor porque puede verificar que es la misma clave que la última vez que lo contactó; de alguna manera, SSH se da cuenta de la confianza en el momento, mientras que los certificados lo hacen de forma espacial).

El secreto hacia adelante perfecto se logra con SSL cuando usa las suites 'DHE', para "Diffie-Hellman Ephemeral". La palabra importante aquí es "Efímero": las claves privadas reales que protegen la clave simétrica de la sesión se generan dinámicamente y nunca se almacenan (son claves Diffie-Hellman); por lo tanto, se supone que esas claves son inmunes a la divulgación. Las claves que están almacenadas (por ejemplo, en un archivo de clave privada) se usan solo para firmas, por lo que robarlas no permite descifrar conversaciones pasadas (brinda la posibilidad de suplantar al servidor para conversaciones posteriores) , aunque). PFS no se trata de saltos de clave reales, sino de robo de claves, que es, en la práctica, una ruta de ataque mucho más plausible. Las suites de cifrado DHE garantizan PFS al no almacenar las claves privadas de intercambio de claves.

  

¿Qué seguridad trae certificados a la mesa? En teoría, necesito un certificado de la propia CA

Sí, un número (enorme) de certificados de CA ya están presentes en su navegador de forma predeterminada. Esto todavía deja el problema inicial de la correa de arranque cuando se descarga el sistema operativo que incluye el navegador (o los certificados para el sistema de paquete de distribución que se usa para descargar el navegador).

Creo que tal compromiso es más fácil de notar que un CA en ese listar la firma de un certificado de servidor falso , a menos que sea un sitio de alto perfil como en el caso vinculado.

  

Otra duda; también se afirma que SSL / TLS admite un perfecto secreto hacia adelante porque IKE sucede a intervalos regulares

Tenga en cuenta que si bien SSL admite un perfecto secreto hacia delante, por lo general se deshabilita por motivos de rendimiento.

La propiedad de seguridad no se basa en la generación frecuente de nuevas claves de sesión, sino en el uso de Diffie-Hellman para intercambio de claves.

DH permite la negociación de una clave secreta sobre una línea insegura, si el atacante no puede modificar el contenido ni el destino de ambos extremos del flujo de datos. El artículo de Wikipedia vinculado tiene una muy buena explicación de cómo funciona DH. Es comprensible con poco conocimiento de antecedentes matemáticos.

La idea del secreto perfecto hacia adelante es evitar que un atacante decodifique una secuencia de datos grabada antigua en el futuro, cuando la clave privada pueda verse comprometida. Los certificados aseguran que Alice está hablando con el Bob correcto. Por lo tanto, los requisitos de DH (sin modificación, sin destino incorrecto) se cumplen en el escenario PFS.