Una pequeña desilusión

Bueno, después de un buen tiempo me ha dado por ponerle SSL al servidor. Ya tocaba, eso de logearse por ahí y que la contraseña pase en plano, no mola. Aunque siempre existen otros riesgos, como un programa que logee las teclas que pulsas o lo que probé ayer, la técnica “del hombre del medio” o the man of the middle que con consiste más que en ARP Poisoning y snifar las tramas que pasan por nosotros. Sería hacer pensar a la máquina cliente y al router que nosotros somos ellos, es decir, el cliente pensará que nosotros somos el router y el router pensará que nosotros somos el cliente. Eso, más un errutado y capturando las tramas, y con por ejemplo Cain está mamado pues el solito te busca los equipos que tienes en tu red o en el rango que le especidiques, enrruta los paquetes a la vez que capturas las tramas. Por si fuese poro genera certificados SSL, que tras un despiste del usuario, obtendríamos el usuario y contraseña de ese acceso. Una pena que no haya Cain en SO POSIX.

El método sería envenenar la tabla MAC de el cliente y router, enrrutar y capturar, obteniendo de algún sitio un certificado válido. Bueno, luego, como decirle al cliente que el certificado auténtico es el nuestro, no se me ocurre nada. Lo bueno de ésto, lo que he aprendido, lo malo… no se me ocurre nada. ¿Modo de protegerse? Tabla ARP Estática, de éste modo cuando Cain o desde lo que sea, nos inyecten un paquete ARP falseado, no hará efecto. Probadlo, tenéis instrucciones aquí.
Para POSIX tenéis arpoison y nemesis entre otros. Para SO Windows tenéis que yo conozca, nemesis, pero seguro que hay más alternativas. Una cosa que he de decir es que Nemesis en Windows requiere la librería LibnetNT y WinPcap. La verdad es que es muy quisquilloso con las versiones o quizá que el las máquinas en que probé algún parche oficial jode la marrana.

Me estoy enrrollando xD, si os dais cuentas, el título del post no va por ahí. Va por el Apache y SSL. Ayer, cuando implementé el SSL me surgía un problemilla, que siempre salía el mismo fuese el VirtualHost que fuese (Mi idea era tener uno diferente para cada uno). Me estuve rucando la cabeza una tarde-noche hasta que al final desistí, dejé mis pruebas y me dispuse a leer un puto RFC, no recuerdo su código, pero en resumidas cuentas, si los servidores virtuales no están corriendo en otra IP, u otro puerto, es IMPOSIBLE tener diferentes certificados SSL para cada servidor virtual. ¿Por qué? Bueno, pueden hacerse 2 cosas:

  • Pensar un poco: Suele ser lo mejor el razonamiento es que antes de el cliente hacer el GET mediante HTTP 1.1, se procede a la negociación con un certificado. Es decir, se usa ese y punto, luego se hace el GET y el servidor Web es el que decide que webs mostrar basándose en la información de la cabezera que el protocolo HTTP 1.1 proporciona. Si coincide con el ServerName o ServerAlias (De lo segundo no estoy seguro) del cualquier servidor virtual, ofrece ese documento, sino, va al sitio por defecto _dafault_.
  • Capturar tramas: Bueno, nuestro comodín, capturar las tramas y ver como no hay nada HTTP, todo es SSLv3 (En Ethereal) y vemos como los primeros paquetes son negociaciones Servidor-Cliente.

Bueno, al menos, ahora, duermo más tranquilo al pensar que mi password va por una capa TLS1 (Evolución de SSLv3, que comprueba que origen y destino de los paquetes son quien dicen ser).

Venga, agur.

Anuncios

7 Responses to “Una pequeña desilusión”


  1. 1 iDavid 4 enero 2006 en 19:14

    Friki de la seguridad…

  2. 2 Gura 4 enero 2006 en 22:25

    Que comentarios mas constructivos ¬¬

  3. 3 igayoso 5 enero 2006 en 10:39

    No sé si es mi sueño, pero veo un nivel muy alto de frikismo conjuntado con la seguridad, es decir, veo un comentario del Gura…

  4. 5 KikoV 10 enero 2006 en 12:38

    Bueno, realmente existe una cosa que es la renegociación del certificado.

    Está implementado en TLS/1.0 creo. Esto debe soportarlo tanto el servidor como el cliente. En el caso del servidor, se me está ocurriendo que el Cherokee de ALO lo soporta ( o eso me dijo él ). El caso es que no es fácil averiguarlo porque no dispongo de ningún navegador que soporte eso.

    El problema tiene que ser bastante sencillo de solucionar en los navegadores. Sería aceptar el certificado temporal que te dan, hasta que mandas el GET / y el Host: . Entonces, si el servidor no te cambia el certificado, lo das por final, y si te lo cambia pues lo tomas.
    A partir de ese momento es cuando el navegador tiene que hacer el chequeo correspondiente del certificado ( esto es, el fqdn coincide con el del certificado, y éste es válido.. Si no lo fuera mostrar el mensaje de advertencia al usuario, etc… )

    Un saludo

  5. 6 Gura 10 enero 2006 en 16:29

    Claro, la idea es cojonuda. Leeré acerca de ello. Gracias por el comentario.

  6. 7 Samuel Harrison 20 julio 2006 en 13:39

    Greets to the webmaster of this wonderful site. Keep working. Thank you.


Comments are currently closed.



Las opiniones reflejadas en este blog son personales o ni siquiera son opiniones, y bajo ningún concepto representan las estrategias, opiniones o posturas de mi empresa actual, ni de ninguna en las que he trabajado, así como tampoco de ninguno de los clientes o proveedores de todas ellas.
La información se proporciona como está, sin garantías de ninguna clase, y no otorga ningún derecho. Los comentarios pertenecen a sus autores y bajo ningún concepto el autor del blog se hará responsable de los mismos.

Categorías

Archivos


A %d blogueros les gusta esto: