Archivo

Archivo para la categoría ‘codear’

Investigando el protocolo SPDY

domingo, 15 de julio de 2012 2 comentarios

Un tiempo atrás venía buscando áreas de investigación para estudiar, y me encontré con una interesante propuesta de Google, de renovar el ya «viejito pero cumplidor» protocolo HTTP 1.1, llamada SPDY (no sin algo de sentido comercial, se nota).

De ahí en adelante (dado que el desarrollo es abierto a la discusión en general) me dediqué a profundizar en él, entender sus ventajas (lo cual implica entender algunas cosas feas de HTTP 1.1 y la Web de hoy en día), limitaciones, y cosas que faltan implementar. Me apasionó el tema, tanto es así que lo propuse como tema de Tesis para mis estudios y hasta ahora vengo bien (bien con las promesas a mi Director, claro está :-P).

Mi idea era con este post abrir una serie de artículos para documentar lo que voy aprendiendo sobre este protocolo, que cada vez tiene más hype en la industria, tanto que Twitter y Google ya lo implementan en sus servidores (Facebook está en camino), mientras que Chrome/Chromium y Firefox (Opera se está sumando) también lo usan si está disponible.

Personalmente me puse a probarlo y a tratar de implementarlo usando Python, forkeando un proyecto que ya existía y arreglando los problemas más obvios que encontré. Todavía tengo todo el código «atado con alambre», no bien testeado, y no estoy seguro si funciona del todo (jua!), pero de ahora en más voy a tratar de mejorarlo y mantenerlo mientras pueda, además de dejar algún rastro por aquí y por mi trabajo de investigación formal.

En resumen, el IETF draft de SPDY está disponible acá; tanto parece estar movilizando este protocolo, que el HTTPbis Working Group, encargado de definir un futuro HTTP 2.0, se está moviendo desde hace un tiempo para discutir las propuestas de SPDY. Y esto recién empieza…

Les dejo un video del último Google IO 2012 que es un excelente acercamiento técnico al tema:

Saludos

Categories: codear, python, web Tags:

Instalando DD-WRT en un TP-Link TL-WR941ND

sábado, 2 de junio de 2012 169 comentarios

Uno compra un Router/Access Point estos días con la esperanza de que el firmware (software en el equipo) que tiene cargado sea eficiente, no tenga bugs (o al menos tenga actualizaciones periódicas del fabricante que los corrija), e incorpore muchas capacidades interesantes para sacarle el jugo, como el uso de conexiones VPN, priorización de tráfico, poder regular el poder de la antena, gráficos/estadísticas de uso de la conexión, y muchas «cositas» que a nosotros (la gente técnica) nos gusta aprovechar del dispositivo, todo por el mismo precio.

Pero lo más común es que suceda todo lo contrario. Mi router TP-Link TL-WR941ND, apenas lo compré, le actualicé el firmware oficial, y de ahí en más, a los dos o tres días de estar prendido, mágicamente «se cae», dejando de responder, acudiendo obligatoriamente a apagar y encenderlo nuevamente. Ni hablar de actualizaciones posteriores, ni funcionalidades «copadas». Casi que me sentí estafado; siendo previo poseedor de un mítico Linksys WRT54G, lo cambié por el TP-Link que es de norma 802.11N, por ende prometía más velocidad y alcance en mi red.

Pasaron unos meses, hasta que en el FLISOL Luján de este año, Efraim me instaló en el Linksys un firmware libre, basado en Linux, llamado DD-WRT que funciona en muchísimos modelos de Access Points/Routers (más de 200 según la página, aunque seguro son más). De antemano sabía de la existencia de estos proyectos/distros de Linux, aunque ignoraba lo bien logrado que estaba y las muchísimas capacidades que le agregaba automáticamente al tenerlo instalado.

Es por todo eso que tenía pendiente instalar DD-WRT en mi TP-Link para liberarlo… hasta hoy: migración exitosa.

Puedo comentar que:

  • El proceso de instalación tiene bastantes particularidades, dependiendo mucho del dispositivo y de la versión del hardware que se tiene; sí, dentro de un mismo dispositivo, hay como diferentes «releases» o versiones del hardware (1.0, 2.0, 3.0…), donde el fabricante agrega/saca características, y puede influir tranquilamente en la versión del firmware a instalar.
  • Por lo anterior, sugiero encarecidamente leer toda la documentación, foros y wiki disponible, además de tomar todas las precauciones del caso, ya que un error se puede pagar tirando el router al tacho de basura.
  • Yendo más a mi situación particular, el router TL-WR941ND figura en el Router Database del proyecto, y dice que funciona con la versión 15778 del firmware dd-wrt (que entre otras cosas, ¡parece ser del 2010!). Además está dentro de la página de dispositivos con hardware Atheros soportado.
  • Yo tengo la versión 3.6 del hardware, lo compré hace algunos meses nomás en Galería Jardín, así que es bastante probable que todavía y por un tiempo haya versiones iguales dando vueltas.
  • Lo único que hice fue buscar, en foros, como documentación, y encontré que el «router database» estaba desactualizado, y había una versión mucho más actualizada y probada que no estaba linkeada en la página (está en este FTP).
  • La parte más fácil fue el upgrade en sí: sólo tuve que ir a «Upload firmware» en el administrador web del TP-Link, subí el archivo «factory-to-ddwrt.bin» que bajé del FTP, apagar/prender y listo. 🙂

