Java 4-Ever!

En Amarello desde siempre hemos apoyado el Open Source, y en el ámbito profesional siempre nos encontramos con muchas personas que prefieren tecnologías privativas, por lo que a veces nos hemos sentido fuera de lugar en algunos ambientes. Ojalá alguien nos entendiera…

El siguiente video es el trailer de la que podría  ser la mejor película geek del año. Disfrútenlo y tómenlo como lo que es: un chiste.


Java 4-Ever
Via: Koreus

¿Como saber si el ISP o la infraestructura telefónica del lugar son el problema de la conexión de Internet DSL?

Hoy en día la gran mayoría de los Routers modernos cuentan con una consola de información en la cual se indica el status de conexión, así como muchos datos interesantes que luego ignoramos por no saber qué significan.

Mi historia es la siguiente:

Yo era un fiel cliente de cablevisión, contaba con servicios de televisión y de internet en casa. Hasta que decidí cambiarme a prodigy debido a que requería tener una ip pública y estaba un poco cansado de que mi conexión se alentara en horas pico.

Después de contratar prodigy pensé que mis problemas se iban a solucionar, sin pensar más conecté el paquete infinitun que llegó a casa. Después de usarlo unos días me daba cuenta que la conexión era muy inestable, innumerables veces reinicié mi router esperando que se arreglara el problema, muchas veces funcionaba, otras no. En fin, no le di importancia ya que, al ser poweruser, podía reiniciar mi router de manera remota y olvidarme momentáneamente del problema. Algún amigo me comentó que el soporte que da prodigy es de los peores en México y que no perdiera mi tiempo marcando ya que lo único que lograría serían soluciones como “¿Ya reinicio su computadora?”, “Apague y vuelva a prender su router”, “El problema debe ser su computadora, seguro tiene algún virus”, “Algún equipo en su red debe estar consumiendo todo el ancho de banda”.

Después de algunos meses batallando con este tipo de problema empecé a notar que no solo perdía mi señal DSL sino que también tenia limitado mi velocidad ya que muchas veces llegaba ha dar hasta el 70% de la velocidad contratada, y después de unos días el problema se agravó quedando muchas veces horas sin internet y cuando llegaba a tener suerte un 20% de la velocidad contratada.

Llegó mi punto de quiebre y me dediqué a marcar al soporte técnico de prodigy esperando a que resolvieran mi problema. Pero inesperadamente al estar hablando con la persona que me atendía me di cuenta que mi conexión de internet mejoraba notablemente, y después de algunos minutos argumentando que no necesitaba soporte de usuario torpe (“¿Ubica el cable amarillo?”, “De click en el menú inicio”, “MacOSX ¿que es eso? solo damos soporte a Windows”) le comenté que ya estaba en la consola del router y le expliqué que mi problema no era mi red local (ya que no tenía otro equipo conectado), tampoco la red inalámbrica (Estaba conectado vía cable UDP), tampoco los filtros y los teléfonos (tenia filtro en cada teléfono de casa y había corroborado que estuvieran bien conectados antes de hacer la llamada) y mucho menos era mi computadora (tenía cerrado todo y monitoreando que ninguna aplicación hiciera alguna conexión remota).

Después de un rato de charlar y descartar lo que antes mencioné, me levantaron un ticket de reporte explicando que el técnico se comunicaría en los próximos 2 días para ver si el problema era de la calle o la infraestructura de mi casa, al terminar colgué y me dispuse a resolver el problema sin la necesidad de nadie.

Navegando (después de haberme dado cuenta que con la llamada mejoró mi conexión) me topé con una página que explicaba sobre el ruido en la señal telefónica y los síntomas que pudiera generar. Investigué un poco más y me tope con esto:

En la consola del router se pueden checar estos valores: Atenuación máxima y SNR. Por lo que se me ocurrió la brillante idea de hacer la prueba desconectando todos los teléfonos y otra prueba con todos los teléfonos conectados.

- Atenuación máxima: -mejor
Para 256 kbps: 64 dB.
Para 512 kbps: 55 dB.
De 1024 kbps en adelante: 41 dB.
De 6144 kbps en adelante (6 megas): 30 dB.
De 20480 kbps (20 megas): 20 dB.

- Margen señal-ruido (SNR): +mejor
6 dB o menos: Conexión inexistente o con graves deficiencias de estabilidad.
Entre 7 y 10 dB: Es posible que aparezcan problemas dependiendo de otros factores.
Entre 11 y 20 dB: Valor óptimo.
21 o más dB: Valor excelente.

Me di cuenta que si había gran mejora desconectando los teléfonos, entonces el problema era la infraestructura de la casa. En el caso de que no mejorara el problema sería la línea que llega desde la calle a casa y sería tiempo de llamar, de nuevo, al soporte telefónico de prodigy para reclamar por su pésimo servicio. Pero al darme cuenta que mi problema se arregló parcialmente fui descartando teléfonos hasta que di con el problema, uno de ellos generaba demasiado ruido (era marca Siemens) e interfería con la señal del DSL aún con filtro.

Al final concluí que entre más teléfonos conectados más ruido se generaba (en mi casa hay 9) y también influye a que altura de la linea conectes el DSL, pues no es lo mismo conectarlo desde donde llega a la casa la línea o al final de toda la cascada de conexiones telefónicas.

+Telefonos + Ruido = +Problemas de conexión

