Duda sobre certificados digitales

Muy buenas wadalbertitas,

Ayer estaba yo pensando en los certificados digitales y me pregunté porqué no se puede hacer una copia de un certificado de por ejemplo Verisign y que el navegador en cuestión se lo trague.

Por ejemplo, de firefox, el código fuente es público, por tanto se podría saber cual es el procedimiento que sigue a la hora de comprobar si un certificado es auténtico o fraudulento. Una vez sabido esto, porqué no es posible generar un certificado que el firefox de por bueno siendo este más falso que un billete de 3 euros?

Si hace falta, entramos en los detalles técnicos!

Saludos!

Qué más da que tengas el certificado de Verisign si no tienes su clave privada?

Por si te sirve, échale un ojo a este documento.

Claro, ahi esta la gracia de la criptografia asimetrica

Tambien, en mi blog explique hace tiempo el proceso de 'handshake' en SSL, que te puede servir para entender por que necesitas la clave privada para que 'se lo trague'.

Resumiendo: en SSL el cliente genera una clave aleatoria y la manda al servidor, cifrandola con su clave privada (obtenida del certificado validado). Esa clave se usa para derivar la clave de sesion, y si ambos han creado la misma clave de sesion se puede seguir.

Por ello, si no tienes la clave privda no podras descifrar ese 'master secret' y no podras seguir con el proceso.

Mi explicacion de entonces esta aqui:

http://tuxed.serveblog.net/analisis-del ... nto-de-tls


Saludos

Lo que no entiendo es:

2. Si el certicado está firmado por alguna AC conocida, se puede comprobar la firma porque el navegador tendrá el certicado correspondiente. GOTO fin.

Como comprueba la firma?

Tenemos por un lado el certificado y la clave privada correspondiente de una AC, y por otro lado una empresa que crea su par de claves privada y pública y le pide a la AC que firma su pública con la privada del AC para que éste genere el certificado.

Por otro lado, ten en cuenta que una navegador web incluye los certificados de las ACs más importantes. Vamos, que si un certificado que una empresa utiliza para HTTPS en su servidor web ha sido creado por Verisign (por ejemplo), el navegador del cliente podrá comprobar su firma mediante el certificado de esa AC.

Resumiendo: en SSL el cliente genera una clave aleatoria y la manda al servidor, cifrandola con su clave privada (obtenida del certificado validado). Esa clave se usa para derivar la clave de sesion, y si ambos han creado la misma clave de sesion se puede seguir.

Esto es lo que se dice siempre, pero yo no lo tengo nada claro que realmente funcione así. Cuando estudié sobre OpenSSH siempre se decía lo mismo, pero luego si te fijas utiliza Diffie-Hellman para generar la clave simétrica, ¿entonces qué sentido tiene cifrar la clave de sesión mediante criptografía asimétrica?

Tendría que estudiarme el protocolo más a fondo (y ahora revisaré el post de TuXeD), pero desde mi punto de vista la criptografía asimétrica se utiliza para lanzar un desafío y ver si el otro extremo es quién realmente dice ser, y no para cifrar la clave simétrica. Y por otro lado, Diffie-Hellman para generar ésta de forma segura.

Hola,

A ver, la firma digital (asumiendo RSA) es tal que asi:

- Calcular hash sobre el certificado (SHA-1 por ejemplo)
- Calcular la firma: s = h^ d (mod n), donde d es la clave privada, n el modulo y s la firma resultado

Por tanto, se necesita d para generarla, y obtener d a partir de s requiere resolver el logaritmo discreto que es muy costoso. O bien factorizar n, que tambien lo es.

Ahora, la comprobacion es tal que asi:

- Calcular hash sobre certificado
- Obtener hash a partir de la firma: h' = s^ e (mod n) = h^{de} (mod n) = h
- Comprobar hash calculado con hash obtenido desde la firma

Si no son iguales, la verificacion falla. Si lo son, la verificacion procede xq indica que esa firma fue generada con d, que es la parte privada de la clave de la CA en la cual hemos confiado.

Me explico?

Hola de nuevo,

Nos solapamos

Lo que dices tu es otra forma de hacerlo, que es la que usa OpenSSH por loq ue dices, pero hasta donde yo estudie SSL en su dia el handshake funcionaba asi.

Aunque tambien es cierto que SSL/TLS incluye muchas posibilidades en el RFC y es posible que usar diffie hellman para el key exchange tambien este definido.

Un saludo

Vaya caos de posts! Cuando he contestado ni había leido el post de TuXeD... Pero mi duda viene cuando veo que él a posteado a las 12:24, Sor a las 12:25 y sale antes el post de Sor jajajaja.

En fin, el handshake lo entiendo:



Lo que no entiendo es como el navegador autentica el certificado a partir de sus certificados instalados (o sea, la tercera linea). Qué implica que el certificado esté instalado? Qué datos comprueba el navegador para saber que ese certificado es el mismo que tiene instalado?

Saludos y gracias por vuestra presteza!

Hmmmm, lo acabo de repensar...

NOTA MENTAL --> La idea es:

Envio un certificado con mi clave pública. Con algún método que no conozco (esa es mi pregunta) hago que el cliente crea que mi certificado es uno de los instalados, entonces, se pone el stick verde, no le sale ninguna notificación al usuario y el cliente envia una clave simétrica cifrada con la clave pública que yo le he enviado.

Esa es la idea!

A no ser que el cliente lo tenga instalado en el navegador (por ejemplo) no va a salir el stick verde a no ser que encuentres un fallo en la validación de la aplicación cliente (mmm, lo dudo). O a no ser que basándote en otra vulnerabilidad consigas que ejecute un programa que instale tu certificado como una AC válida.

Dependiendo de que navegador yq ue version uses, pueden 'caer' ante el ataque del byte nulo...

Hay por ahi un certificado valido para *\0.nosequedominio.com que se puede usar para probar esas cosas

Saludos

Que te lias NewLog!!!

Con las horas digo...

Yo al menos veo am y pm, y 11 y 12

Suerte,

Creo que con lo del byte nulo lo que se pueden falsear son los dominios... pero no me lo mirado a fondo

Gracias por el aporte

Supongo que se sale un poco del tema pero...

https://i.broke.the.internet.and.all.i.got.was.this.t-shirt.phreedom.org/

Opera y FF no tragan desde el principio, pero IE traga, aunque avisa ya que la fecha de caducidad del certificado esta puesta para 2004, para evitar malos usos... ahi hablaban de un ataque de colision a MD5 sobre estos temas...



Suerte,

P.D. Lo postee hace bastante tiempo, pero no logro encontrar el post... sorry

... a no ser que encuentres un fallo en la validación de la aplicación cliente (mmm, lo dudo).

Esa es la idea! Pero es necesario encontrar un fallo en la validación? Quizá utilizando un poco de ingenieria inversa se pueda (o ya se haya) conseguir. Quiero decir que si sabes cómo el navegador comprueba que el certificado sea válido (de los instalados) y sabes qué certificados vienen de série en el navegador quizá puedas generar un certificado que cumpla todas las comparaciones que haga el navegador.

Dependiendo de que navegador yq ue version uses, pueden 'caer' ante el ataque del byte nulo...

Ahora buscaré información sobre ello, pero no sabrás de algun link de calidad?


Al fin nos hemos entendido ^^


P.D.: vlan7 tienes toda la razón! Se me ha ido la cabeza a fondo jajaja! Por cierto, ahora no tengo ningún iexplorer a mano ^^