Ahora tengo muchísimas más opciones y potencia que antes en mi equipo y la casi certeza de que va a funcionar correctamente. En este mismo FTP también se van subiendo periódicamente las versiones nuevas del dd-wrt (del 2012), separada por equipo/versión de hardware: ftp://dd-wrt.com/others/eko/BrainSlayer-V24-preSP2/2012/

A disfrutar del Software Libre se ha dicho. 🙂

¡Saludos!

Categories: codear, linux, sysadmin Tags:

Jornada de Python en Luján: PyDay Luján 2012

miércoles, 28 de marzo de 2012 Sin comentarios

PyDay Luján 2012 PyAr, el grupo de usuarios de Python Argentina, está orgulloso de presentar una nueva Jornada del lenguaje de programación Python 2012 (PyDay) en la Universidad Nacional de Luján, el día Sábado 5 de Mayo de 2012 de 11Hs a 18Hs.

Durante el Python Day se darán pequeños cursos y charlas relacionadas a este lenguaje, creando un espacio en donde cualquier persona interesada pueda acercarse para preguntar, aprender y experimentar con esta herramienta.

Python es un lenguaje moderno, sencillo de aprender pero muy poderoso en cuanto a la cantidad de aplicaciones en las que es usado profesional y académicamente: en sitios web, en juegos, aplicaciones de escritorio y en scripting en general, etc…

El publico al que nos dirigimos es de todos los niveles, pero estamos muy interesados en acercar Python a quienes solo lo conocen de oído o directamente no saben de que tipo de lenguaje se trata. Tendremos charlas especiales para ellos.

Con esta misma invitación damos por iniciado el Call For Charlas; aquellos interesados ya pueden proponer nuevas charlas y son bienvenidos los colaboradores y empresas/entidades interesadas en participar y auspiciar la jornada.

Cualquier duda o consulta, puede visitar la página del evento, o contactarse vía mail a pydaylujan@gmail.com.

El encuentro se llevará a cabo en el pabellón 400 de la sede central de la UNLu (ver página Cómo Llegar)

La entrada libre y gratuita (previa inscripción web), ¡los esperamos!

 

Categories: codear, python Tags:

Cursos Asterisk 2011

jueves, 10 de marzo de 2011 1 comentario

Hola, paso a dejar un lindo chivo aviso sobre cursos de Asterisk que están armando un grupo de gente conocida y amiga, en su versión 2011:

Bitsense, empresa dedicada a la implementación de soluciones telefónicas, dará comienzo a su curso de capacitación de Telefonía IP denominado BiaC (Bitsense Initial Asterisk Course) edición 2011, el mismo es el primer curso en la Argentina dictado por dos instructores certificados dCAP (Digium-certified Asterisk Professional) junto con el apoyo de certificados Cisco y Juniper. Este curso está orientado a brindarle las herramientas y conocimientos necesarios para implementar una infreastructura de Telefonía IP basado en Asterisk desde su inicio.

Para solicitar mas informacion envienos un mail a capacitacion@bitsense.com.ar y un representante se comunicará con usted o llamenos al telefono 5353.9858 (opción 2).

Le informamos también que referenciando esta publicación (si, ¡este blog!) usted accederá a un descuento especial.

http://www.bitsense.com.ar/cursos/biac/

Saludos

Categories: codear, misceláneos Tags:

Estableciendo conexiones HTTPS «bien seguras» en Python

sábado, 19 de febrero de 2011 2 comentarios

Hace unos días que tenía pendiente colgar esto acá, ya que a alguien en PyAr le fue útil.

HTTPS es la manera de establecer conexiones HTTP pero seguras, en el sentido de que previo al diálogo HTTP estándar pero luego de establecerse la conexión TCP contra el servidor, se negocia entre los participantes una conexión/sesión «especial» entre ambos.  Allí se intercambian certificados con el fin de autenticar contra quién se «está hablando», para luego, si hubo éxito en la dicha comprobación, encriptar (o no) todo lo que va para el otro lado, tanto del Servidor al Cliente (generalmente un navegador), como del Cliente al Servidor.

