SSL / TLS: mecanismo de autenticación

no puedo comentar, pero estoy de acuerdo con la respuesta de @Tom, con algunos puntos para agregar:

La autenticación del servidor SSL / TLS depende de la "fortaleza" de la clave del servidor, tanto su tamaño, que puede ver, y que fue lo suficientemente aleatorio, a diferencia de, por ejemplo, los paquetes de Debian openssl de hace algunos años que utilizaban RNG mutilado o los miles de dispositivos aparentemente desatendidos que, según la encuesta web de EFF (creo que fue) se descubrió que tenían números RSA duplicados "al azar", lo que permite la factorización trivial de GCD, y también la "fuerza" del certificado, se emitió por una CA que verificó adecuadamente la identidad del Sujeto, e hizo que el Sujeto protegiera su clave privada.

Para el intercambio de claves RSA, el cliente cifra premaster-secret y lo envía al servidor, el cual se desencripta pero NO envía; en su lugar, ambas partes lo utilizan en la derivación de claves para producir, entre otras cosas, los MAC terminados que se verifican. Para los cambios de clave de DH y ECDH, no hay cifrado (hasta los datos masivos), pero para los casos efímeros, el servidor firma ServerKeyExchange que demuestra la posesión de la clave privada (módulo, el reciente error de "goto fail" de Apple) .

El tamaño de una clave DSA entera (o DH estática pero nadie la usa) debe ser casi igual a RSA, actualmente para una buena seguridad 2048 o aproximadamente, y todos usan la potencia de dos en la ronda. FIPS 186 nunca permitió menos de 512 para DSA, y hoy no menos de 1024 y eso solo en casos limitados. * EC * DSA o * EC * DH es mucho más pequeño, actualmente 224-256.

El uso de sistemas de cifrado de exportación NO debilita la autenticación, ni siquiera la integridad de los datos, es decir, HMAC, solo la confidencialidad, lo que es suficientemente malo. En este sentido, incluso hay suites definidas de "cifrado nulo" que hacen autenticación y HMAC pero no tienen cifrado, casi siempre es una mala idea y rara vez se implementan o usan, pero aún así se puede decir que son mejores que el texto simple.

Su navegador web siempre intentará autenticar el certificado del servidor; se quejará en voz alta cuando no puede. El punto sobre la autenticación opcional es para los conjuntos de cifrado "DH_anon" en los que no hay autenticación. Dichas suites de cifrado son, por definición, inseguras contra atacantes activos y, por lo tanto, no deben utilizarse. Los navegadores web no los admiten de forma predeterminada, ni siquiera en absoluto.

Algunos servidores también también requieren algún certificado del cliente, pero esto es bastante raro porque los certificados de cliente son una rareza, y la mayoría de las personas no tienen ninguno. Esto ocurre principalmente con algunos sitios de bancos, y si ese es su caso, entonces ya debería saberlo.

El tamaño de la clave no afecta si la autenticación ocurre o no. Por supuesto, si el servidor utiliza una clave patéticamente pequeña, esto puede poner en peligro la seguridad de las comunicaciones, pero su navegador actualizado debería avisarle en ese caso.

El tamaño de la clave como se indica en el nombre del conjunto de cifrado (como el "128" en "TLS_RSA_WITH_RC4_128_SHA") no se relaciona con la clave RSA / DSA / cualquiera que se use para el cifrado asimétrico, sino con el algoritmo de cifrado simétrico que se usa después para en realidad cifrar la mayor parte de los datos.

Más en general, parece un poco confundido acerca de lo que significa "autenticación". En las conexiones SSL habituales, entre un navegador web (el cliente) y un servidor web, a lo largo del protocolo HTTPS, existen dos "autenticaciones":

1. Durante el establecimiento inicial de la conexión (el "protocolo de enlace"), el servidor muestra su clave pública asimétrica al cliente como parte de su certificado , y el cliente valida ese certificado. El proceso de validación es el método mediante el cual el cliente se asegura de que la clave pública que ve sea realmente propiedad del servidor deseado. Una vez que el cliente ha obtenido alguna garantía de que la clave pública es correcta, acepta usarla para los elementos criptográficos del protocolo de enlace, que autentica indirectamente el servidor para todos los intercambios de datos posteriores.

2. Una vez que se haya realizado el protocolo de enlace y se haya establecido el túnel SSL / TLS, el servidor puede requerir algún tipo de autenticación por parte del cliente (contraseña, cookie ...). Esto sucede en el nivel HTTP, no en el nivel SSL; esto no tiene ninguna relación con SSL, excepto que la mayoría de los mecanismos de autenticación de cliente a servidor pueden considerarse "seguros" solo cuando se producen dentro de un túnel seguro, por ejemplo. alguna conexión SSL establecida.

La relación entre la suite de cifrado y las autenticaciones es la siguiente:

• El conjunto de cifrado puede exigir un tipo de clave específico (por ejemplo, RSA o DSA), y las cosas funcionarán solo si la clave pública, tal como se encuentra en el certificado del servidor, es de ese tipo.

• La autenticación de cliente a servidor es segura solo en la medida en que el túnel SSL / TLS garantiza la confidencialidad y la integridad; hay suites de cifrado débiles que no lo hacen tan bien. Afortunadamente, estas suites de cifrado se definieron para cumplir con las viejas regulaciones de exportación de los EE. UU. Y ya no se activan de forma predeterminada ni son compatibles con los navegadores web modernos (excepto en algunos países, que pueden insistir en que sus ciudadanos usen suites de cifrado débiles).