Si vemos bien la tabla anterior, donde se muestran los dB máximos y mínimos, nos podemos dar cuenta que aunque contratemos una conexión de 6mbps la infraestructura del lugar puede no soportarla debido a:

-la cantidad de teléfonos conectados a la infraestructura
-la distancia entre la central y el lugar
-la calidad de los teléfonos y filtros

Finalmente resultó que mi SNR era muy bajo debido a la cantidad de ruido que generaba un teléfono en particular y la otra razón que no he podido, ni podré resolver, es que tengo demasiada “Atenuación máxima” debido a la lejanía de mi casa con la central. Pero gracias a la tabla anterior puedo saber hasta que velocidad puedo contratar sin desperdiciar el ancho de banda pagado.

Puede ser que cablevisión dé servicios inferiores, pero como el equipo se encuentra dentro de la red interna (de ellos) es mucho más estable, puedes contratar más velocidad y no tener pérdida. A diferencia de una conexión DSL, Cablemodem llega vía cable coaxial desde un repetidor en la calle de fibra óptica, prácticamente no hay pérdida (sólo un poco de la calle a tu casa) y además no usas la infraestructura telefónica que aumenta el ruido por cada teléfono que conectes.

Mis conclusiones finales son:

Si lo que requieres es velocidad en el futuro : Cablevisión
Si lo que requieres es velocidad hoy y hasta que llegue al límite de lo que pueda aguantar la infraestructura del lugar: Prodigy

Por cierto, este problema me recuerda a un post que me dio mucha risa.

Autenticación segura sin SSL/TLS

Muchas veces no es necesario o es demasiado cifrar toda la comunicación entre el cliente y el servidor, por razones de performance o por el sobrecosto de implementar un esquema de PKI (Public Key Infraestructure) para usar SSL/TLS. Pero siempre hay algo que es necesario proteger por seguridad: las credenciales de autenticación del usuario. Por lo que en este post explicaré cómo se puede hacer una autenticación sin enviar esa información (no, no es telepatía).

Protocolos de conocimiento cero (ZKP)

Sabemos que sin un esquema de cifrado de llave pública es trivial para un atacante interceptar la información que se envía entre el cliente y el servidor, pero el sistema debe tener alguna manera de autenticar a los usuarios del sistema. Necesitamos enviar algo que si un atacante intercepta no pueda utilizar para autenticarse. Esto se conoce como un protocolo de conocimiento cero (Zero-knowledge proof), y en palabras coloquiales significa: “probar que poseemos cierta información sin revelar esa información”.

Como comúnmente la única información que queremos “probar que poseemos pero no queremos revelar” es la contraseña, voy a explicar el esquema que usa MySQL para implementar su autenticación de usuarios. Los detalles no están explicados de manera formal en la documentación de MySQL pero alguien se tomó el tiempo de leer el código fuente y explicar cómo funciona (MySQL 4.1.x authentication internals).

¿Cómo se almacenan las contraseñas?

Lo primero que hay que tener en cuenta es que, siguiendo los principios básicos de almacenamiento seguro de contraseñas, éstas se almacenan en el sistema sólo como un hash criptográfico. Que tiene la propiedad de ser prácticamente irreversible y prácticamente único. Por lo que esta es la primera parte del ZKP, ya que sólo quien conozca la contraseña podrá generar el hash criptográfico que le pertenece.

Desde MySQL 4.1 las contraseñas de usuario están almacenadas en la tabla “mysql.user” en la columna “Password” de la siguiente manera: SHA1(SHA1(password)). Donde SHA1 es el hash criptográfico SHA-1.

La transmisión

Si cada vez que el cliente se quiera autenticar sólo transmitiera SHA1(SHA1(password)), cumpliría con el principio de no revelar la contraseña, pero un atacante podría capturar y enviar después SHA1(SHA1(password)) para autenticarse exitosamente aún sin conocer la contraseña. Por lo que necesitamos agregar más cosas al protocolo para que la información que transmite el cliente sólo sea útil para un intento de autenticación.

Este sería el esquema cliente-servidor para la transmisión:

  1. Se inicia el intento de autenticación
  2. El servidor genera una cadena aleatoria salt y se la transmite al cliente.
  3. El cliente calcula S_1 = SHA1(pass), S_2 = SHA1(S_1) y S_3 = SHA1(salt+S_2) (aqui + significa concatenación).
  4. Finalmente el cliente transmite M = S_3 \oplus S_1. (aquí \oplus significa bitwise XOR)

Autenticación

El servidor sólo conoce H = SHA1(SHA1(password)), que está almacenado en la tabla de usuarios, y salt. Para autenticar hace lo siguiente:

  1. Calcula S'_3 = SHA1(salt+H).
  2. Calcula S'_1 = M\oplus S'_3.
  3. Calcula S'_2 = SHA1(S'_1).
  4. Sólo si H=S'_2 la autenticación es exitosa.

Observaciones

Nunca se transmite S_2 ni S_1, por lo que la fortaleza está en que este ZKP verifica que el cliente conoce SHA1(password)) y SHA1(SHA1(password)) pero sin revelar esa información, y que sería casi imposible que un atacante poseyera sin conocer password.

También hay que observar que salt es una cadena única por cada intento de autenticación, o sea que esa cadena siempre está cambiando.

Implementación

Próximamente trabajaremos en una implementación de este esquema para aplicaciones web usando JavaScript y PHP, que publicaremos bajo licencia LGPL.