Todo eso forma parte de SSL 3.0 (hoy TLS 1.0), y si bien se puede utilizar para cualquier conexión TCP (SMTP, IMAP, etc., lo pueden usar también), su uso más común se da cuando uno entra a su casilla de Webmail o su cuenta del Banco desde el navegador;  lo que sucede allí es que nuestro navegador autentica al Servidor, y si todo va bien nos muestra el famoso «candadito» e informa que la sesión «es segura». Ahora bien, en esos casos, el Banco o Webmail no nos autentica a nosotros como Cliente y deja que cualquiera se conecte a su página, ya que eso requiere varios pasos más (sería realmente engorroso que sea obligatorio).

Sin embargo, en nuestra vida de programadores nos solemos encontrar con necesidades del entorno que nos obliguen a esta situación un tanto extrema y bastante más segura: que tanto el Cliente que desarrollamos autentique al Servidor como que el Servidor autentique al Cliente, amén de que la conexión muy probablemente deberá estar encriptada. Esto nos permitirá asegurarnos que los Clientes (software) que se conecten a nuestro Servidor sean únicamente quienes queremos que sean (o casi).

Python, dentro del módulo httplib nos provee de la clase HTTPSConnection, que maneja y nos abstrae en varias de estas cuestiones de SSL/TLS y nos deja trabajar a nivel HTTP (una capa más arriba). Lo que hay que observar bien (y que recién en la versión 2.7 de la documentación apareció en rojo), es que esta clase aún cuando uno le puede pasar como parámetro los paths a certificados, en realidad no hace ninguna comprobación de validez del certificado que el Servidor exporta. Con lo cual, hay un potencial problema: que nuestro cliente mande los datos a cualquier lado menos a nuestro Servidor de confianza.

¿Y cómo se fuerza a que nuestro programa Cliente chequee el certificado del Servidor? Armé esta clase que extiende sólo lo necesario a HTTPSConnection, que funciona en Python 2.6.x y que me permite hacer eso.

Le agregué un ejemplo en la llamada a __main__ para mostrar cómo se usa:

#!/usr/bin/env python
#-*- coding: utf-8 -*-
 
import socket
import ssl
import httplib
 
class HTTPSClientAuthConnection(httplib.HTTPSConnection):
    """ Class to make a HTTPS connection, with support for full client-based
        SSL Authentication.
    """
 
    def __init__(self, host, port, key_file, cert_file, ca_file, timeout=None):
        httplib.HTTPSConnection.__init__(self, host, key_file=key_file,
                                                   cert_file=cert_file)
        self.key_file = key_file
        self.cert_file = cert_file
        self.ca_file = ca_file
        self.timeout = timeout
 
    def connect(self):
        """ Connect to a host on a given (SSL) port.
            If ca_file is pointing somewhere, use it to check Server Certificate.
 
            Redefined/copied and extended from httplib.py:1105 (Python 2.6.x).
            This is needed to pass cert_reqs=ssl.CERT_REQUIRED as parameter
            to ssl.wrap_socket(), which forces SSL to check server certificate
            against our client certificate.
        """
        sock = socket.create_connection((self.host, self.port), self.timeout)
        if self._tunnel_host:
            self.sock = sock
            self._tunnel()
        # If there's no CA File, don't force Server Certificate Check
        if self.ca_file:
            self.sock = ssl.wrap_socket(sock, self.key_file, self.cert_file,
                        ca_certs=self.ca_file, cert_reqs=ssl.CERT_REQUIRED)
        else:
            self.sock = ssl.wrap_socket(sock, self.key_file, self.cert_file,
                                              cert_reqs=ssl.CERT_NONE)
 
if __name__ == '__main__':
    # Little test-case of our class
    import sys
    if len(sys.argv) != 6:
        print 'usage: ./https_auth_handler.py host port key_file cert_file ca_file'
        sys.exit(1)
    else:
        host, port, key_file, cert_file, ca_file = sys.argv[1:]
    conn = HTTPSClientAuthConnection(host, port, key_file=key_file,
                                           cert_file=cert_file, ca_file=ca_file)
    conn.request('GET', '/')
    response = conn.getresponse()
    print response.status, response.reason
    data = response.read()
    print data
    conn.close()

En cuanto a la generación de las claves de Cliente, Servidor y CA hay unos cuantos artículos y es relativamente sencillo una vez que se entiende qué se está haciendo. Por otra parte que en estos casos es muy común que el Servidor exija que el Cliente si o sí envíe su certificado o sino la conexión se deberá caer; esto en el caso del Servidor Apache está bien documentado.

Entiendo que en Python 3.2 esto está resuelto en la misma API standard de Python (en su momento abrí un ticket similar para usar esto con urllib2, que incluye cosas importantes como el manejo de cookies, por ejemplo), y comentaron eso.

Según me dijeron en PyAr, es casi seguro que este ejemplo no funcione en Python 2.7, así que en un futuro no muy lejano espero poder adaptar este código a dicha versión y seguramente lo estaré subiendo en esta página.

Saludos

Categories: codear, programación, python, ubuntu-ar Tags: