Archivo de la categoría ‘Programas’

Seguridad: Sniffing. Capítulo Cuarto -> Analizadores/Capturadores de Paquetes

ATENCION: Los ejemplos que se van a mostrar y “tutoriales” tan solo tienen carácter educativo. En ningún aspecto comparto filosofías de invasión a la intimidad, ataques contra un sistema informático o cuestiones similares. En la medida que sea posible siempre se usarán ejemplos y formas que puedan ser usados por cualquier persona, de forma que pueda verificar los contenidos escritos. No obstante, por motivos más que obvios, materiales como contraseñas, nombres de usuarios o de hosts, serán omitidos o modificado en las capturas de pantallas realizadas (o las lineas escritas). Es decir, los ejemplos serán completamente reales, los datos mostrados a vosotros necesarios para poder pertrechar estos ejemplos no siempre lo serán (Sí lo serán los resultados). Para que esto conste de forma clara, todo material sensible modificado o falso estará resaltado en ROJO. Por motivos de seguridad, todo el material que sea expuesto aquí (exceptuando software propietario o libre, citaciones expresas o código de terceros) tanto texto, imágenes y código son propiedad del autor y está completamente prohibido su reproducción completa o parcial en otros lugares, espero que se comprenda.


Analizadores de Paquetes («Sniffers»)

Los protocolos se especifican sobre papel para dar una serie de descripciones sobre como deben de funcionar, como deben de ser implementados, sus propósitos… pero es evidente que su uso no solo posee el ámbito de lo teórico. Teorizar sobre el papel o crear implementaciones de los protocolos es fácilen comparación de las implementaciones prácticas, pero sobre todo a la hora de verificar su correcto funcionamiento. Al igual que en programación disponemos de depuradores paso a paso para ir comprobando el correcto comportamiento de un algoritmo, los protocolos de red necesitan de una herramienta similar que puedan comprobarlos, verificarlos… a fin de cuenta observarlos. De esta necesidad nacen los Analizadores de Paquetes. ¿Qué son? Software que son capaces generalmente de capturar desde paquetes (nivel 3 en modelo OSI) hasta frames (nivel 1 y 2 del modelo OSI), y posteriormente analizarlos. Para que esto sea posible es común que el sistema requiera algún driver especial para poder ser capaz de capturar paquetes «raw» por la interfaz de red, generalmente, Ethernet. El propósito es evidente, gracias a estos analizadores de paquetes podemos ver de forma simple todo lo que circula por nuestra interfaz de red.

En realidad, aunque «Sniffers» sea el tema principal de este artículo, posiblemente lo que son los sniffers en sí mismos sea el capítulo más corto de todo ello, puesto que estos no son sino las orejas. Es por ello que para comprender bien su funcionamiento era necesario conocer al menos los protocolos más usados a día de hoy, pues básicamente es lo que va a mostrarnos un Sniffer. El como interpretemos dichos datos tendrá en gran medida relación a lo bien que conozcamos los protocolos inferiores que tenemos. Recordemos que el modelo TCP/IP o el modelo OSI son modelos jerárquicos!! una página web usando el protocolo HTTP se encapsula dentro del protocolo de transporte TCP, y este a su vez dentro de IP, y este en un frame Ethernet… El Sniffer puede mostrarnos incluso de forma simple cada uno de estos protocolos, pero la mejor forma de comprender la información que nos muestra es sin duda alguna conociendo los protocolos que se han usado.

Aunque los analizadores/capturadores de paquetes nacieron por la necesidad de analizar los protocolos e implementaciones de estos, a día de hoy su valor para asegurar cualquier infraestructura de red es inestimable. Un Analizador de paquetes a fin de cuentas es capaz de monitorizar todo el tráfico entrante y saliente de un mismo equipo (y incluso todo el tráfico que circula por una red), lo que permite desde detectar problemas en cualquier nodo de la red, detectar ataques desde esta o desde fuera y por supuesto espiar cualquier tipo de información que se transfiera por dicha red. «Sniffer» es el término coloquial para referirnos a un capturador de paquetes, su traducción sería algo así como «Husmeador» u «Olfateador». Sin embargo la experiencia nos dice que por regla general el término Sniffer se suele relegar al ámbito Hacker o Underground, mientras que en la literatura formal o dentro de la seguridad es más común usar el término «Analizador/Capturador de paquetes». Como ya se ha visto, aquí generalmente usaremos el término Sniffer, simplemente porque es más corto.

  • Capturando y analizando paquetes
  • Modificando el tráfico a nuestra voluntad: OGame -> OGame Automatizer
  • Envenenamientos: ARP y DNS
  • Certificados y Túneles
  • Un apunte sobre WIFI



Capturando y analizando paquetes

Dada la gran versatilidad y potencial de los analizadores de red, estos jamás pueden pasar desapercibidos para nadie, ni siquiera para usuarios novatos dentro de la informática, los cuales tendrían que conocer al menos su existencia, sus virtudes y sus usos. A fin de cuenta es la única manera de que los usuarios puedan tener cierto grado de seguridad. Con los Sniffers se aplica una de las afirmaciones más comunes de la informática: «Toda la información que pueda maneja el PC, puedes ponerla a tu disposición para el fin que sea por algún medio, pudiendo simplemente desde capturar dicha información a manipularla a tu antojo». Esto quiere decir que no podemos ver el PC como una caja negra, sino como una caja transparente a la que podemos meter la mano cuando deseemos.

Que un usuario pueda ser capaz de visualizar todo el tráfico que circula por su equipo puede ser de por sí un gran problema de seguridad, pero aun es peor si dicho usuario puede de forma simple visualizar absolutamente todo el tráfico de su red. Pero la constitución de Internet se realizó pensando en su versatilidad y facilidad de uso, no en su seguridad, y cualquier dato enviado o recibido por nuestra red, ya sea de forma interna (una LAN) o externa (Internet), puede ser fácilmente leído si este es enviado en lo que llamamos «texto plano», lo cual es lo que se realiza el 90% de las veces. Todo el tráfico que no se esté cifrando con algún protocolo o sistema punto a punto, es altamente propenso a ser interceptado e interpretado, y en consecuencia, si así se desea, a ser modificado. Por desgracia la seguridad no es algo en lo que se ponga mucho empeño por regla general por parte de las compañías, y aunque existen método casi inexpugnables en cuanto a seguridad se refiere, estos solo solemos encontrarlos en sitios puntuales. Es decir, la tecnología para ello existe, pero no se usa como se debería ni cuando se debería.

El Modelo TCP/IP es muy simple de manejar, y si los datos se envían siempre de determinada manera, en algún punto el hardware y el software interactúan de tal modo que es posible mediante drivers de sistema o aplicaciones específicas, usar el adaptador de red en lo que llamamos un «monitor». Dicho de otro modo, podemos inducir en el adaptador de red un modo de funcionamiento tal que pueda «escuchar» todo lo que pasa a través de él, es decir, capturar todo el tráfico de red que llegue hasta él, ya sea tráfico entrante o saliente. Esta es la razón por la que en prácticamente cualquier sistema operativo, se requiere ante todo este driver que permite leer los frames directamente desde el adaptador de red. Nosotros en todo momento nos referiremos a adaptadores de red tipo Ethernet, aunque esto es extrapolable a cualquier tipo de adaptador de red, con más o menos matices por supuesto (WIFI, Fibra, Token-Ring…).

No hay que irse muy atrás el tiempo cuando esto no era algo tan simple. Para que un sistema pueda acceder a estos frames, el mismo hardware (el adaptador de red) como los drivers del sistema que lo gobierna, deben de estar pensados para ello. Del mismo modo el OS que está por encima debe de ser capaz de recibir dichos datos. Técnicamente esto es tarea del capturador de paquetes, mientras que el analizador de paquetes no es más que un software que recibe e interpreta dichos datos. En Windows 7, ya se incorporan mecanismos internos para poder realizar las labores de captura, pero es más común el uso de las librerías y drivers de sistema WinPcap, y será lo que usemos. Por otro lado, WireShark hará el papel de Analizador. Importante: El Sniffer no podrá en ningún momento ser capaz de capturar aquellos bits/bytes que sean filtrados o descargados directamente por el Hardware!! El ejemplo más común de ello (como ya veremos) es que en los frames Ethernet no es posible capturar los bytes del preámbulo o los Bytes interframes. Del mismo modo es común no poder visualizar los 4 Bytes del FCS (El CRC del protocolo Ethernet. Esto en WIFI tiene mayor relevancia, puesto que es complicado poder capturar los llamados Frames de control.

 

Bien, hemos dicho que un capturador de paquetes será capaz de leer todo el tráfico de red que circule por nuestro adaptador de red. Esto nos garantiza que el 100% de todo el tráfico enviado por nuestro sistema al exterior y todo el tráfico enviado a nuestro sistema (ya sea enviado desde el exterior o desde nuestro propio sistema a sí mismo) podrá ser recogido. Pero si se entendieron los capítulos anteriores, los datos enviados desde nuestro sistema o enviados específicamente a nuestro sistema, no son los únicos datos que pueden llegar a nuestra interfaz de red. Un ejemplo sencillo a esto sería cualquier tráfico que sea enviado por broadcast o multicast, que es tráfico enviado no a un host concreto, sino a todos los host de una red o a un conjunto de hosts de esta. Es decir, que todo el tráfico que sea enviado a broadcast o multidifusión podría ser igualmente capturado por nuestro adaptador (por ejemplo tráfico generado por DHCP o ARP).

Es necesario llegado a ese punto diferenciar lo que es que un dato sea enviado a un host concreto de forma lógica o de forma física. Es fácil, imaginar que dos equipos se conectan uno al otro por un cable de red. Independientemente de la IP o configuración de red de cada uno, si uno de los equipos coloca un dato en la linea de recepción del otro, el dato llegará a la interfaz de red del otro equipo, con completa independencia que el equipo destino coincida con los parámetros de destino que envió el emisor. Es decir, que en este caso da igual que el Emisor dijese que dicho paquete estaba destinado a la IP 10.0.0.2, porque al tener ambos una unión física directa, aunque el destino tenga la IP 10.0.0.100 este recibirá el paquete en su interfaz de red. La cuestión es que hace la interfaz de red cuando recibe un paquete que no está designado de forma lógica para él. Y lo habitual es que el adaptador de red mismo simplemente descarte el paquete.

Pues bien, ahora no pensemos en un equipo conectado a otro por un cable, sino una red de 20 equipos, todos ellos conectados mediante un Hub. Los Hub, como se vio en su momento, son meros repetidores, une cada linea de envío de datos de cada hosts conectado a dicho hub, a todas las lineas de recepción de datos de cada uno de los hosts conectados al hub. Es decir, si el equipo 1 envía cualquier dato, con completa independencia de quien sea el destinatario, dicho paquete llegará al 100% de los adaptadores de red de todos los equipos. Dichos adaptadores de red comprobarán entonces el destino de dichos datos, y lo descartarán si no son para ellos. Pero si el adaptador de red nos lo permitiese y el software/driver también, bastaría con dar la orden al adaptador de red que dejase de ignorar el tráfico que no fuese dirigido hacia él, de modo que el capturador de paquetes sería capaz de capturar ya no solo el 100% del tráfico propio, sino el 100% del tráfico de TODA la red. Dicha orden que se le da al sistema se  denomina Modo Promiscuo.

Por suerte, podemos decir que los Hubs pasaron a la historia hace años ya (aun se encuentran en muchos lugares). Recordemos que la forma más habitual de expandir una red es por medios de Hubs y también por medio de conmutadores o Switchs. ¿Que panorama nos encontramos ante redes constituidas por Swichs? En este caso el panorama es muy diferente, los datos son enviados físicamente a sus destinatarios. Es decir, en una red de 20 equipos conectados por medio de un Switch, si el equipo 1 envía un dato al equipo 10, podemos verlo como si el Switch conectase a ambos equipos de forma única, con lo que el resto de equipos jamás sabrán siquiera que el equipo 1 y el 10 están comunicando datos. En este caso el tráfico generado en nuestra red que no esté destinado a nuestro equipo (o no sea procedente de este) quedaría completamente inalcanzable para nosotros… ¿o tal vez podamos hacer algo al respecto? (Lo veremos un poco más adelante)

Dado que los Hubs están a día de hoy en desuso y que aun no vamos a entrar en las opciones de las que disponemos en redes conmutadas (Switchs), ¿que valor puede tener capturar/analizar nuestro propio tráfico? Bueno, del mismo modo que aun cuando nuestro cuerpo es nuestro y sabemos que tenemos sangre, es necesario realizar analíticas de sangre cuando algo no funciona bien en nuestro organismo, o simplemente queremos aprender un poco más de nuesetro metabolismo, funcionamiento… aquí sucede lo mismo. Dado que la mayoría del tráfico generado por nosotros (entrante o saliente) suele ser tráfico HTTP (para Internet), el uso más común quizás sea usar estos analizadores para ver información de interés que de otro modo escaparía a nuestros ojos. Esto lo vimos más o menos cuando hablamos de HTTP Sniffing o HTTP  Headers Sniffing. Evidentemente esto es solo uno de los infinitos usos que puede tener esta técnica. Desde mi punto de vista, es una de las técnicas/herramientas más interesante que existe de cara al aprendizaje, comprensión e incluso defensa dentro de una red, el valor de poder visualizar exactamente cada uno de los paquetes que envía o llega a nuestro PC, no tiene precio: Detección de malware que están enviando datos a host desconocidos, mal funcionamiento de nuestra red, problemas de nuestro router, ataques hacia nuestro PC/red que proviene de nuestra propia red o desde el exterior, estudio/ análisis y/o creación de protocolos de red…

Por desgracia, sería imposible escribir un artículo o un libro con cada uno de los infinitos ejemplos en los cuales un Sniffer no solo es recomendado sino obligado. Aquí, tan solo puedo pretender exponer la idea, su funcionamiento y algunos ejemplos prácticos con la intención de que cada cual que se interese por ello tenga lo suficiente para continuar por ellos mismos.  Para no complicarnos, y dado que el Sniffing puede ser desde  tremendamente complejo (por filtros, análisis…), todos los ejemplos que veremos serán usando Windows 7  y Wireshark 1.4.2, aunque del mismo modo podía haberlo realizado con Linux (que no se enfaden mis amigos Linuxeros).

Por lo general, un Sniffer no es discriminatorio. Es decir, en teoría es capaz de capturar absolutamente TODO lo que circula por el adaptador de red que se esté monitorizando. Somos nosotros como usuarios los que por comodidad indicamos al software que deseamos realmente capturar u observar. Es evidente, generalmente buscamos frames o paquetes concretos, tráfico que nos llega de de un host concreto o el tráfico de un terminado protocolo. Es por ello que cuando se desea estudiar o buscar algún frame o paquete concreto, es bueno intentar evitar el mayor tráfico posible. Wireshark no solo es un mero Sniffer, sino que posee una colección ingente de diseccionadores de protocolos, es decir, una base de datos enorme con la estructura de dichos protocolos. Recordemos que siempre estaremos dentro del modelo OSI/TCPIP, y que este modelo está completamente jerarquizado, en el que un nivel se encapsula dentro de otro para acabar siendo todo un simple flujo de datos. Imaginar por tanto que en el nivel de enlace de datos o nivel físico colocásemos el sniffer, lo que obtendríamos sería los frames que van circulando por él, unos datos estructurados si comprendemos cada uno de los bits de dichos frames o simplemente un conjunto de bits sin significado alguno. Es aquí donde ntra en juego el analizado de paquetes, que es capaz de detectar el inicio de cada frame, y analiza cada uno de ellos desglosándolo en cada uno de sus protocolos. De esta forma, podemos convertir ese amasijo de datos sin sentido en una estructura bastante inteligible y fácil de manejar.

0000 00 25 xx xx xx xx 00 24 xx xx xx xx 08 00 45 00 .%…… ……..
0010 02 b5 33 3d 40 00 80 06 d1 8b c0 a8 xx xx 4a 7d ..3=@… ……J}
0020 e6 52 13 7c 00 50 97 da db af 4b c4 00 72 50 18 .R.|.P.. ..K..rP.
0030 3f c3 f6 21 00 00 47 45 54 20 2f 20 48 54 54 50 ?..!..GE T / HTTP
0040 2f 31 2e 31 0d 0a 48 6f 73 74 3a 20 77 77 77 2e /1.1..Ho st: www.
0050 67 6f 6f 67 6c 65 2e 65 73 0d 0a 55 73 65 72 2d google.e s..User-
0060 41 67 65 6e 74 3a 20 4d 6f 7a 69 6c 6c 61 2f 35 Agent: M ozilla/5
0070 2e 30 20 28 57 69 6e 64 6f 77 73 20 4e 54 20 36 .0 (Wind ows NT 6
0080 2e 31 3b 20 57 4f 57 36 34 3b 20 72 76 3a 32 2e .1; WOW6 4; rv:2.
0090 30 62 39 70 72 65 29 20 47 65 63 6b 6f 2f 32 30 0b9pre)  Gecko/20
00a0 31 30 31 32 31 39 20 46 69 72 65 66 6f 78 2f 34 101219 F irefox/4
00b0 2e 30 62 39 70 72 65 0d 0a 41 63 63 65 70 74 3a .0b9pre. .Accept:
00c0 20 74 65 78 74 2f 68 74 6d 6c 2c 61 70 70 6c 69 text/ht ml,appli
00d0 63 61 74 69 6f 6e 2f 78 68 74 6d 6c 2b 78 6d 6c cation/x html+xml
00e0 2c 61 70 70 6c 69 63 61 74 69 6f 6e 2f 78 6d 6c ,applica tion/xml
00f0 3b 71 3d 30 2e 39 2c 2a 2f 2a 3b 71 3d 30 2e 38 ;q=0.9,* /*;q=0.8

La tabla anterior sería un ejemplo de un frame capturado por un sniffer, en el lado izquierdo la representación hexadecimal y en el derecho una representación ASCII. En este caso sería un frame saliente de nuestro adaptador de red, más exactamente una petición HTTP realizada por el navegador para obtener la página web de www.google.es. Esta es simplemente la función del Sniffer, capturar el frame completo. En cambio, el analizador lo que realiza es diseccionar en partes más pequeñas dicho frame, dando a cada una de ellas un significado propio. Esto como hemos dicho es posible en tanto y cuanto conocemos el funcionamiento del modelo OSI/TCPIP, y sabemos que los datos viajan encapsulados en los distintos niveles OSI/TCPIP, usando diferentes protocolos. A fin de cuentas, el navegador en este caso quien ha realizado la petición, no necesita ni le es útil conocer la MAC de la interfaz del router o la suya propia, así como que le interesa bien poco saber que tipo de protocolos llevarán a acabo su petición. El navegador tan solo renderizará el código HTML que le devuelva el servidor de www.google.es (en este caso), es decir, en realidad lo que le interesa al navegador del frame anterior es el contenido que comienza con «GET /HTTP…» (En la columna del código ASCII) hasta el final.

En cambio, para el analizador tan importante es el protocolo HTTP (que comienza en el punto citado) como el protocolo Ethernet, que comienza justo al principio. Así, el analizador es capaz en la mayoría de las ocasiones de interpretar cada una de las partes del frame y su significado:

-Frame Ethernet: La MAC destino (6 Bytes) y la MAC origen (6 Bytes), seguidos del identificador del protocolo de red que tiene encapsulado (oxo800 = IP)
-Paquete IP: El primer Byte representa la versión de IP (4 = IPv4) y el segundo el número de palabras de 4 bytes (32 bits) de la longitud de la cabecera (5  -> 4*5 = 20 Bytes.  1 Byte para TOS, 2 bytes con la longitud total dele paquete IP (0x02b5 = 693 bytes), 2 para el ID del paquete, otros dos bytes indicadores de fragmentación, el byte TTL y el Byte de protocolo, que como en el frame Ethernet especifica el protocolo superior que encapsula, en este caso el prtocolo de nivel de transporte TCP (0x06 = TCP). Antes de incluir las direcciones IP origen/destino aparecen 2 bytes mas del CRC de la cabecera. Despues de esto se especifica simplemente las direcciones IP, en forma de 4 bytes cada una
-Mensaje TCP: Los primeros Bytes pertenecientes al mensaje TCP (nivel 4 del modelo OSI) serían los Bytes 0x13 y 0x7c, que especifican el puerto de origen, seguidos de otros 2 bytes que especifican el puerto de destino (0x0050 = 80, puerto HTTP). Los 4 siguientes bytes especifican el numero secuencia y los 4 siguientes el numero de ACK. Despues de esto, el nibble 0x5 especifica la longitud de la cabecera, mientras que 0x018 (los 12 bits restantes) se usan para los flag (0x018 = PSH y ACK habilitados). Para terminar 2 Bytes con el tamaño de ventana usado y otros 2 para el CRC. El resto son tan solo 2 Bytes de Padding. Nota: Es muy posible que analizadores como Wireshark verifiquen los CRC pro ellos mismos y los comparen con los obtenidos en la captura. Cuando estos datos no coinciden, suelen marcarse los paquetes (en wireshark) como errores en la verificacion de CRC, no obstante no quiere decir que el paquete efectivamente fuese dañado/modificado. La mayoría del hardware de red moderno realiza en ellos mismos ciertas tareas repetitivas para evitar al sistema tener que realizar ciertos cálculos, agilizando el sistema en gran medida. La verificación de CRC es un ejemplo de ello. El hardware en realidad es quien añade y calcula dicho CRC, no el OS, cno lo que la validación/verificación falla. Si tenemos errores de este tipo, solo decir que son normales, y posiblemente nuestro hardware de red esté mejorando el rendimiento de nuestro sistema gracias a estas tecnologías.
-Datos HTTP: Una vez pasado el nivel de transporte, en este caso pasamos al nivel de presentación, tráfico HTTP puro, que será el que maneje directamente nuestro navegador para solicitar o recibir la información en pantalla. En este caso se comienza con una petición tipo GET y toda la cabecera HTTP de petición, especificando el host destino, el User-Agent…

 

Es por todo esto que cuando se desea usar técnicas como el Sniffing es necesario conocer cuanto más mejor los protocolos que intervienen en ello, como ya pudimos ver en otros capítulos. Es evidente que un análisis manual como el que hemos llevado a cabo es imposible de cara a la realidad, donde pueden capturarse cientos de frames por segundo. Pues bien, Wireshark es el que nos ayuda a ello, de un modo mucho más gráfico y sencillo, a la par que nos permite reensamblar PDUs segmentados, descomprimir el tráfico HTTP, filtrar virtualmente por lo que necesitemos, analizar las pilas de protocolos, estudios estadísticos de los frames…

En tanto y cuando el ejemplo anterior tan solo era una muestra del aspecto de un frame que incluye una petición HTTP (y tampoco con demasiado valor), es muy interesante a la hora de estudiar protocolos y ver la seguridad de muchos de ellos, lo cual puede dar juego a posteriori. Por ejemplo, lo inseguro que puede ser el protocolo SMTP ante el Sniffing. Veamos una «Conversación» de una sesión SMTP (por supuesto sin cifrar, sin usar TLS/SSL o STARTLS):

En este caso, es simple usar WireShark para «limpiar» la «conversación» y mostrar los datos de un modo más intuitivo:

220 smtp140.mail.ukl.yahoo.com ESMTP
ehlo prueba
250-smtp140.mail.ukl.yahoo.com
250-AUTH LOGIN PLAIN XYMCOOKIE
250-PIPELINING
250 8BITMIME
auth login
334 VXNlcm5hbWU6
Y3VlbnRhLnBydWViYUB5bWFpbC5jb20=
334 UGFzc3dvcmQ6
MTIzNDU2
235 OK, go ahead
mail from: <cuenta.prueba@ymail.com>
250 OK , completed
rcpt to: <blog@theliel.es>
250 OK , completed
data
354 Start Mail. End with CRLF.CRLF
from: Prueba <cuenta.prueba@ymail.com>
to: Theliel <blog@theliel.es>
Subject: Asunto prueba
Este correo es un claro ejemplo del deficit de seguridad en el protocolo SMTP sin cifrar

.
250 OK , completed
quit
221 Service Closing transmission

Cuando enviamos un correo electrónico usando SMTP en «plano», es francamente sencillo extraer cualquier tipo de información de él. En este caso se ha usado el método de autentificación «login», que simplemente usa codificación base64 para el nombre de usuario y la contraseña (completamente reversible y simple). Pero aun cuando se usan sistemas de autentificación como CRAM-MD5, continuarían siendo visibles datos evidentemente «comprometidos», como las direcciones de correo origen/destino, el nombre de los usuarios, el asunto… y por supuesto el cuerpo del mensaje. Es evidente que el nombre de usuario y la contraseña son los datos más sensibles. Por supuesto, esto por si solo no tendría mayor importancia dado que solo son datos que salen de nuestro equipo, y evidentemente conocemos dichos datos sin necesidad de un Sniffer. Pero esto lo trataremos más adelante.

Idealmente, cualquier comunicación punto a punto debería de estar cifrada. Es por ello que existen los protocolos de encriptación como TLS/SSL. Su propósito principal es que tan solo los extremos de la comunicación puedan tener acceso a dichos datos, evitando que cualquier «man-in-the-midle» que pueda interceptar una comunicación pueda tener acceso a dichos datos de forma «plana», es decir sin cifrar. Esto evita además, no solo protección ante terceras personas que puedan tener intenciones maliciosas, sino que evita también que nuestros propios ISP o agencias gubernamentales puedan conocer el contenido de la información que estamos transmitiendo. Ojo!! Transmitiendo!! este tipo de protocolos solo garantiza la inviolabilidad de los datos en la transmisión de estos. El destino recibirá dicha transmisión en plano, por así decirlo, su navegador, su gestor de correo, su… mostrará sin problema alguno los datos transmitidos:

Por último, no solo la información en sí es importante, sino su conjunto. La mayoría de los ataques DoS, Escaners de puerto, exploits, envenenamientos… pueden ser detectados por un Sniffer. La gran mayoría de estas técnicas suelen responder a un patrón fácilmente reconocible simplemente explorando un registro de un Sniffer. La gran mayoría de todas las comunicaciones se basan en protocolos bien definidos, lo que hace de estos que sea «fácil» seguir una comunicación entre dos (o más) equipos. Si es una comunicación telnet o HTTP, si es un flujo de datos, si… esto no significa que siempre es posible conocer la finalidad o el objetivo de un frame interceptado, pero muchas veces podemos hacernos una clara idea de ello. En esto juega un gran papel los puertos de conexiones. Por ejemplo, por defecto sabemos que los servidores web usan el puerto 80, o el puerto 25 para servidores SMTP de correo. No quiere decir que todo el tráfico recibido por un equipo remoto por su puerto 80 sea tráfico HTTP, pero desde luego siempre será la primera opción a pensar. Pues bien, del mismo modo que los diferentes servicios que existen suelen estar asociados a uno o varios puertos conocidos, la mayoría de los «ataques» informáticos también pueden llamar la atención. Es aquí donde los analizadores de paquetes juegan un papel muy importante en, nunca mejor dicho, analizar dicha información. Por supuesto, será el usuario final siempre el que tenga que interpretar dichos frames y su posible significado:

La imagen anterior sería el resultado de colocar un Sniffer en nuestro router ante un simple escaner de puertos un tanto «ruidoso», en la que «Lilith» (el router en cuestión) respondería con un mensaje TCP  con el flag RST a todos los mensajes SYN (uno a cada puerto escaneado) que el equipo «Theliel» está enviando. Todo deja huella, y cuanto más se aleje de un comportamiento «normal», más ruido. Generalmente, cualquier Hacker o usuario malicioso que quiera efectuar un ataque informático quiere pasar completamente desapercibido, lo cual convierte el anonimato y el silencio en una de las primeras prioridades. Un escaner de puertos como el mostrado anteriormente es muy ruidoso, evidentemente hay formas mucho menos ruidosas de hacerlo. Este papel lo conocen bien los administradores de redes, no todo es un DoS, ni todas las conexiones esporádicas son accidentales.

 

El análisis o estudio estadístico del tráfico por la red sería demasiado extenso como para dedicarle unas pocas líneas, así que nos quedaremos (estudiaremos) tan solo aquel tráfico que pueda ser interesante para nosotros desde un punto de vista más directo, es decir, aquel tráfico que expone directamente datos que podríamos considerar delicados para los usuarios: Nombres de usuario, Contraseñas, números de tarjetas de créditos… pero los Sniffers no solo son capaces de interceptar el tráfico saliente, sino también el entrante. Generalmente, dicho tráfico no está pensado para que sea manejado directamente por nadie, suelen ser datos solicitados por el navegador, o por ejemplo un correo electrónico entrante que descarga un gestor de correos. Pero del mismo modo que se puede capturar el tráfico, podríamos pensar que podríamos interceptarlo y modificarlo al vuelo.

 

 

Modificando el tráfico de la red

Capturar el tráfico puede ser un gran problema de seguridad cuando no existen mecanismos de cifrado que lo protejan, pero tanto o más peligroso es la posibilidad de poder alterar dichos datos. La teoría es simple, si un Sniffer nos permite de algún modo interceptar tráfico en la red, podríamos también alterar dichos datos. Esto suele ser muy útil, particularmente para dos labores: Engañar un software cliente/servidor con datos no legítimos para lograr un comportamiento diferente al esperado a tener y también de cara a minimizar los fallos de seguridad de un software cliente/servidor. Muchas veces un software se crea con el pensamiento de que todo funcionará siempre en un entorno ideal. Un programa servidor podría estar preparado para contestar siempre en función de unas preguntas preestablecidas por un programa cliente. Dado que el programa cliente se crea conjuntamente con el programa servidor, podría caber pensar que el servidor no sería falta programarlo para casos que no se contemplan en el programa cliente. No obstante, comprobar el comportamiento de un software ante cualquier situación debe de ser algo primordial, no solo ceñirse a meras condiciones ideales, ya que a fin de cuenta un atacante es más que posible que use todo tipo de técnicas, aunque sea generar un tráfico que jamás podría generar una aplicación cliente. Es aquí donde suelen nacer la mayoría de los Exploits, programas que generan cadenas de Bytes a conciencia que aprovechan fallos de seguridad de un software objetivo que no estaba diseñado para tal efecto.

De todos modos, la inyección de tráfico es diferente a la modificación del tráfico, que es donde nos vamos a centrar. La gran mayoría de todo el tráfico que existe a día de hoy es tráfico HTTP, páginas web que se envían y solicitan. Incluso ¿la mayoría? de las aplicaciones que requieren de acceso a la red usan peticiones HTTP para comunicarse con los servicios externos. Esto convierte la modificación del tráfico de red en un juego de niños. Aun cuando el tráfico que se quiera modificar no proceda de protocolos bien conocidos, tampoco es una imposibilidad el poder jugar con ellos y modificarlos a voluntad con las herramientas adecuadas. Por ello, vamos a ver lo simple que puede resultar realizar esta operación por medio de un servidor proxy local que interceptará todo el tráfico HTTP, y por medio de unos simples filtros lo modificará. Un servidor Proxy no es exactamente un Sniffer, sino un software que recibe/envía cierto tráfico a través de él, generalmente para filtrar, controlar o modificar pequeños aspectos de este tráfico. Por ello, es una gran herramienta a la hora de probar el comportamiento HTTP de ciertos programas, como navegadores o servidores de aplicaciones web. Estos servidores proxys no capturan frames, ojo!! por lo general tan solo los datos enviados y recibidos desde el nivel de aplicación.

 

En esta ocasión he optado por un ejercicio práctico, que bien podría ser objeto de un artículo independiente de como «piratear» (no me gusta nada dicha palabra) la aplicación en cuestión.

Hay un juego Online relativamente conocido llamado «Ogame«. Es un juego online PHP, que la verdad no nos interesa en absoluto para el objetivo de este pequeño ejercicio práctico. Como todo buen juego online conocido, hay ingeniosos programadores que crean bots (programas que automatizan ciertas tareas del juego) para hacer «trampas» en estos. Lo cierto es que la gran mayoría de todos los Bots que existen para juegos online suelen ser gratuitos, pero la aplicación que vamos a tratar (que no es más que un bot para Ogame) es Shareware, y tan solo nos permite un tiempo limitado de uso sino se compra. La aplicación en este caso es: «Ogame Automizer».

Aunque sea algo que ya conozca la mayoría de mis lectores, mi intención no es que aparezcan ahora oleadas de tramposos en Ogame, ni mucho menos boicotear la aplicación en cuestión para que pueda usarse sin pagar por ella. Es más, una vez termine la publicación de este artículo, como es costumbre, enviaré un aviso al desarrollador para que sea consciente del fallo de seguridad de su software. He optado por esta aplicación en particular porque muestra perfectamente la importancia de un Sniffer y la modificación del tráfico de red incluso cuando este se genera por nuestro propio equipo, así como la versatilidad e importancia de un servidor Proxy.

Antes de nada, hay por supuesto que comprender le funcionamiento de registro de este programa. Es simple. Si no se registra, el programa permite un tiempo de 1 hora y 30 minutos de forma autónoma, tras dicho tiempo es necesario hacer clic en un botón o el programa no funcionará. Después de presionarlo estará activo de nuevo por el mismo tiempo, así indefinidamente. Es evidente que esto no es viable para un Bot que precisamente puede ser usado para dejarlo activo durante horas o incluso dias de forma completamente autónoma, no tener que «reactivarlo» cada 1 o 2 horas. No obstante, cualquiera puede realizar un registro gratuito que incluye un serial trial que permite el uso del programa por 4-5 días completos, después de dicho tiempo se volverá al estado inicial, con la imposibilidad de poder solicitar un nuevo serial trial, dado que estos serial se asocian al propio nombre de usuario de OGame, con lo que tan solo se permite un serial trial por jugador de OGame.

¿Como podemos estudiar el comportamiento de la aplicación? Bueno, aquí tratamos con Sniffers, así que no hay mejor sistema para investigar el sistema que usa que un Sniffer. Ni que decir tiene que el sistema de verificación del número de serie y el tiempo de activación de dicho número de serie se realiza a través de la red, con lo que colocar un Sniffer a OGame Automizer sería a priori la mejor forma de comprender el sistema de verificación de este programa. Por supuesto, en este punto no podemos saber si la comunicación se realizaría de forma cifrada, o si posee algún sistema mixto, es por ello que como se dijo mucho antes, casi siempre todo comienza analizando el tráfico de red. Si aislásemos el tráfico generado por OA (OGame Automizer a partir de ahora), veríamos que cada X, la aplicación enviaba una petición HTTP con unos datos más que interesantes, y que el servidor respondía con datos igualmente interesantes:

Si extraemos de ahí el paquete 56, tendríamos la madre del cordero:

GET /public.php?action=expire&uni=xxx.ogame.com.es&login=AlmasOscura&serial=xxxxxxxxx HTTP/1.1
Host: 188.165.227.218
User-Agent:Mozilla/5.0 (Windows NT 6.1; x64; rv:2.0b9pre)
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Accept-Language: en-us;q=0.5,en;q=0.3
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: Keep-Alive

HTTP/1.1 200 OK
Date: Fri, 19 Nov 2010 02:51:58 GMT
Server: Apache/2.2.14 (Ubuntu)
Vary: Accept-Encoding
Content-Length: 11
Keep-Alive: timeout=10, max=32
Connection: Keep-Alive
Content-Type: text/html

……72482

La primera parte corresponde a la petición HTTP que realiza la aplicación al servidor de OA, mientras que la segunda parte corresponde a la respuesta por parte de este, y que será procesada por la aplicación. Es evidente por tanto como se realiza la verificación. Cada X segundos la aplicación realiza una petición al servidor de OA, en la que incluye lo que desea hacer (action=expire), el servidor de OGame en el que está activo dicho jugador (uni=xxx.ogame.com.es), el nombre de usuario (login=AlmaOscura) y el serial que está usando dicho usuario para la aplicación OA (serial=xxxxxxx). Es decir, la aplicación envía al servidor de OA todos los datos necesarios para que este pueda verificar el estado de dicho número de serie asociado a dicho usuario en dicho universo OGame.

La segunda parte es la respuesta del servidor, una vez recoge los datos de la petición envía de vuelta los datos del estado de la verificación de la cuenta. En este caso simplemente responde con «…….72482» (el resto es la cabecera de respuesta del servidor). Bueno, no hay que ser un lince para deducir que dicho número es el período en segundos del que aun disponemos para poder usar OA. En este caso 72482 segundos es algo más de 20 horas, que podemos verificar perfectamente si mirásemos el número de horas y minutos que la aplicación OA nos dice… y por supuesto coincide.

Llegados a este punto todo es relativamente sencillo. El sistema de verificación de OA se basa en peticiones regulares en las que el servidor de OA indica el número de segundos que restan, y se usa como sistema de sincronización, dado que el contador disminuye constantemente (es controlado por la aplicación), pero es siempre el valor devuelto por el servidor el que prima. Si este es el único sistema de verificación/activación, es tan simple como modificar el valor devuelto por el servidor a uno que sea constante (mayor o menor), de forma que cada vez que la aplicación sincronizase con el servidor (cosa como hemos dicho bastante regular y cada pocos segundos/minutos), de cara a la aplicación OA el servidor siempre le respondiese con el mismo valor, con lo que aun cuando la cuenta de la aplicación fuese inferior, esta se restablecería a nuestro valor falso, y tendríamos OA indefinidamente.

Este comportamiento se podría comprobar de forma simple con alguna aplicación que actuase de proxy que permitiese interceptar peticiones HTTP y editarlas, quizás el software más famoso en su época fue «Achilles», aplicación que siempre tendrá un pequeño hueco en mi corazón. Pero en realidad cualquier servidor proxy que permita crear una simple respuesta HTTP sería suficiente. En mi caso ha sido Paros Proxy, una aplicación ya antigua, pero que siempre me ha gustado por lo bien orientada que estaba.  Sería cuestión de forzar una solicitud HTTP de verificación de OA, interceptar la respuesta del servidor y simplemente cambiar el valor devuelto por el servidor por otro a nuestro antojo, inmediatamente comprobaríamos que el tiempo de activación de OA era correctamente actualizado. En la imagen se muestra como realizar la petición forzada, no la modificación. Para permitir la modificación, OA tendría que estar configurado para pasar todo a través de un proxy local, y en Paros activar la interceptación de tráfico entrante:

Aquí, el servidor nos devuelve algo diferente, y es debido a que los datos introducidos al realizar la petición corresponden a unos datos cuya cuenta hace ya mucho que dejó de estar activa, de ahí el mensaje de «expire», seguido del número en segundos que hace que expiró. Esto es interesante también, pues será algo que será usado un poco más adelante para facilitar la creación de un filtro. También muestra lo simple que resulta crear peticiones HTTP creadas a mano a un servidor cualquiera, y por supuesto ver su respuesta, lo cual resulta tremendamente útil.

Evidentemente dicho procedimiento sería inviable, dado que la verificación se realiza de forma regular. Esto implica que sería necesario crear un filtro que fuese capaz de reconocer las peticiones realizadas o recibidas por OA y modificarlas al vuelo. Y para esto sin duda alguna es mucho mejor el uso de un servidor Proxy decente, como pueda ser Squid, el mismo Apache o, en este caso concreto, Privoxy. Personalmente creo que es más fácil manejar privoxy a la hora de crear filtros específicos, que es lo único que tendremos que hacer. Privoxy puede modificar cualquier contenido al vuelo en función de un patrón definidos, de forma global o incluso tan solo en determinados hosts. En este caso lo más simple sería tomar de patrón «expired», y configurar Privoxy para que modifique dicha cadena al número de segundos que deseamos, por ejemplo 64000 segundos.

La única pega que quedaría sería el problema de la compresión HTTP. Prácticamente cualquier servidor HTTP y cualquier aplicación/navegador solicita el contenido comprimido para ahorrar ancho de banda, lo cual suele ser tremendamente efectivo, ya que la gran mayoría de todo el tráfico HTTP es texto plano, y por ende altamente comprimible. Privoxy no podrá reconocer ningún patrón que venga de contenido comprimido, con lo que también habría que instruir a Privoxy para que, o se comunique con el exterior siempre sin usar compresión, o configurando/compilar Privoxy con soporte para ello, con lo que privoxy realizaría la descompresión y compresión del contenido. Todo ello no obstante es muy simple, tan solo hay que configurar correctamente Privoxy:

Por un lado que el filtro tan solo sea efectivo para el servidor de OA y que dicho contenido vaya siempre sin comprimir (Archivo User.action):

{ +prevent-compression }
188.165.227.218

{ +filter{OA} }
188.165.227.218

Por otro lado el filtro que realiza la modificación al vuelo (Archivo User.Filter):

FILTER: OA Modificar la cadena «expired» por «999999»
s/expired.*/999999/

En realidad dicho filtro no solo modifica la cadena expired, sino la cadena expired y todos los caracteres siguientes hasta encontrar un retorno, es decir, modificaría toda la linea por el valor deseado. Con tan solo esas líneas, privoxy sería capaz de modificar al vuelo las peticiones de verificación de OA, haciendo que dicha aplicación estuviese indefinidamente activada, siempre y cuando OA pasase el tráfico a privoxy, evidentemente, y que en este caso la expiración hubiese ocurrido ya, de lo contrario sería necesario modificar el patrón del filtro.

Es normal que los programadores no sean expertos en seguridad, lo cual influye sobre todo en el software creado por programadores independientes que no tienen un gran soporte de una empresa por encima con un buen control de calidad. La solución no solo pasa por usar sistemas seguros como TLS o SSL, sino que independientemente de estos las mismas aplicaciones tendrían que cifrar el contenido ellas mismas, de modo que la información desde que saliese de la aplicación hasta que llegase fuese siempre completamente indescifrable, y digo esto porque aun usando protocolos como TLS o SSL se podrían crear en los servidores proxys soporte para ello, con lo que la aplicación continuaría comunicándose de forma no cifrada con este, y en consiguiente contenido fácil de leer y modificar.

Evidentemente esto no es más que una aplicación simple que tan solo podría tener alguna utilidad para algunos tramposos, pero esto mismo expuesto es aplicable a una gran cantidad de aplicaciones existentes que son vulnerables a todo este tipo de ataques, que no dejan de ser básicamente pequeños Hacks, aunque yo prefiero llamarlo simplemente agujero de seguridad.

 

 

Envenenamientos

Hasta donde hemos visto, el Sniffing es una gran herramienta, pero tiene barreras que no puede sortear. Es evidente que es muy útil poder capturar o analizar todo el tráfico saliente o entrante de nuestro propio equipo, pero seamos sinceros… lo ideal sería poder realizar lo mismo en toda nuestra red. Esto dijimos que era posible siempre y cuando nuestra red estuviese constituida por un Hub, o evidentemente si colocásemos un Sniffer en el router mismo, lo que nos permitiría conocer todo el tráfico saliente o entrante de este (no entre los propios equipos). Es evidente que un administrador de red tendrá acceso a toda la infraestructura de esta, y lo más posible es que tenga acceso directo a todo el tráfico por medio de los puertos especiales llamados «Mirror» (Espejo), que permiten conectar un equipo a él y poder monitorizar todo el tráfico. Ni que decir tiene el poder que otorga un puerto espejo en un switch de una red, imaginar todo lo explicado anteriormente pero no limitado tan solo a nuestro equipo, sino a TODOS los equipos conectados a la red, imaginar una empresa o una universidad, la cantidad de información sensible a la que se podría tener acceso.

Evidentemente los usuarios maliciosos, atacantes, hackers… no suelen tener acceso a estos puertos especiales, ni tampoco un acceso directo a un router ajeno. Pero como ya hemos dicho muchas veces, Internet no se creó desde un principio con la seguridad en mente, sino en su versatilidad y potencial. Prácticamente todos los protocolos de Internet están basados en estas premisas, lo que ha producido que con los años se descubran importantes problemas de seguridad en ellos. No obstante, esto no implica que dichos protocolos sean un error, gracias a la simpleza de estos, Internet es ha día de hoy lo que es, digamos que hemos tenido que pagar un precio en cuanto a seguridad se refiere por entornos mucho más libres, fluidos…

 

El término «Envenenamiento» proviene del acto de manipular una caché concreta de forma que los datos añadidos/modificados aparenten ser legítimos. ¿Caché? En informática es muy común el uso de memorias caché que almacenan de forma temporal aquellos datos que son usados de forma más frecuente. Por ejemplo, un servidor Proxy caché, almacenará en dicho caché las páginas web más visitadas, con el objeto de si se solicita dicha web el servidor proxy sirve de manera inmediata dicha web, sin necesidad de realizar una petición al servidor original. Por ello, las caché suelen ser efectivas para datos que no se actualizan de forma muy regular, o mejor dicho, que la frecuencia en la que dichos datos son necesitados es muy superior al tiempo en el que dichos datos necesitan actualizarse.El objetivo de una caché es evidente, acelerar en mucho la velocidad de un sistema, en concreto el acceso a los datos que se están cacheando.

Pero hay un problema. Por definición, un dato almacenado en una caché no tiene por qué estar actualizado. Aquellos datos que son relativamente constantes no es un problema, cuando el dato necesita actualizarse se actualiza y listo. El problema es que no siempre hay un sistema que dice cuando el dato está actualizado o no. Volviendo al ejemplo de una caché de un servidor proxy, imaginar que el servidor proxy almacena en caché la web de google.es, de tal forma que cada vez que cualquiera de los 300 equipos conectados a dicha red quiere acceder a googole.es el servidor web la sirve sin necesidad de realizar una petición a google.es por cada equipo que quiera acceder a ella. Pues bien, si el caché tiene por ejemplo un tiempo de vida de 24 horas y Google cambia la portada de su página, todos los equipos continuarán accediendo hasta el fin de esas 24 horas a una versión antigua de google.es. Evidentemente esto puede no ser importante, o por el contrario tener una gran importancia. Normalmente este tipo de problemas se soluciona disminuyendo el tiempo de permanencia de los datos en las caché en relación con el tiempo que podría tener validez dichos datos. En el caso del servidor proxy, lo normal es que Google modifique su web a lo mejor de mes en mes, con lo que tener configurado en el servidor proxy un tiempo de vida de dichos datos para 24 horas sería suficiente para tener un sistema eficiente.

¿Como nos afecta esto? Bueno, tenemos caché prácticamente en cualquier aplicación, registros, protocolos… pero aquí vamos a citar dos en especial, por tener relación directa con el Sniffing:

  • Caché ARP
  • Caché DNS

 

Envenenamiento ARP

El protocolo ARP fue explicado en su momento. Resumiendo, el protocolo ARP es el responsable de que un sistema pueda conocer la dirección física de otro por medio de su IP, o al revés, conocer la IP de un sistema por medio de su dirección física. Recordemos que el nivel en el cual se usa IP es el nivel de red, nivel 3, pero por debajo de este es necesario conocer las direcciones físicas (Direcciones MAC). La asociación IP-MAC es mucho más estrecha de lo que uno pueda imaginarse, en realidad usamos direcciones IP por una cuestión de simplicidad y facilidad de uso, pero en última instancia, los datos son enviados por las interfaces de red a otras interfaces de red.

Recordemos que cuando un equipo se conecta a la Red generalmente se anuncia, para indicar a los equipos vecinos que existe. Aun cuando esto no se realiza, cuando cualquier equipo quiere comunicarse con otro equipo vecino, debe conocer su dirección Física, no solo su dirección IP. Si no la conoce, tendrá que preguntar a la red que dirección física tiene, para así poder comunicarse con él. Esto se realizaba gracias al protocolo ARP.

La caché ARP por tanto almacena en cada PC (o sistema) una tabla con la asociación IP <-> MAC de cada equipo conocido, cuando el equipo encuentra una nueva asociación o una actualización de uno de ellos, modifica dicha tabla para actualizar sus datos. ¿Por qué es necesaria dicha caché? En realidad no es necesaria, pero ahorra una cantidad más que importante de ancho de banda!! sin dicha caché, cada vez que nuestro PC quisiese comunicarse con cualquier otro equipo (incluyendo el propio router) tendría que realizar antes una petición ARP para conocer la dirección física de dicho dispositivo y esperar por supuesto la contestación de este. Evidentemente esto sería impensable. Por lo general, las asociaciones IP <-> MAC suele ser suficientemente constante, a veces constante hasta que los equipos se reinician o temporal en caso de que la asignación de IP a los equipos tengan tiempos de leasse relativamente pequeños. La realidad es que en redes pequeñas como las domésticas, estos datos pueden ser constante durante días, mientras que en redes empresariales, universitarias… estos datos pueden tener una constancia mucho menor, normalmente la duración de la sesión. Aun así, si en una sesión se envían cientos de miles de paquetes o conexiones, es más que necesario el uso de una caché ARP.

Es evidente que aun así, debe de existir un sistema de actualización de dichas caché, ya que las mismas IPs se reutilizan para diferentes equipos, sobre todo en entornos en los que estas son asignadas de forma dinámica por sistemas como DHCP. Es por ello que las caché ARP pese a todo suelen usarse, y suelen siendo modificadas de forma dinámica según el propio protocolo ARP, lo cual nos hace ver la verdadera utilidad de un envenenamiento ARP.

ARP es un protocolo simple, que es usado de forma natural en cualquier red. En un buen uso de este, las tablas ARP de todos los dispositivos se van actualizando mientras que las peticiones ARP lanzadas a toda la red van llegando. Por ejemplo, si un dispositivo pregunta por medio de ARP una dirección física, en la misma pregunta especificará su propia IP y MAC, con la idea de que se conteste a dicho equipo. Pero esto puede ser usado de forma maligna para engañar a las caché ARP de los otros equipos. Básicamente se trata de lograr que los equipos vecinos tengan en sus cachés ARP datos incorrectos. ¿Que pasaría si un equipo tuviese en su caché ARP la dirección física asociada al router modificada por la dirección física de un atacante? Que cada vez que la victima quisiese comunicarse con el router, este sin saberlo estaría enviando los datos al atacante, y este por tanto podría interceptarlos por medio de un Sniffer.

Un ataque completo de envenenamiento ARP suele componerse de dos partes. La primera en lograr alterar la caché ARP de una puerta de enlace (o router) para colocar la dirección física del atacante asociada a la dirección IP de la víctima, la segunda en alterar la caché ARP de la víctima para colocar la dirección fisica del atacante asociada a la dirección IP del router. De esta forma, cada vez que el router quiera enviar cualquier dato a la víctica, este será pasado al atacante, y del mismo modo cada vez que la víctima quiera comunicarse con el exterior, pasará ante los datos por el atacante. El atacante ahora tan solo tiene que ser capaz de enrutar los datos para que los paquetes enviados por la víctima crucen el atacante y este los reenvíe al router, y lo mismo para el proceso de recepción. Esta imagen ilustra mejor el proceso:

En una situación de pre envenenamiento, los equipos hacen uso de su caché sin alterar para conocer las direcciones físicas a las cuales dirigirse. Si en ese momento un atacante (el host 192.168.0.10) quisiese comenzar un ataque de envenenamiento, enviaría un frame ARP hacia la MAC e IP del router, pero especificando en el payload ARP que él mismo (el atacante) posee la IP 192.168.0.15 (la IP del host a atacar), en vez de su IP real 192.168.0.10. Con esto provoca que la caché ARP del router actualice la dirección MAC asociada a la IP 192.168.0.15. El mismo proceso se realizará pero hacia el host atacado, en este caso el atacante enviaría un frame ARP especificando en el payload de este que el atacante posee la IP del router, actualizando así en la caché ARP de la víctima la dirección MAC asociada a la IP del router. Una vez las dos caché han sido envenenadas, la víctima cada vez que envíe un paquete a la dirección IP de la puerta de enlace (el router, 192.168.0.1) lo estará enviando sin saberlo al atacante, dado que su equipo la dirección física que tiene asociada a dicha IP es la dirección física de este (el atacante). El atacante a su vez recibirá el paquete de la mano de la víctima, y para evitar cortar la comunicación entre la víctima y el servidor remoto, reenviaría dicho paquete a la puerta de enlace, y de ahí a Internet. Cuando cualquier paquete con destino a la víctima alcanzase el router, este lo enviaría al atacante dado que la dirección física asociada a la IP de la víctima desde el punto de vista del router es el atacante, por tener su caché envenenada. La siguiente imagen ilustra el estado de las caché y del éxito del envenenamiento:

Cual es la utilidad del envenenamiento ARP? pues que el atacante logra que todo el tráfico desde y para la o las víctimas circule por él, y por tanto podrá usar un Sniffer para capturar todo su tráfico, exponiendo cualquier dato sensible que este intercambiando la víctima y no esté siendo cifrado. Todo ello sin que la víctima sea consciente de nada. Evidentemente hay medidas para evitar los envenenamientos, como por ejemplo usar en los routers tablas ARP estáticas (aunque suelen dar problemas) o tener un software que monitorice la red y ante la sospecha de un ataque de envenenamiento ARP actúe o desconectando al equipo sospechoso, ignorando los frames ARP que vengan de la MAC sospechosa, actualizando la caché ARP interna… los ataques de envenenamiento ARP suelen ser ruidosos, con lo que también suelen ser fácilmente reconocibles y usar contramedidas, las cuales también pueden ser fácilmente sorteadas por un atacante.

¿Conclusión? Una regla de Oro muy simple, si te encuentras en una red pública o que no puedes controlar, jamás enviar a dicha red ningún dato que pueda ser sensible a menos que se tenga la certeza de que la conexión se realiza de forma segura, y aun así, se debe de tener cuidado! No nos gustaría que un usuario malicioso estuviese viendo cualquier conversación vía mensajería instantánea, correos electrónicos, videoconferencias… no hay límites.

 

Envenenamiento DNS

Si bien el envenenamiento DNS no posee una relación directa con el Sniffing, es buena idea añadirlo aquí, como segundo envenenamiento de caché conocido. El envenenamiento de DNS suele tener una relación más directa con el Spoofing, dado que por regla general su objetivo no es otro que redirigir las peticiones de una web hacia otra.

Aunque los equipos poseen también una caché DNS, al igual que poseían una caché ARP, no nos referimos generalmente al envenenamiento de DNS como el envenenamiento de esta caché, lo cual sería generalmente conocido como un envenenamiento de caché DNS por ARP (que también es posible realizar). Al igual que la mayoría de todos los protocolos en los que se basa internet. el protocolo DNS es abierto y tiene un ámbito global, lo cual implica que en teoría cualquiera puede montar un servidor DNS completamente funcional y sincronizado con otros servidores DNS. Cualquier servidor DNS suele tener una caché temporal que almacena las peticiones más recientes de DNS para evitar en la medida de lo posible la recursividad, y así evitar un importante ancho de banda.

Al igual que el protocolo ARP, el protocolo DNS permite la sincronización/actualización de los datos de su caché. De nuevo, en un mundo ideal, tan solo los servidores DNS legítimos tendrían que poder realizar dichas actualizaciones (por así decirlo), pero la vida real es bien diferente. Por tanto, un atacante que tuviese un servidor DNS colocado para tal efecto podría intentar enviar peticiones de actualizaciones a un segundo servidor DNS víctima. Si este no tuviese los protocolos y mecanismos adecuados para autentificar dichas peticiones, vería como su caché sería modificada, provocando que supuestos los nombres de dominio deseado apuntasen a direcciones IP bien diferentes. ¿Qué utilidad? Pues bien, dado que los usuarios suelen depender de los servidores DNS, si nuestro servidor DNS estuviese envenenado por un atacante, podría darse el caso que cuando quisiésemos acceder por ejemplo al servidor de google para google.es (que legítima mente tiene la IP 74.125.230.81), nuestro servidor DNS nos devolvería una IP falsa, lo que haría que nuestro navegador aun cuando pusiese que la web visitada era google.es no estaría enviando a cualquier otra web, archivo… o lo que fuese. Esta técnica es tremendamente útil a la hora de realizar por ejemplo ataques de Phishing

Estos ataques suelen tener una importancia en mayúscula por muchos motivos. Para empezar, envenenar un solo servidor DNS (el de un ISP, una empresa, un partícular…) puede afectar a su vez a decenas, cientos, miles… de usuarios!! En segundo lugar, y no menos importante,  al usuario le sería imposible saber que está pasando, a menos que usase un servidor DNS diferente al que está envenenado, ya que desde su punto de vista todo ha sido normal.  Por suerte, este tipo de ataques suelen ser bastante sofisticados y cada día más difíciles de llevar a cabo, sobre todo ahora que se está comenzando la implementación de DNSSec de forma masiva en la mayoría de servidores DNS, añadiendo un método eficaz de autentificación entre servidores DNS.

 

 

Certificados y Túneles

El Sniffing nos permite capturar y analizar todo el tráfico de nuestro sistema, mientras que los envenenamientos nos permiten aplicar el Sniffing a redes completas. ¿Que nos queda por tanto? Para evitar cualquier tipo de escucha, lo ideal sería siempre que todo el tráfico enviado de punto a punto fuese cifrado. El problema es que prácticamente todos los sistemas de cifrado punto a punto que existen suelen basarse en algún momento del intercambio de certificados o claves a través de la misma red.

En su momento, cuando se trató el cifrado asimétrico y los protocolos SSL/TLS todo parecía que era perfecto. Estos sistemas nos daban los métodos adecuados y aparentemente perfectos para poder transmitir y recibir información de forma completamente segura. No obstante, cuando se indaga un poco más adentro, vemos que en realidad cualquier sistema por seguro que sea siempre tiene puntos por los cuales se puede echar a perder dicha seguridad. Los métodos de seguridad que existen son únicamente seguro siempre y cuando tanto el usuario como el entorno que le rodea es seguro. Dicho de otro modo, una contraseña puede ser un sistema sencillo y eficaz para proteger algo, pero si el usuario usa de contraseña su propio nombre, habría sinceramente que detenerse a pensar si el método de proteger algo por contraseña es realmente inseguro o es el usuario el único responsable del fallo de este sistema. Con los años te das cuenta que la tecnología en la medida que puede intenta tapar dichas «torpezas» de los usuarios, pero por mucho que esta avance y por mucho que se le ponga fácil al usuario, este siempre tiene la última palabra sobre si un sistema es seguro o no lo es.

El caso de TLS/SSL es lo mismo. Recordemos por encima y de forma rápida, que cuando un equipo realiza una conexión segura entre este y un servidor remoto, lo que sucede básicamente es que el usuario solicita una conexión segura, el servidor le envía su certificado público, el usuario verifica dicho certificado y cifra una key con dicho certificado (que posee la clave pública), el servidor recibe el mensaje y lo descifra con el certificado privado y la comunicación se realiza con la key escogida/generada por el cliente. Este esquema parece perfecto, una vez el canal se ha asegurado todo parece perfecto, y puede ser cierto… ¿Pero que pasa si el canal aun no se ha establecido? Este procedimiento es eficaz siempre y cuando se de por sabido que el certificado del servidor al cliente es válido y legítimo!! Evidentemente el cliente puede y tiene la obligación de verificar la validez del certificado del emisor, pero el hacerlo o no hacerlo, o como actuar cuando el certificado no es válido es otro cantar.

El problema de una sesión SSL/TLS es el mismo que se ha visto en el envenenamiento ARP. Ante un posible ataque de man-in-the-middle, el usuario creería siempre que está comunicándose directamente con el equipo remoto, y este a su vez con la víctima, pero podría suceder que entre la comunicación de ambos existiese un tercero, un atacante que estuviese interceptando todo el tráfico enviado por la víctima y el tráfico originado por el servidor remoto hacia la víctima. Ante esta situación, el atacante podría estar realizando una conexión segura TLS/SSL con el servidor remoto, a la par de intentar engañar a la víctima con que su sesión SSL/TLS es genuina:

No obstante, hacer pasar por válido un certificado que no lo es, no es algo tan fácil, y depende en gran medida de la víctima. La veracidad o genuicidad de un certificado digital se basa principalmente en la cadena de verdad, en la que un certificado es firmado por una autoridad certificador en la que el cliente confía. En realidad, cualquier certificado puede autofirmarse a sí mismo, cualquiera puede emitir un certificado raiz con el que dar supuesta validad a otro certificado, el único problema siempre es el mismo, que el cliente tenga en su lista dicha entidad raiz o certificadora como legítima o adecuada. Todo esto se traduce en que (y todos lo hemos visto alguna vez) puede llegar a nuestro equipo un certificado que dice ser incorrecto. Generalmente esto suele indicar o que el certificado está caducado o lo más normal, que la entidad que lo firmó no consta en la base de datos de nuestro navegador o gestor de correo o almacén de certificados… como una entidad segura, y por ello el aviso. ¿Que sucede? Que la base de datos de nuestro almacén de certificados no tiene por qué ser ni mucho menos completa.

El ejemplo más sencillo a esto es aquí en España los certificados usados por la administración pública. Dichos certificados suelen estar validados (es decir, la entidad certificadora) por la policía o la casa de moneda y timbre (la FNMT, fábrica nacional de moneda y timbre), incluido nuestro DNIe. El problema es que por defecto, las bases de datos de nuestros navegadores o equipos no tienen incluída dichas CA como entidades legítimas, lo que produce que si visitamos cualquier site que use un certificado legítimo emitido por una de estas entidades, nuestro navegador podría desde rechazar la conexión, tan solo advertirnos o por supuesto también permitir la conexión aunque el certificado no sea válido desde el punto de vista de nuestro equipo, navegador, gestor de correo… Es decir, que nuestro equipo en algún momento nos advierta de que el certificado no es válido o que supone un riesgo no tiene por qué ser cierto tampoco.

En el caso que nos ocupa, es exactamente lo mismo. El atacante podría crear un certificado propio, incluso estableciendo en él los supuestos datos del servidor al que la víctima quiere tener acceso pero firmado por sí mismo o cualquier otro «truco». Llegado este momento, las consecuencias dependen de muchos factores, desde la configuración del equipo de la víctima, del programa que esté creando la conexión segura y por supuesto del usuario que hay detrás de la máquina de la víctima:

-Si el programa que está creando la sesión en el equipo de la víctima no impide por defecto la comunicación, el cliente puede no darse cuenta nunca de lo que está sucediendo. Este sistema sería muy inseguro, pero por otro lado el usuario no tendría que tratar con la incomodidad de toparse con CA que simplemente no tiene instalados.
-El programa que está creando la sesión puede estar configurado por defecto y sin advertir de denegar cualquier comunicación que él crea incorrecta, lo cual sería un sistema muy seguro pero tendría el problema de que muchas conexiones legítimas se impedirían, sin que el usuario fuese consciente de ello, para él simplemente no podría conectarse.
-El programa podría tener una política mixta, denegar o aceptar por defecto la conexión pero informando en tiempo real de ello al usuario, ofreciéndole la opción contraria si así lo desease. Este sería el sistema desde mi punto de vista más seguro, el problema es que muchos usuarios al acceder a una web legítima que requiera de un certificado cucha CA no se encuentra en el programa del cliente, se asustarían y no sabrían que está sucediendo, con lo que el aviso les haría cerrar la sesión por precaución, simplemente por desconocimiento de que implica dicha advertencia.

De nuevo, es aquí donde el usuario siempre juega un papel importante. Hasta que punto la víctima está preparada ante la posibilidad de un certificado falso, como actuaría. Lo aceptaría por defecto? Tendría medio y cancelaría ante una alerta? Usaría software que le advierta de los peligros o usará software que simplemente aceptará? Todo lo que dependa exclusivamente del usuario no hay respuestas, pero por suerte o desgracia de los atacantes (siempre he creído que el término Hacker es complicado de acuñar) suelen hacer antes que nada un perfil de la víctima, comenzando por conocer el software que usa, y conociendo dicho software. ¿Por qué? Por que es muy diferente saber que el navegador que usa por ejemplo rechaza por defecto cualquier comunicación TLS que parezca insegura o saber si dicho navegador la acepta sin problema!! lo mismo se puede decir del Phising, de los sites malignos, de… Por desgracia, los usuarios son muy rápidos en decidir que es mejor o peor por su estética o su uso a primera vista, y son incapaces de ver que lo importante no es eso, sino las capas de seguridad que hacen que dicho software sea seguro. Veamos ejemplos:

Firefox: Tiene una política de bloqueo por defecto, dando la opción en dicho momento de añadir el certificado a priori inseguro como un certificado seguro, mostrando antes de ello todos los datos de dicho certificado. Ojo!! no añade a la CA que lo emite como segura, solo marca dicho certificado de dicho site como válido. No obstante,  en las opciones de configuración permite la inclusión de entidades CA genuinas que no estén incluidas por defecto y que validen cualquier certificado emitido por ellas, para evitar tener que ir aceptando todo y cada uno de los certificados de cada site que usen dicha entidad.

Internet Explorer: Usa un sistema similar a Firefox, pero es más restrictivo. Para añadir dicho certificado como válido hay primero que aceptar el aviso de peligro (que claramente invita a cancelar la conexión), y más tarde habría que buscar el botón del certificado para instalarlo, y así marcarlo como seguro. De lo contrario, en cuanto el navegador se reinicie volverá a mostrar la misma advertencia.

Chrome: Usa una política casi idéntica a Internet Explorer, invita a abortar la conexión, aunque el mensaje es algo más claro que el usado por Internet Explorer. En contrapartida, es aun más difícil añadir el certificado como seguro en el caso de que estemos seguro de que dicho certificado es válido.

Quizás, de los tres navegadores el que use el sistema más molesto sea Internet Explorer, da poca información e invita a salir corriendo de dicha web, pero también sería el más seguro. Firefox da la opción de añadir el certificado en concreto como válido, lo cual ahorra muchos pantallazos de error similares para consiguientes conexiones, y además especifica el motivo por el cual el certificado no es válido. Chrome no permite añadir como un certificado seguro, pero si explica más o menos de forma sencilla el peligro o no peligro que realmente puede haber, y recomienda instalar los certificados raíces para evitar más avisos. Personalmente me quedo con el modelo de Firefox, aunque al menos, los tres métodos bloquean por defecto y hacen que no sea tan trivial el darle al «Si» de toda la vida que tantos usuarios están acostumbrados a hacer.

Por otro lado nos quedaría Safari y los navegadores de los dispositivos móviles. Safari opta más bien por un popup de advertencia que advierte del peligro de forma muy concisa. El problema, es que Safari usa un sistema de Continuar/Cancelar, y la experiencia nos dice que ante este tipo de ventanas o advertencias el usuario no suele pensarlo mucho y simplemente acepta el cartel.

En dispositivos móviles la cosa cambia, y generalmente se opta por políticas menos restrictivas. En este caso la cosa cambia:

-Safari (iPhone, iPad, iPod Touch): Por regla general acepta el certificado y no advierte de ningún tipo de problema, aunque dicho certificado sea incorrecto
-Firefox Mobile: Usa exactamente el mismo sistema que el usado por la versión tradicional.
-Chrome Mobile: Usa un popup de advertencia que nos avisa del riesgo, el problema es que como hemos dichos estos popup de «si» ó «no» generalmente se aceptan por parte de los usuarios sin preocuparse o preguntarse

Pero por supuesto no solo se limita a navegadores, tenemos del mismo modo gestores de correos, conexiones VPN, conexiones remotas, software que usa estos sistemas para dar un acceso supuestamente seguro a los datos… y cada uno de dichos programas se comportará según sus programadores. Y siempre, sin perder de vista al usuario final, que es quien suele tener siempre la última palabra ante cualquier riesgo de seguridad. Veamos una última imagen ilustrando el robo de una sesión TLS de un HTC Desire accediendo a Gmail:

Evidentemente el host «dTheliel» de este ejemplo corresponde a un dispositivo completamente diferente al que realizó la captura y la manipulación, el cual se aprovechó de un ataque de envenenamiento ARP. Un ejemplo de como incluso los protocolos seguros como TLS/SSL son vulnerables a ataques tipo «man-in-the-midle». En este caso, tan solo una pantalla de advertencia en el dispositivo portátil avisaba de un posible certificado incorrecto, advertencia que como hemos dicho en muchos dispositivos ni siquiera aparece, quitando por supuesto el darle a sí directamente que hace la gran mayoría. En la sesión robada, en los datos eliminados de la imagen por motivos evidente, se podía encontrar no solo la cookie de sesión (que simplemente con ella bastaría para acceder a su correo), sino su correo y su contraseña en «plano», y lo pongo entre comillado porque dichos datos no se enviaron en texto plano, sino en una sesión completamente cifrada bajo TLS (para la autentificación) y RC4 como algoritmo de cifrado de todo el contenido, no solo el nombre de usuario y la contraseña. Este ejemplo puede extrapolarse a cualquier situación en la que se realicen conexiones seguras o túneles por medio de certificados.

 

No hay que sacar en conclusión que los protocolos seguros no lo son, sino que por buenas que sean las medidas de seguridad que existen a día de hoy, más importante es la educación a nivel particular de cada usuario. El ataque anterior habría sido imposible de llevar a cabo si la víctima (en este caso yo mismo) me hubiese parado a pensar en la advertencia de seguridad que mi navegador lanzaba, a ver me parado en ver los detalles de esta y habría comprobado el motivo por el cual el certificado no era válido. En consecuencia, si una víctima hubiese tomado dicha molestia, simplemente habría impedido la conexión a dicho site y nada hubiese sucedido.

 

 

Un apunte sobre WIFI y otras conexiones Wireless

Antes de terminar este capítulo, hay que hablar de las redes WIFI.

Todo lo que hay detrás del Sniffing a fin de cuenta es siempre lo mismo, una técnica que permita conocer los datos que hay a nuestro alrededor. Pero la libre circulación de estos datos depende en última instancia del medio por el cual son transferidos. Podemos capturar tráfico que sale y entra de nuestro equipo porque estos datos llegan a este, y lo mismo cuando estamos conectado a un Hub o usamos técnicas de envenenamiento ARP en un Switch, ya que cuando el ataque está en curso podemos ver nuestro equipo como si estuviese conectado directamente a las víctimas. Pero con las tecnologías inalámbricas estos problemas no existen!! El medio en estas redes es el aire, y todos los equipos que están en su rango, absolutamente todos, reciben por igual la información, no existe un cable que conecta punto a punto dos equipos, la información se transmite al aire.

GSM, 3G, WIFI, Bluetooth… cualquier tecnología que use el aire como medio de transmisión es directamente vulnerable al Sniffing, a fin de cuenta tan solo hay que tener un dispositivo que soporte dicha tecnología que esté escuchando. Esto es bien conocido, por eso estos protocolos, al contrario que los que vieron nacer internet, son constituidos de base pensando en la seguridad. Esto no quiere decir sin embargo que todas estas tecnologías sean completamente vulnerables ante agentes externos, solo que hay que tener más cuidado con ellas. Posiblemente, las dos redes Wireless más comunes a día de hoy sean las redes telefónicas GSM y las redes WIFI.

Si hablamamos de redes WIFI casi todos habrán escuchado en algún momento que es posible robar WIFI, o incluso más actual la extensión de Firefox que permitía robar sesiones de usuarios de aquellas redes WIFI que estaban abiertas. Para evitar que cualquiera pueda capturar de forma simple aquellos datos que no iban destinado a ellos, se suelen usar sistemas de autentificación y cifrado. En el caso de WIFI, el primero y aun usado de forma mayoritaria aquí en españa, WEP, es a día de hoy un sistema roto. Los protocolos WIFI se fueron actualizando con los años añadiendo sistemas de seguridad mejores, hasta llegar a día de hoy con el sistema WPA2 y extensiones de seguridad para entornos más seguros. Pero que existan estos cifrados o métodos de enmascaramiento, no implica que los datos sean recibido por todos los usuarios, solo significa que dichos usuarios no entenderán nunca el contenido. Es evidente que la primera medida de precaución que se tendría que tener ante un dato sensible es el no comunicarlo a quien no vaya dirigido, pero en el caso de las redes inalámbricas esto no es posible.

Podemos hablar también de las redes GSM, actualmente usadas a nivel mundial para la comunicación telefónica. En realidad sucede lo mismo!! los datos son transmitidos desde las torres de forma omnidireccional hasta alcanzar aquel terminal que está emitiendo o recibiendo dichos datos. En teoría, cualquier usuario que esté en rango de dicha torre recibiría igualmente esos datos. Esto abre rápidamente la cuestión sobre si es posible sniffar (capturar) conversaciones telefónicas, y la respuesta es evidente… claro que se puede. Con equipo básico es posible crear un capturador de de señales GSM, lo cual de nuevo no implica que las señales o los datos obtenidos tengan ningún tipo de significado o validez para aquellos a los cuales no estaba destinado dicha comunicación. No obstante, no hay que ser muy listo para tener la certeza absoluta de que es posible (y se hace) realizar escuchas telefónicas realizadas por GSM. Es más, recientemente se hizo público y se mostró una serie de vulnerabilidades que permitirían capturar cualquier conversación telefónica GSM por medio de un pequeño dispositivo dedicado para tal afecto que no sería caro de fabricar (no llegaría a los 1200€), y un par de antenas.

 

 

Es evidente que es el juego del ratón y el gato que nunca termina. Con los años nuevas mentes y sistemas darán jaque a las tecnologías actuales,  y entonces nuevas tecnologías emergerán para hacer frente a las antiguas. Y esto posiblemente se suceda durante aun muchos años. Redes inalámbricas, redes cableadas… incluso se conocen de estudios que logran capturar el tráfico que circula por los cables Ethernet o de fibra sin estar conectados a ellos, simplemente por medio de los cambios electromagnéticos que producen los datos al circular por los cables. Un obseso con la seguridad puede ser un paranoico, pero aquel que se toma la seguridad como algo ilusorio es un loco

Comparativa Navegadores: IE9, Firefox 4, Chrome 6, Safari 5, Opera 10

Índice

  • Versiones de los navegadores
  • Que es mejor que es peor: Que comparar
  • Benchmarks
  • Conclusiones

 

Versiones de los navegadores

 

Tenía pensado escribir este artículo cuando la versión final de Firefox 4.0 y IE9 fueran lanzadas. La razón es obvia, tanto Chrome como Safari han publicado sus versiones más actuales hace poco. El problema de realizar una comparativa de navegadores es la versión de estos que empleas, no sería sensato hacer una comparativa de un navegador oficial frente a otros en estado alpha o beta. Pero sinceramente la creciente publicidad que le ha dado los medios a la beta de Internet Explorer 9 (aka IE9), he optado por realizar una comparativa enfrentando a las versiones oficiales de Chrome y Safari frente a las versiones beta más actuales de Firefox e IE9. Esto quiere decir que esta comparativa no será completamente rigurosa. Por un lado podríamos decir que IE9 y Firefox 4 estarían en desventaja en esta comparativa debido a que es ambos navegadores continuarán añadiendo posiblemente funciones y/o rendimiento adicional al que ya de por sí se tiene. Pero por otro lado otros podrían decir que Chrome y Safari estarían en desventaja dado que se estarían usando versiones completamente actuales, las cuales es lógico pensar que al ser mas nuevas será mejor.

Por ello, espero que esta comparativa se tome tan solo con carácter orientativo. De nuevo hay que tener en cuenta que tanto Safari como Chrome y Opera sacaron sus versiones nuevas hace nada. Chrome 6 fue lanzado el día 2 de septiembre de este año, Opera 10.6 el 1 de Julio y Safari 5 fue lanzado el 7 de Junio de este año. Esto es importante tenerlo en cuenta, dado que el proceso de desarrollo de este tipo de software suele ser relativamente largo. Recordemos que la última versión de IE (IE8)  fue lanzada el 19 de Marzo de 2010 (hace año y medio), Firefox 3 a mediados de 2008, al igual que Safari 4 (la versión anterior). Chrome se queda fuera de esta «norma» dado que es un navegador nuevo y tiene otro sistema de versiones, al igual un poco que le ocurre a Opera. Lo que quiero decir es que en teoría Firefox 4 o IE9  deberían de estar más o menos a la par que sus homólogos, dado que los tiempos de desarrollo de sus versiones ha sido también similar. Actualmente Firefox 4 se encuentra en fase de beta 7, e IE9 en fase beta (sin determinar). Esto quiere decir que aun siendo productos aun en fase beta están en su mayoría ya perfilados.

De todos modos lo que me hace realizar la comparativa no es otra que la cantidad de tonterías que son publicadas en la mayoría de los medios, blog y otros. En estos días no he parado de ver comparativas de IE9 beta por ejemplo con Firefox 3.6.X, lo cual es completamente absurdo teniendo en cuenta que la última beta estable publicada por Mozilla es Firefox 4.0 Beta 6. Otros son mas ingeniosos y comparan la beta de IE9 con versiones beta de Firefox 4.0 que se sabían tenían fallos que aun no se habían corregido. Yo quiero ser un poco más riguroso que todo esto, y aun cuando las versiones de Chrome, Opera y Safari que voy a utilizar son las oficiales, al final del todo abriré un pequeño apartado explicando la fase actual del desarrollo de estos.

Actualizado: Añadido Opera por petición popular

 

 

Que es mejor, que es peor

Otro problema que se plantea a la hora de hacer una comparativa de Navegador es simplemente que comparar. Firefox fue el primero que puso en marcha la carrera de los motores JavaScript JIT, los cuales hacen que el rendimiento en la ejecución de código JavaScript sea exponencialmente superior. Esto no es negativo ni mucho menos, pero hay que saber realmente que importancia tiene esto. Desde que sucediese aquello, parece que ahora lo único que importa es que navegador es más rápido en realizar pruebas de rendimiento sintéticas JavaScript, es decir, pruebas para medir el rendimiento del motor JavaScript del navegador por medio de test que no se ajusta en lo más mínimo a la vida real. Que quiero decir con esto? Es simple, que un navegador sea 100 veces más rápido que otro en un test JS sintético no quiere decir que sea un navegador 100 veces más rápido, ni siquiera que sea 100 veces más rapido procesando JS. Lo único que quiere decir es que es 100 veces más rapido en ejecutar el código JS de dicho test. Os diré que TODOS los navegadores modifican partes concretas en sus motores JS para obtener mejores resultados en dichos test sintéticos, algo así como pequeñas «trampas» que tan solo afectan en dichos test. Es decir, los resultados de estos test son de nuevo relativamente útiles.

Aun cuando los test sintéticos tuviesen una fiabilidad del 100% para medir el rendimieto JS de un navegador, esto es tan solo una parte de un todo mucho mayor. Dicho de otro modo, de que sirve tener el motor JS más rapido del mundo cuando la web que se está visitando no posee código JS o prácticamente carece de él. Cual sería la diferencia entonces? 0.1 milisegundo? menos aun? Es por tanto que me parece sencillamente ridículo comparar navegadores por ello.

En cambio, esta es la norma que han escogido prácticamente todos los creadores de los navegadores para promocionar el suyo. Es cuanto menos gracioso leer el «titular» de cada uno, dice mucho de la empresa/organización que hay detrás:

Internet Explorer 9: «Tan asombroso como la Web misma es el increible potencial de IE9.» «Acceda y compruebe como los desarrolladores crean una web más hermosa gracias a tecnologías como HTML5 y los avances de IE9»

Firefox 4: «Ayúnamos a que sea el mejor navegador dele mundo»

Safari 5: «El navegador más rápido del mundo»

Opera 10.6: «El navegador más rápido del mundo es aun más rápido»

Chrome 6: «Google Chrome ejecuta aplicaciones y páginas web a gran velocidad»

Tengo una interesante duda: Tenía entendido que cuando se habla de «El más…» solo puede ser uno, no dos. Pues bien, tanto Opera como Safari claman que son los navegadores más rápidos del mundo. En cambio es interesante ver como Chrome simplemente dice que es un navegador rápido, o IE9, que solamente hace alusión a sus novedades. El caso de Firefox es igual, tan solo hace alusión a un deseo. Es decir, de los 5 navegadores, dos de ellos automáticamente mienten en el peor de los casos, y en el mejor de los casos no son nada específicos. Esto es lo que ocurre cuando los desarrolladores tan solo se centran en cuestiones específicas para ocultar la decadencia de su propio navegador. Curiosamente tanto Opera como Safari son los navegadores  con una penetración de uso muy inferior al resto.

Otra cuestión ahora de moda es el soporte para HTML5 de los navegadores. HTML5 será efectivamente el próximo estandar en la web que añadirá multitud de funciones nuevas a la web, algunas de las cuales tan solo accesibles ahora mismo a través de complementos como Flash, Java o complementos ActiveX. Esto en realidad es «normal», lo que sucede es que ahora es el corre ve y dile de muchos desde que Steve Jobs (presidente de Apple) no dejase de alardear de la no necesidad de Flash en sus productos gracias al soporte HTML5, declaraciones que pronto tendrán un año. No obstante la realidad es muy diferente, HTML5 no será publicado de forma oficial hasta 2020, y las especificaciones no se congelarán hasta 2012. Es decir, aun pasará mucho tiempo para que naveguemos por páginas web. no específicas, con contenido html5. Actualmente el 99% de todo el contenido HTML5 que existe es experimental y en continuo cambio, dado que hasta 2012 las especificaciones cambiarán constantemente, algunas cosas más y otras menos. Es ahora cuando le preguntaría a Steve Jobs donde están todas las web usando HTML5, cuando en este año el uso de Flash continúa siendo el mismo, y las pocas web que usan el nuevo soporte video de HTML5 se encuentran en fase experimental y con más problemas que otra otra cosa. No obstante, es evidente que es es otra cuestión a tener en cuenta, y es bueno ver que poco a poco los navegadores se adaptan a los borradores HTML5, aunque como digo ahora mismo este soporte es prácticamente inútil dado que prácticamente no hay ninguna web (quitando test o páginas experimentales) que hagan uso de estas nuevas características.

HTML5 no es el único estándar que se está perfilando, junto a este tenemos CSS3, igualmente en desarrollo. Es evidente que junto HTML5 supondrán un avance increíble en como concebiremos Internet en la próxima década. Pero una vez más, todo lo que se dijo para HTML5 podemos decirlo de CSS3. La diferencia radica en que CSS3 es una tecnología que posiblemente sí será usada de forma más escalonada, que sí vamos a ir viendo su uso cada vez más, sin necesidad de esperar años. Desde mi punto de vista, a corto plazo, CSS3 es más importante que HTML5, al menos es más útil.

Que más podemos poner en la parrilla de esta comparación? Bueno, sin duda alguna todo aquello que pueda ser medido. Tenemos nuevos motores JS para el código JS, pero otra cuestión igualmente importante (o incluso más) es el rendimiento de un navegador a la hora de renderizar el contenidos de la web, ya sea texto o gráficos 2D como las imágenes o incluso contenido 3D. Y es aquí cuando entramos en la aceleración hardware de dicho contenido, una herramienta eficaz para permitir velocidades de vértigo a la hora de procesar contenido gráfico en el navegador, permitiendo la creación de contenidos que antes era igualmente imposible de imaginar.

Por último pero no menos importante son aquellas características concretas de cada navegador que están fuera de lo que es la web, pero que nos proporcionan facilidad de acceso, interfaces más cómodas, mayor seguridad a la hora de navegar… cuestiones a tomar muy en cuenta, dado que muchas veces para el usuario medio son estas las que pueden hacer que este se decante por un navegador o por otro. El problema es que este tipo de características no pueden ser muy comparables, cada navegador tiene su propio estilo, su propia filosofía, sus ventajas. Pero veremos algunas también.

 

Benchmark

Una vez visto la introducción, ahora sí, podemos ir a los números y a las comparaciones entre estos. Veremos como la gran mayoría de todos los blog, medios y otros no mienten al poner los resultados, lo que sucede es que publican solo lo que a dicha persona le interesa, realizando pruebas que de antemano saben el resultado que van a obtener, puesto que de lo contrario no lo publicarían. Así, un site que sea seguidor de IE9 hará lo posible por mostrar toda su fortaleza y ninguna de sus debilidades, como pueda ser la web de Microsoft. O por otro lado el Benchmark de Google V8, que evidentemente sería casi impensable que diese un resultado mejor en otro navegador. Los datos que muestran no son falsos normalmente, simplemente son incompletos y muy específicos para que su caballo sea el ganador. Otra cosa interesante con la que me he tomado es no especificar el sistema usado para realizar los test, o si se ha realizado algún ajuste específico en estos que pueda afectar el resultado de estos. Así que antes de poner los resultados, vamos a hacer un pequeño resumen de los navegadores que se van a probar, la plataforma sobre la que se van a probar y todos los test que se van a efectuar. Aquí no habrá ni trampa ni cartón.

Sistema:

  • OS: Windows 7 Ultimate x64
  • CPU: Intel Core i7 920
  • RAM: 12GB DDR3 Triple canal
  • Video: nVidia GTX460 (Driver 260.63)

Navegadores:

  • Chrome 6
  • Safari 5
  • Internet Explorer 9 Beta
  • Internet Explorer 9 Beta x64
  • Firefox 4.0 Beta 7
  • Firefox 4.0 Beta 7 x64
  • Opera 10.6

Test:



 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

  • Firefox 4b7 x64 tiene un bug que provoca que se cierre al ejecutar V8


 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

  • IE9 no puede cargar el emulador.
  • Safari puntúa con 50fps, no obstante es completamente injugable, saltos continuos

















  • Safari 5 no puede cargar el juego
  • Puntuación ponderada a 10













































































  • El primer test HTML5 es sobre 300 puntos
  • El segundo test HTML5 (beta) es sobre 377 puntos
  • Las versiones de 64 bits de IE y firefox  obtienen el mismo resultado que las versiones de 32 bits
  • Safari requiere tener instalado QuickTime para ofrecer los elementos video y audio. Aquí no se testean los navegadores con otros complementos instalados. Podemos decir por tanto que Safari carace de soporte nativo html5 para video y audio.
  • Por alguna razón, IE 9 no es capaz de acceder al test beta HTML,5, posiblemente debido al servidor de dicho test que filtra el user agent o algo similar.



















Conclusiones

Bueno, quien llegue hasta aquí y haya ido viendo los diferentes resultados habrá sacado algunas interesantes conclusiones. Lo primero es que posiblemente no podemos hablar de «El mejor navegador será el mejor en todo», puesto que esto claramente no es posible. En cambio, si podemos hacer un balance global de todos ellos.

 

  • JavaScript

    Sin duda alguna Chrome continua siendo el ganador indiscutible, siendo su engine JS el más veloz, tanto en test sintéticos como en aplicaciones que podríamos de calificar «más reales». Opera parece mantener la segunda posición, aunque queda de manifiesto que en aplicaciones reales como JSNES su engine comienza a fallar. Puede ser una simple casualidad o puede ser debido precisamente a que son los test sintéticos los que están fuertemente… «preparados». Firefox se colaría en tercer lugar, mostrando un buen rendimiento en todos los campos, especialmente en entornos reales si tenemos en cuenta sus resultados en los test sintéticos en comparación con los demás navegadores. El cuarto lugar lo ocuparía Safari, siendo sorprendente que no sea capaz de ejecutar de forma correcta ninguno de los dos juegos creados en JS (uno no lo carga y el otro es completamente injugable), lo cual deja claro que se han preocupado más por obtener buenas puntuaciones en los test sintéticos que en entornos reales. Para finalizar, tenemos Internet Explorer. Lo interesante de IE es en realidad el gran salto que da desde IE8, rozando a Safari si atendemos a SunSpider, o con rendimientos aceptables en BioLab. Esto no quita que actualmente sea de nuevo colista.


  • Gráficos

    Con gráficos recordemos que nos referimos a cualquier contenido de este tipo, desde videos, imágenes, texto… casi cualquier elemento que sea procesador en el navegador. En realidad es tanto o más importante que JavaScript, en cambio esto parece que pasa desapercibido para la mayoría.

    En cuanto a Gráficos se refieres creo que nos encontramos con lo que podríamos llamar navegadores de primera generación: Safari y Opera, y navegadores de segunda generación: IE, Firefox y Chrome. Para aquellos que no hayan realizado test pertinentes o no estén puestos en la materia, podrían incluso creer que los resultados son erróneos, pero nada más lejos. Estos son debido en gran medida gracias a la Aceleración Hardware del navegador, que usa la tarjeta de vídeo del sistema como apoyo. El resultado no puede ser más increíble. Por ejemplo, Chrome 6 tardó nada más y nada menos que 5770 segundos, 1,6 horas aproximadamente en completar el test de las letras, mientras que IE9 lo hizo en 8 segundos!!. El test de las letras, así como otros muchos no son aplicaciones o test necesariamente en 3D, muchas veces se cae en el error que la tarjeta de vídeo tan solo sabe renderizar polígonos en la pantalla. He hablado también de Chrome como navegador de segunda generación, aunque sería más correcto decir de 1.5G. En Chrome 6 es cierto que no existe ninguna clase de aceleración hardware, no obstante en las últimas versiones build de Chrome 7 existe un soporte parcial a esta, aunque solo es parcial. Por el contrario, ni Safari ni Opera poseen aceleración hardware siquiera en sus builds más actuales, ni tienen pensada incluirla a corto plazo.

    La Aceleración Hardware en los navegadores se ha logrado en dos partes. La primera es por medio de las API de Windows Vista y Windows 7, concretamente gracias a Direct2D y Direct Write, dos tecnologías creadas por Microsoft que permiten usar las tarjetas de vídeos basadas en DirectX10+ (y la mayoría de DirectX9c) para acelerar prácticamente cualquier aspecto gráfico de Windows. El éxito de esta tecnología es más que evidente, al igual que sus resultados. La segunda parte es bastante menos significativa, aunque igualmente ayuda en muchas tareas, como por ejemplo en la presentación de vídeos que están superpuestos sobre otros elementos o a los que se le aplican diversos efectos o web con diferentes capas y hojas de estilo. Esto es posible tanto a OpenGL como a DirectX9, y se le llama Aceleración Hardware de composición de capas. La ventaja de este sistema es que al funcionar sobre OpenGL podría ser usado tanto en Windows, Linux o MAC OS, mientras que para poder usar Direct2D/DirectWrite es necesario Windows Vista o Windows 7. Los dos sistemas son complementarios, uno no sustituye al otro, siendo sin duda alguna el más significativo el de Direct2D/DirectWrite.

    El secreto de los números anteriores es que tanto Internet Explorer 9 como Firefox 4 poseen ambas tecnologías en sus navegadores (en caso de Firefox en MAC OS/Linux tan solo podrá usarse evidentemente la aceleración hardware por capas,  y en ninguna circunstancia se podrán beneficiar de D2D/DW). Chrome en sus últimas Builds de Chrome 7 ha comenzado a implementar la aceleración hardware de composición de capas, y dentro de esta tan solo una parte. Es decir, incluso en esas builds el soporte de aceleración de composición es pobre, y los resultados que se obtienen aunque mejoran las cifras actuales en la renderización, estan muy lejos de las cifras de IE o Firefox. Por su parte, tanto Apple como Opera carecen de estas funcionalidades. Posiblemente Opera terminará implementando dicha tecnología, mientras que Safari casi con toda seguridad no lo haga. Por qué? Es simple, Safari es de Apple y Apple usa MAC OS, dudo mucho que Apple trabaje en una versión de Safari que sería muy superior a la versión de Safari para MAC OS. Una vez más vemos la importancia de un OS.

    La cabeza en este caso es sin duda para IE9, que aunque usa las mismas APIs que Firefox, sin duda alguna aun funciona mejor que él. Es muy posible que esto sea debido a bug presentes actualmente en Firefox, y que casi con toda seguridad ambos navegadores estén prácticamente a la par cuando el desarrollo de Firefox 4 e IE9 haya terminado. Es el precio a pagar por las betas. Quizás esto no suceda e incluso en ese caso IE9 continúe ganando la carrera de la aceleración hardware. No obstante también hay que alabar el trabajo de Mozilla, dado que es lógico que Microsoft (que fue quien creo la tecnología en cuestión) la use de forma más eficiente,  sin olvidar que Firefox ya trabajaba con ella antes de que IE9 apareciese siquiera anunciado.

    Dentro de los gráficos, pero sin incluirlos en esta ocasión tendríamos el estandar WebGL. WebGL permitiría usar especificaciones OpenGL para el navegador, es decir, la posibilidad de renderizar contenido 3D directamente en el navegador. El soporte WebGL no obstante creo recordar que es parte de HTML5 (ahora mismo no estoy seguro), y de todos los navegadores tan solo Firefox posee tanto aceleración hardware completa como soporte WebGL, con lo que los test serían un poco deprimentes para los demás. Hay que tener en cuenta que actualmente tan solo Firefox y Chrome son compatibles con WebGL, y Chrome tan solo si se habilita por linea de comandos. Que beneficios nos brinda esto? Bueno, aunque gracias a HTML5 y Canvas podemos representar igualmente contenido 3D, el poder usar OpenGL nso abre un sin fin de posibilidades que de otro modo sería imposible. Como digo, me hubiese gustado mucho añadir algunso test basados en WebGL, pero el resultado sería simple: Todos los navegadores a cero y Firefox el único que podría hacerlos correr. Para quien esté interesado le dejo por ejemplo la web de Chrome dedicada a ella y la de khronos (Chrome tendrá soporte para WebGL, khronos es quien mantiene las especificaciones OGL):

    • https://sites.google.com/a/chromium.org/dev/developers/demos-gpu-acceleration-and-webgl
    • https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/demos/
  • Estándares

    Este es otro punto candente. Los test de estándares me he basado tan solo en dos (podría haber incluido los de Dromeo). Por un lado, Microsoft ha creado un portal bastante interesante en cuanto a test se refiere para estándares. En este caso en particular he pasado todos los test a Firefox 4, y de ahí he obtenido los resultados publicados con anterioridad. Podemos encontrarlos en:

    http://samples.msdn.microsoft.com/ietestcenter/

    Por otro lado tenemos otro conjunto de test que rapidamente analiza ciertas funciones de HTML5 y nos dice cuales cumple nuestro navegador no lo hace. De este en cambio existen dos versiones, la normal y la beta. La beta simplemente incluye más tests:

    http://beta.html5test.com/
    http://html5test.com/

    Personalmente a cuanto HTML5 se refiere me fío más de los segundos test, más que nada porque aun cuando Microsot esté haciendo las cosas mucho mejor, no serían tan idiotas de sacar un conjunto enorme de Test que le dieran la victoria a otro navegador. Es evidente por tanto que los test que encontraremos en Microsoft tienen la finalidad de dar como ganador a IE9. No obstante son igualmente útiles a la hora de comparar el resto de los navegadores.

    En estos test encontramos de nuevo grandes sorpresas, quizás no tanto por los números, pero sí por lo que significan si se saben interpretar. Por ejemplo, si hacemos cuenta a los Test de IE9 vemos que Firefox 4 llega casi al 80% en todos ellos, llegando al 90% en la mayoría de los casos. Pero si mirásemos donde falla (por motivos de legalidad no creo que pueda publicar la tabla completa de resultados tal y como la tiene publicada microsoft), vemos que lo hace en su mayoría en DOM (escritura japonesa y eventos) y en algunos elmentos de HTML5 (con elementos no me refiero a partes de html5). Tanto Chrome como Safari (los cuales usan ambos el mismo engine WebKit), así como Opera obtienen claramente unas «puntuaciones» bastante inferiores.

    Si miramos los test de HTML5 de htm5test.com (y beta), vemos que curiosamente los resultados son muy diferente. En ellos IE9 obtiene de lejos la peor puntuación. Estos test también nos muestran algo realmente curioso, y es que Safari tan solo posee soporte video y audio por medio de html5 sí y solo sí el sistema tiene instalado QuickTime!! Es decir, el navegador te obliga q tenerlo instalado si quieres usar dicha tecnología. Esto es aun más gracioso si tenemos en cuenta que Apple no ha parado de atacar a Adobe por Flash, argumentando que Flash es una tecnología propietaria, lenta e inservible, cuando los navegadores ya pueden reproducir video o audio sin necesidad de complementos. No obstante desde mi punto de vista tener instalado QuickTime para poder usar dichas funciones es tener un complemento instalado!!, ni que decir tiene que además tienes el problema de que es un programa, de sus fallos de seguridad, del rendimiento nefasto de QuickTime… Es decir, el mayor defensor de HTML5 y atacante de otras tecnologías usa complementos para poder usarla y además está en penúltimo lugar según dichos test en cuanto a HTML5 se refiere.

    Podemos concluir sin duda alguna que mirando todos los tests, quizás el navegador más compatible con los estándares actuales sea Firefox, seguido quizás por Chrome. Determinar el tercer lugar sería complicado, quizás fuese Internet Explorer, quizás Opera, quizás Safari, todo depende de a que le diésemos mayor valor. Pero es lo que sucede con los estándares que aun a día de hoy no son oficiales.

    Me han preguntado porqué no incluir Acid 3 a los test de estándares. Bueno, Acid 3 creo que a día de hoy está anticuado y además creo que más o menos todos alcanzan ya el 100%. Los únicos que no lo obtienen son Firefox e IE9, y no porque no sean compatibles, sino dado a que Acid3 testea las fuentes SVG, las cuales creo incluso que ahora mismo están fueras del estandar. Creo que son mucho más importantes a día de hoy otro tipo de test antes de si un navegador es compatible con fuentes SVG o no.


  • Compilaciones x64

    Aun no he tocado este tema. Como puede verse, se ha usado también las versiones de 64 bits de los navegadores que las tienen, Firefox e IE9. En general podemos decir que el soporte x64 aun no cumple con lo esperado. El equipo de Mozilla por su parte está logrando alcanzar los resultados que se obtienen con el navegador de 32 bits, mientras que en cuestionese intensivas se puede obtener un mejor rendimiento. Por otro lado me he topado con una gran sorpresa al ver la versión de 64 bits de IE9. No, no hay error en las cifras, IE9 x64 falla estrepitosamente en JavaScript!! es posible no obstante que su nuevo motor JS no haya sido portado a la versión x64, y de ahí a sus resultados tan dispares. De nuevo solo podemos suponer, dado que es una versión beta y es posible que todo esté de camino.

    De todos modos es más o menos esperable. Portar un programa a 64 bits es complicado. Ya no solo el optimizarlo, sino simplemente el portarlo. La gran mayoría de optimizaciones no se han realizado teniendo en cuenta los 64 bits, con lo que es de esperar que el rendimiento sea inferior. La buena noticia es que en el caso de Firefox el proyecto ya ha unificado las dos arquitecturas. Cada día que pase los compiladores que usan estarán mejor preparados para 64 bits y llegará el día en el que efectivamente veremos de forma clara el beneficio de un navegador web de 64 bits, a fin de cuentas recordemos que teóricamente un programa en 64 bits podría ser hasta un 15-20% más eficiente que su homólogo en 32 bits (por supuesto dependiendo de mil circunstancias).

    Por su parte, actualmente no existe intención por parte de los demás navegadores la creación de versiones de 64 bits, aunque creo (no estoy seguro) que para MAC OS si hay una versión de 64 bits de Safari.

 

Llegados a este punto, podemos por tanto decir que navegador es el más rápido dele mundo? Yo no sería capaz de afirmarlo, pero puedo asegurar que dicha afirmación que hace tanto Opera como Apple es completamente FALSA. Si nos atenemos a contenido gráfico sin duda alguna el ganador sería IE9, seguido de Firefox. Si nos atenemos a test sintéticos o rendimiento JavaScript sin duda tendríamos que decir que Chrome, seguido a cierta distancia por los demás. Quizás habría que realizar un test aun más profundo para tener en cuenta otras contribuciones al rendimiento general del navegador, como lo es el tiempo que tarda en ejecutarse, el tiempo que tarda en cerrarse, el consumo de RAM que hace, el uso del procesador en determinadas tareas… y ojo! no digo que no amplíe este artículo con el tiempo, añada las versiones nuevas que vaya apareciendo y teniendo en cuenta cada vez más factores. Lo que me gustaría al menos haber aclarado es que la navegación Web a día de hoy, la rapidez de navegación no se basa tan solo en la eficiencia de los motores JS de los navegadores, sino en un todo.

Podríamos hacer un balance general de que navegador es el mejor? Bueno, aquí tan solo estamos midiendo aquello que es medible. Para poder afirmar que un navegador es realmente mejor que otro o es el mejor de todos habría q tener en cuenta las funciones que posee, no solo los estándares que cumple o las tecnologías que aplica. Todos los navegadores van aplicando y añadiendo funciones para hacer su navegador más competitivo, incluso Chrome que se basa en la simpleza máxima.

 

¿Personalmente? Bueno, he de decir que cada dia que pasa soy aun más partidario de Firefox. Ya ha logrado colarse en un 3º puesto en cuanto a rendimiento JS, el segundo en rendimiento gráfico, el primero en compatibilidad con estándares, el primero en cuanto a versatilidad y el primero posiblemente en cuanto a seguridad. Si a esto le añado WebGL, la nueva intetrfaz más limpia, las aplicaciones en pestaña, Sync… sin duda alguna creo que Firefox 4 va a ser algo a tomar realmente en serio. Me sorprende no obstante el trabajo en cuanto a gestión de gráficos que ha realizado microsoft en IE9, pero de nuevo aun falla en los estándares y en rendimiento general, por no decir en cuanto a versatilidad se refiere. Esto hace que actualmente la única alternativa real para mí sería Chrome por que precisamente se creó para eso, ser simple. Aunque como digo me quedo de lejos con Firefox. Que decir de Safari? Bueno… si puntuase todos los navegadores sin duda alguna Safari sería el colista. La dependencia de QuickTime es algo absurdo, así como que tampoco añade ninguna función que podamos decir que realmente sea interesante. Y si todo esto fuese poco, durante todo el tiempo en el que TODOS los navegadores fueron testeados, Safari fue el único que se me quedó colgado, aunque sin duda alguna el mayor problema fue que cada X minutos Safari empezaba a hacer un uso intensivo de mis HDD simplemente por el mero hecho de estar abierto. ¿Y Opera? Bueno, los chicos de Opera hacen buen su trabajo, están siempre en medio, pero en la guerra de los navegadores (sobre todo cuando hay 5 que se disputan el premio gordo) no puedes contentarte con ser simplemente bueno. Firefox o Chrome han significado tanto no porque puedan ser más rapido o más versátiles, sino porque innovan. Sí, Opera es bastante Innovador, pero no adapta las innovaciones de otros. Si Firefox ve algo interesante de Opera simplemente lo implementa, al igual que hace Microsoft con IE9, Pero además de implementar las buenas ideas de otros se encargan de crear tecnologías propias, ideas nuevas que a fin de cuenta hacen que la navegación web sea un poco más interesante.

Secunia: Informe Semestral 2010

No es la primera vez que aparece en este blog los amigos de Secunia. Para quien no lo sepa, Secunia es una de las empresas más importantes (si no es la más) dedicadas por así decirlo a consultoría y/o auditoria en seguridad de software. Posiblemente posee la base de datos pública más extensa sobre vulnerabilidades de software. Cuando hablamos de vulnerabilidades de software (normalmente exploits), hay que tener en cuenta que son datos relativos, es decir, los datos que se tienen son siempre de las vulnerabilidades conocidas, no significa que no existan más, y esto es algo a tener muy en cuenta, ya que un buen software (en relación a la seguridad) no se puede medir únicamente por el número de vulnerabilidades, sino la penetración de él a nivel mundial. Esto es algo que este año Secunia a comenzado a tener en cuenta, a fin de cuenta encontrar un error en un programa que usan 10 personas es más fácil que encontrarlo en uno que tan solo usa una persona.

Para quien quiera el informe completo puede descargarlo desde el siguiente enlace:

Secunia Half Year Report 2010

 

Cuando hablas con un experto sobre seguridad informática, puede darte razones o explicarte por qué un sistema es más seguro que otro o que tecnologías son superiores. En cambio, y aquí lo hemos vivido alguna vez, el usuario medio no entiende de exploits, de ASLR, DEP, núcleos… ellos tan solo le dan a un botón para encender su equipo y viven en la creencia de que este es seguro. Y no es que no lo sean, algunos lo son de echo, otros lo son menos y otros… bueno, tiene que existir de todo. Lo que quiero decir, es que ese grupo de usuarios (que es el mayoritario) les vale más una tabla con resultados que todas las explicaciones del mundo. Y aquí es donde entra Secunia. Hoy no vamos a volver a explicar las diferentes medidas de seguridad o que software es mejor que otro y por qué. Simplemente quiero comentar los datos de Secunia.

Pues bien, nada más comenzar el informe, lo primero que nos enseña Secunia es el Top 10 de las empresas de software con más vulnerabilidades. Ya lo he dicho antes, pero lo voy a repetir, tener siempre en la cabeza presente cuales de esas empresas tienen mayor penetración en el mercado. Si se tiene esto en mente, los datos se interpretan de otro modo más realista, y si lo tenemos en cuenta, algunos datos que nos presenta Secunia son escalofriantes, ya que la siguiente imagen tan solo entiende de número de fallos de seguridad, no de uso:

Si los colores no se distinguen bien no importa, en la leyenda de la derecha están ordenadas las empresas por orden de ranking. Los resultados son cuanto menos interesantes. Apple no solo ostenta el peor puesto, sino que va de mal en peor. A esto hay que sumarle el echo irrefutable que de todas las compañías de software del top 10, Apple es además con mucha diferencia la que tiene menor penetración en el mercado!! Ojo!! En esta gráfica no se recogen sistemas operativos o software concreto, sino TODO el software de la compañía. De todos modos los nombres de las empresas del top 10 son de todo menos desconocidos, y de echo, quitando Adobe y Mozilla, el resto de empresas tienen su propio Sistema Operativo: Windows, MAC OS, Android/Chrome, Cisco IOS, VMware ESX…

Hace unos meses era un servidor quien hacía una comparativa similar, simplemente con carácter informativo basándome en los datos de Secunia. Pues bien, el informe de ellos básicamente destaca lo mismo.

1º. El puesto de honor como no podía ser de otro modo es para… Apple, y lo es en realidad desde más allá de año 2000 (no aparece en la gráfica) según Secunia. Y digo desde el 2000, porque como se puede ver en el informe original, en los datos de Oracle se sumaron también los datos de sus recientes adquisiciones: Sun y BEA, si las separamos, Apple reside en el puesto de honor desde el año 2000, superada tan solo por Microsoft como se puede apreciar en 2006. Entre el software de Apple encontramos sobre todo MAC OS, iPhone OS, iTunes y Safari como software más «importante» de ellos, que es en los cuales reside el grueso de las vulnerabilidades. El primer puesto es por tanto para la empresa con menos presencia de software de todas las que aparecen en la lista. (Aun saldrá Jobs diciendo que MAC OS es el OS más seguro, y le echará las culpas de nuevo a Adobe, como ya hizo tiempo atrás)

 

2º. En el segundo puesto tenemos a Oracle, un peso pesado. Si bien es cierto tenemos que ser un poco consecuentes con ellos, y se les ha sumado las vulnerabilidades no solo de estos, sino de sus recientes adquisiciones como por ejemplo Sun. Oracle es una de las empresas más fuertes de Software también, con una presencia enorme en el mercado, posiblemente, de las que más presencia tiene. No es por tanto demasiado incoherente verla en el puesto número dos. Software de Oracle? Pues quizás el que ha tenido mayor repercusión ha sido su software para bases de datos, entornos de programación como JDeveloper, entornos de ofimática como OpenOffice… y recientemente con la compra de Sun pues la lista se engrosa con MySQL por ejemplo o por supuesto JAVA. Es decir, no estamos hablando de una empresa que no sabe que es un software. El puesto número 2 es justificado? Bueno, no es «justo» si tenemos en cuenta el gran elenco de software que aporta Oracle y la penetración de este, pero los datos son los datos, y es la segunda peor empresa en cuanto a seguridad se refiere.

 

3º. Por increible que parezca a más de uno, Microsoft no solo no está en el puesto número uno, sino que se encuentra en el número tres. Bueno, posiblemente a día de hoy sea la empresa de software más fuerte del mundo, no por su variedad quizás, sino por su penetración en el mercado, lo que hace aun más impresionante su posición. Por penetración, Microsoft debería de estar con muchísima diferencia en el puesto número uno, en cambio no es así. Este echo constata el gran esfuerzo de la compañía de Redmond en cuestiones de seguridad. Esto es algo que he dicho muchas veces, pero parece que si no son con datos nadie te cree. No hace falta nombrar el Software de Microsoft, pero por si tenemos algún despistado podemos resumirlo fundamentalmente a: Windows, Office, Internet Explorer, SQL Server e Internet Informations Server (IIS). Recordemos que Windows tiene una penetración de más de un 90%, Office posiblemente de más de un 40%, IE un 40-60 según los últimos datos… y sobre SQL Server e IIS no tengo datos ahora mismo, pero son usados de manera bastante extensa. Y aun con todo ello tan solo ostenta un tercer puesto. Si separásemos Oracle, tendría un puesto aun inferior. y Apple aun quedaría la primera. De echo, a datos de 2005 se puede observar que MS ostentaba el puesto número cinco.

 

4º. Y quien no conoce HP? En realidad desde mi punto de vista los datos para HP son malos… si no tenemos en cuenta la reciente compra de Palms, softaware que ya se encuentra incluido bajo HP en dicha gráfica. HP se dedica principalmente a Software, pese que la gran mayoría los conoce más como OEM. Esto es debido a que las soluciones de HP son más empresariales que domésticas. Es por ello que los datos de HP son malos para mi, dado que no posee una penetración tan amplia como pueda tener Oracle o Microsoft, y en cambio está en el puesto número cuatro. De todos modos, el top 10 coincide más o menos con el top 10 de los mayores fabricantes de software, y por tanto estar en el puesto cuatro tampoco es una noticia demasiado mala. Software de HP? Bueno, quizás menos conocido para el usuario doméstico, pero tenemos desde el software de centros de datos (data centers), sofware de seguridad, de gestión, de control… y recientemente además se le debe de sumar al igual que a Oracle su última adquisición: Palm, lo cual explica un cuarto puesto, y entre su software sobr todo destacar Palm OS/WebOS

 

5º. Adobe System, otra de esas empresas dedicadas por completo al mundo del software. Posiblemente uno de los puestos más equilibrados de todo el top 10, el que menos sorprende ni por bien ni por mal, y no porque esté en el ecuador de la lista. Pese las críticas y el intento por parte de Apple de boicotear Flash, el software de Adobe es por regla general bastante más seguro que el de Apple. Esto contrasta enormemente con las palabras de Jobs, al afirmar con toda la cara del mundo que «Cuando MAC OS falla es por culpa de Flash», excusa que daba entre otras para justificar el motivo por el cual iPhone no tenía Flash. No obstante todo no es positivo para Adobe. Aunque es cierto que Adobe se centra tan solo en software, es cierto también que de todo su software el más «problemático» es aquel que interactua desde la red (como lo es siempre), y básicamente se encuentra en el puesto número cinco por su tecnología Flash o Acrobat. Esto tampoco podemos decir que sea malo del todo, si tenemos en cuenta que Flash tiene una penetración de un 99%!! Es decir, que le guste al señor Jobs o no, un quinto puesto para Adobe son más que buenas noticias para ellos (para adobe), puesto como se verá despúes, solo Safari es bastante más vulnerable e inseguro que Flash.

 

6º. IBM tenía que aparecer tarde o temprano, y lo hace en un buen puesto. IBM es otro de esos grandes pesos pesados, junto con Oracle y Microsoft conforman seguramente los 3 fabricantes de software más importantes del mundo. Enumerar el software de IBM es algo absurdo, es enorme. Desde sistemas operavicos como OS/2, pasando por software de gestión de todo tipo, software de ofimática, de administración, data centers… aunque es cierto que prácticamente el grueso es orientado a empresas. Es cierto que si podemos decir algo a favor de IBM es que siempre se han tomado en serio la seguridad, y un sexto puesto es todo un logro. Evidentemente no tiene la penetración como pueda tener Microsoft u Oracle, pero sinceramente no sale demasiado mal parada.

 

7º. Interesante puesto en la séptima posición, VMWare. En realidad, aun en séptima posición, ostenta un resultado nefasto. VMware es una empresa de software especializada en software de virtualización, el cual por cierto tiene una aceptación y versatilidad enorme!! En los últimos años la virtualización se ha convertido en algo incluso necesario y tremendamente útil. Hasta aquí bien, el problema es que carece de sentido que una empresa con software tan especializado y con una cartera «pequeña» de este, aparezca en el top 10. Evidentemente vmware posee una gran aceptación y penetración en el mundo de los servidores, pero aun así me parece un puesto bastante alto. Sinceramente me ha sorprendido, no sabía que poseía unos resultados tan «malos» en referencia a la seguridad. Entre su software posiblemente los más conocidos sean VMware Workstation o VMware EXS

 

8º. Como no podía ser de otra forma, antes o después tenía que aparecer Cisco. Este es un puesto esperado y que se comprenderá en la medida que lo explique. Cisco, para quien no lo sepa, es la empresa más importante a nivel mundial en infraestructuras de red. En realidad esto podría aparecer no tener una relación demasiado importante con el software, no obstante si la tiene y por partida doble. De todas las empresas que tenemos en el top 10, Cisco es la empresa más «lógica» que intentaría atacar un hacker. Esto puede no tener aun mucho sentido, pero si incluimos que el 90% de toda la infraestructura principal de Internet se apoya en hardware Cisco, esto cobra mayor sentido, y rematamos la cuestión si recordamos que los routers y otros dispositivos de hoy en día son prácticamente todos a fin de cuenta gobernados por un OS o una firmware… software a fin de cuentas. Es decir, la penetración de mercado de CISCO no se puede medir en «personas», como pueda ocurrir con Windows por ejemplo, sino en dispositivos de red. Cisco tiene una presencia increíble a nivel mundial. Y por otro lado, aunque el software de CISCO sea super específico, es evidente que por su gran importancia un porcentaje enorme de esfuerzos recaen en asaltar Cisco IOS, el software de control de la mayoría de sus routers. Encontrar un fallo de seguridad en Cisco IOS puede implicar tambalear todo Internet. No hay que irse muy lejos, hace un año aproximadamente se detectó un fallo de seguridad en este, y la respuesta de Cisco no se hizo de esperar, lanzó una actualización masiva para solucioanr dicho error, y fue enviada con carácter urgente a todos los ISP y otros. Cisco como tal se dedica sobre todo a grandes corporaciones/empresas, no al usuario doméstico, para ello posee la conocida Linksys, propiedad de Cisco. Es por ello que en la lista, CISCO antes o después debía de aparecer, al igual que es evidente que por seguro que pueda ser Windows, siempre aparecerá en la lista.

 

9º. Google!! También era un candidato esperado en la lista, aunque un noveno puesto es un resultado excelente. Google se dedica a día de hoy a prácticamente TODO, y por supuesto al software. Es normal que haya subido algún puesto si tenemos en cuenta la aparición del navegador Chrome o Android, pero tampoco podemos olvidar sus servidores gws (Google Web Servers). Con el éxito de Google es evidente que también ha sido un caldo de cultivo para hackers, y ello implica también que se descubran más vulnerabilidades. Es decir, Google en noveno puesto es una buena noticia para todos, ya que podemos decir que hacen un buen trabajo.

 

10º. Para terminar, el último en el Top 10, y con último me refiero a la «empresa» más segura del top 10, Mozilla (Mozilla es una organización, ojo, no una empresa). Es evidente que como empresa de software más cercano al usuario (navegadores, gestores de correo…) tenía que aparecer en la lista, dado también la penetración y el éxito que ha tenido Firefox (Thunterbird ha tenido menos éxito, pero por la sencilla razón de que el usuario medio no suele usar gestores de correo). ¿Que podemos decir de Mozilla? Bueno, Firefox posee un ratio de vulnerabilidades algo superior a Safari e inferior a IE. Si ahora atendemos a que IE tiene una cuota de mercado de un 40-60, Firefox un 20-40 y Safari un 3-4%, podemos decir sin lugar a dudas que el trabajo realizado por Mozilla es excelente, y de nuevo Apple se lleva una manzana roja, no se comprende como un navegador con tan poca penetración y se le encuentren tantos fallos de seguridad. Es un poco lo que sucede con Windows Vs MAC OS, teniendo el primero una penetración infinitamente superior, y en cambio a efectos globales MAC OS tiene más vulnerabilidades!! esto desde mi punto de vista es cuanto menos sorprendente

 

 

No obstante, del informe de Secunia se pueden extraer más cuestiones interesantes, como es e echo de que la gran mayoría de las vulnerabilidades, esas que hacen que el equipo se vuelva más inseguro, no residen en el propio OS. Por ejemplo, en Windows, el 65% de los fallos de seguridad no residen en Windows en sí, sino en el software que los usuarios instalan sobre él, que es el que debe de ser debidamente parcheado. Esto es lógico. Vivimos una época en la que el software se renueva cada día para ofrecernos desde características más avanzadas a simplemente software más eficiente o adaptado al hardware moderno. Pero quizás el echo más trascendente es la Red. A día de hot prácticamente la totalidad del software permite conexiones a internet para actualizarse, verificar licencias, trabajar sobre la red… esto dota a los programas con una nueva ventana de posibilidades, el problema es en cambio que un fallo de seguridad en el programa puede dejar expuesto al equipo que lo está ejecutando. Es por ello que la principal fuente de ataque en un sistema operativo es el navegador web, dado que es el software directo con el que interacciona cualquier usuario para Internet:

Esta otra tabla refleja el mismo top 10, pero sobre software concreto de terceros, es decir no incluyen sistemas operativos. Tengo que decir que no estoy de acuerdo con los datos de esta tabla. Según esta, Firefox actualmente se encontraría instalado en un 56% de equipos, Chrome un 30% y Safari en un 15%. Bien, actualmente aunque Firefox tiene una cuota más que aceptable y Chrome también, Firefox no tiene una penetración de un 56%, Chrome ni de lejos llega al 30% y Safari más quisiera tener un 15%, al igual que iTunes no lo tiene instalado un 43% de equipos. Los datos de la penetración de Adobe son más reales la verdad, aunque Adobe AIR no llega al 41% ni en sueños. Hay que decir que estos datos proceden de una fuente específica de Secunia, lo cual si explica las tasas de share tan altas. Quitando eso, lo que si es una realidad es el número de boletines de seguridad de cada uno de ellos. En este caso, el que se lleva la peor parte es Firefox y despues Safari a muy poca distancia. De nuevo se debería de repetir lo mismo que en la tabla anterior, el software más usado debería de ser el que más vulnerabilidades presentase, y en cambio vemos de nuevo a Apple casi en cabeza de la lista, siendo Safari el navegador menos usado con mucha diferencia en el mercado.

Si es interesante destacar el tercer puesto y el séptimo. El tercer puesto lo ostenta el runtime de JAVA, que con un 89% de share es aceptable su tercera posición. El séptimo puesto es para Flash, y es destacable porque choca de nuevo de bruces con las palabras de Steve Jobs, cuando este decía que el problema de MAC OS era casi siempre Flash. Pues bien, quitando el echo del share de uno u otro, lo que es cierto es que Safari es en cuanto a seguridad se refiere infinitamente peor que Flash, y eso que Flash tiene una penetración casi dele 100%. Es evidente que una vulnerabilidad no es sinónimo a un mal funcionamiento, pero si pudiésemos medir esto, el resultado sería similar a todas las tablas mostradas. Por cierto, otra posición interesante es la de iTunes, y creo que es la más preocupante del top 10.

Los 10 programas de esta lista, tienen TODOS una interacción directa con internet. En la lista encontramos evidentemente y en los puestos superiores 3 navegadores, y en la cola un gestor de correo. Con esto son ya 4 piezas de software en los que su uso es casi exclusivo para Internet. Pero ademeás de estos 4 programas tenemso JRE y Flash, los dos complementos (addons) para los navegadores más importantes. Si bien estos pueden ser usados para otras aplicaciones, el 99% de su uso es directo con internet. Ya tenemos cubiertos 6 de 10. Por otor lado tenemso Adobe AIR y Acrobat/reader, que en realidad es el mismo software básicamente (una versión lite de la otra). Y por qué está Acrobat en la lista? Porque la lectura de PDF online se ha convertido en algo habitual, y los complementos para los navegadores para ello son igualmente comunes en estos. De las 10 piezas de software mostradas, iTunes es la única que no tiene una razón de ser directa con internet. Sí, iTunes lo usamos para comprar música o aplicaciones… pero no tiene una interacción directa con Internet, tan solo es un programa que requiere una conexión para poder conectar a los servidores de Apple. 48 boletines de seguridad para iTunes es simplemente algo sorprendente, cuando Internet Explorer que posee una penetración de un 99& tan solo tubo 49, y es un explorador web. De nuevo, la seguridad de Apple es cuanto menos inexistente.

Como muchos habrán visto, en dicha tabla NO aparece ningún producto de MS. No es que no estén, es que se han puesto en otra tabla. De todos modos, el tan criticado IE se situaría en dicha tabla en la posición 9.

 

Todo esto no significa que el software que usamos sea deficiente ni mucho menos. Es igual de importante la política de actualización de estos. De echo, algunos software como Firefox o Chrome, pese a tener un numero relativamente elevado de vulnerabilidades, las actualizaciones de estos son casi inmediatas, no se suele esperar a tener 10 vulnerabilidades para corregirlas. Esto quiere decir que cualquier usuario de Firefox o Chrome puede tener una seguridad bastante alta de que su navegador es seguro siempre. Microsoft con IE no es tan inmediato como los dos mencionados. Para MS a menos que sea un fallo crítico suele esperar a los boletines de seguridad que suelen poner en Windows Update cada dos jueves, aunque si es cierto que cuando la vulnerabilidad es grave al día siguiente tenemos el parche disponible en el Update. La peor parte de nuevo es para el software de Apple, la política que tiene de actualizaciones es nefasta. Apple tan solo suele parchear problemas de seguridad cada bastante tiempo. Es decir, si se descubre mañana un exploit que afecta a Safari y que permite un control total del equipo, Apple puede tardar perfectamente meses antes de parchear la vulnerabilidad, mientras que Firefox o Chrome lo tendrían parcheado el día después. Esto parece que no tiene importancia, pero cuando un fallo de seguridad se descubre y se hace público, es muy común que aparezcan exploits inmediatamente que los aprovechen. Existen numerosas bases de datos de estos que se actualizan continuamente, y si tu equipo no está actualizado, eres vulnerable.

Adobe por otro lado es cierto que tampoco se da toda la prisa del mundo, se toma las cosas con algo de calma, sin llegar a la inactuación de Apple. Adobe suele estudiar el caso, probarlo, reprobarlo… y entonces saca la actualización. Ante un fallo crítico Adobe respondería aproximadamente en unos 3-5 días. Sun (ahora Oracle) tendría una respuesta similar. De todos modos ambos tienen un excelente soporte de actualizaciones periódicas, y no está de más actualizar el software dele equipo cada mes o dos meses.

 

Conclusión? Bueno, los datos de Secunia son los datos de Secunia, con sus matizaciones, interpretaciones… pero están ahí. Que Apple disponga del software más vulnerable no es nuevo, para un hacker asaltar un MAC OS es infinitamente más sencillo que una plataforma Windows, o atacar a Safari mucho más simple que hacerlo contra Firefox o IE. Es por ello que aquí se demuestra que los mitos son mitos por algo. Que por mucho que muchos usuarios se empeñen en decir que MAC OS es más seguro, la realidad es bien distinta, no solo son más seguro, sino que son colistas en cuanto a seguridad se refiere.

Firefox 3.7/4.0

Como gran seguidor del proyecto Firefox, no puedo sino ir dejando unas palabras de cuando en cuando en la medida que creo que van sucediendo cosas «interesantes».

La última versión estable lanzada actualmente de Firefox es la versión 3.6.4, en cambio, desde hace ya tiempo se está perfilando la que iba a ser la versión 3.7, que al final casi con toda seguridad pase a ser la versión Firefox 4.0. Pues bien, a día de hoy, Minefield (Nombre en clave de la versión alpha 3.7) ha alcanzado la fase Alpha 5, y se está terminando con Alpha 6. En un principio la idea era lanzar una versión Firefox 3.7 y a posteriori una versión Firefox 4.0, pero como he dicho todo indica al lanzamiento directo de la versión 4.0, lo que ha «demorado» muchas de las grandes novedades que vamos a tener.

En realidad, si tan solo fuesen dos mejoras aquí y una allí, personalmente no me molestaría para indicarlo, pero para mi sorpresa, estos dos últimos meses de desarrollo han sido completamente desbocados a la hora de implementar nuevas funcionalidades. Lo interesante aquí, es que no solo se han centrado en mejorar la velocidad del motor JS que es lo que parece que ahora está de moda y que es lo que prácticamente parece que hacen los navegadores, Safari/Opera y en menor medida Chrome (en menor medida no me refiero a que aumente menos la velocidad, sino que no solo se esfuerzan en ello).

Pues bien, ahora mismo en la build diaria más reciente (Alpha 6), ya contamos con grandes mejoras, y es lo que vamos a ver:

  • Aceleración Hardware para casi todas las partes del navegador: Soporte Direct2D y DirectWrite para todo el layout, lo que implica renderizado de fuentes, de temas, de imágenes… mejorando en mucho la carga de las páginas y aumentando el rendimiento de manera exponencial en aplicaciones y/o contenido visual/gráfico. WebGL para renderizado de objetos 3D. Para poder usar todo ello se requiere mínimo una tarjeta de video DX9, y mejor DX10. Es cierto que aun quedan algunos bug y problemas que arreglar, y es por ello que actualmente no es una opción habilitada por defecto. Para habilitar soporte D2D y DD, es necesario realizar los siguientes cambios en la configuración avanzada de Firefox (Se accede escribiendo en la dirección about:config):

    gfx.font_rendering.directwrite.enabled -> Establecerlo en true
    mozilla.widget.render-mode -> Establecerlo en 6

    Algunas web de Ejemplo para quien quiera probar esto con y sin aceleración hardware, aunque algunas de estas web pueden prácticamente dejar colgado el navegador si no se usa la aceleración:

    http://mrdoob.com/projects/chromeexperiments/ball_pool/
    http://www.tapper-ware.net/stable/web.dom.stresstest.transform/
    http://url3.tk/canvas/

  • Nuevo diseño de la interfaz y soporte Glass para Windows, ahora podemos poner la barra de pestañas en la parte superior si así lo deseamos, y se ha añadido un botón de menú que sustituirá la barra de menús. Actualmente se parece más a una pestaña que a un botón, pero pronto se integrará de forma definitiva en la parte superior izquierda, con un look más agradable.

    Por otro lado la interfaz se ha redefinido de tal modo que será posible de forma simple modificar prácticamente cualquier aspecto visual de Firefox, tanto por temas, como por «Personas», como por «Style». Por ejemplo en mi caso, actualmente he optado por un diseño minimalista, semejante un poco a la interfaz de Chrome, pero con mis complementos a primera mano, maximizando además el área de la web.

    El soporte Glass por otro lado permite una mejor integración con los temas de Windows que tengamos puestos.

  • Nuevo diseño de la interfaz de Addons, que podríamos incluir quizás en el apartado anterior. Ahora, el gestor de complementos y temas no será una pantalla flotante de firefox, sino será abierta como una pestaña más del navegador en el que podremos encontrar de forma sencilla nuestros complementos instalados. Tiene un toque más sofisticado y estético, a la par de una mayor organización
  • Soporte nativo para 64bits, parecía que no llegaría nunca, pero en cambio ya se ha incluido en el repositorio principal de Firefox las compilaciones para 64 Bits para Windows (para Linux ya existían). Esto quiere decir que ahora mismo es posible descargar e instalar Firefox 3.7pre6a en 64bits, y en 64 bits no me refiero a que se pueda instalar en un OS de 64 bits, sino que la aplicación es nativa en 64bits, lo que nos dará un bonito 10-20% de rendimiento (en el mejor de los casos) más una mejora en la seguridad del navegador. Las extensiones funcionarán casi todas perfectamente, en cambio los addons NO. Es decir: Para contenido JAVA, será necesario instalar la versión x64 de JAVA JRE, para Flash habrá que esperar un poco más, dado que también se está terminando el desarrollo de Flash Player para x64. Personalmente, esto es algo que esperaba desde hacía tiempo, y con Firefox en 64 bits puedo decir que por fin prácticamente todo el software principal que uso está en 64bits.
  • Sync, nombre del proyecto WEAVE, el cual permite la sincronización entre diferentes navegadores Firefox de contraseñas, historial, pestañas abiertas, preferencias y marcadores. Es decir, que si usas más de un dispositivo con Firefox, ya no existirán problemas de tener dos configuraciones diferentes. Para ello es necesario o tener un servidor propio de sincronización o usar el de Mozilla, el cual es completamente gratuito, y es tan fácil como acceder a las opciones de Sync, decir que se es usuario nuevo y especificar un nombre de usuario y una contraseña. Tan fácil como eso. En segundo plano cada X segundos/horas se sincronizará automáticamente con el servidor para mantener la copia de este siempre actualizada. Si accedemos desde otra ubicación, del mismo modo simplemente podemos obtener los datos de él.

    Actualmente Sync no obstante no ha sido integrado en el repositorio de Firefox, en el árbol principal, pero se espera que sea en muy breve, con lo que ahora mismo para usar Sync se debe de instalar como extensión. Repito, esto es solo temporal. El único problema que he encontrado es la dificultad actual de montar un servidor Sync propio, el rato que lo he intentado no he sido capaz de hacerlo ,pero espero tener mi propio servidor Sync listo en breve (aun así el servidor de Mozilla funciona perfectamente bien, rápido y eficaz).

  • Comienzo del proyecto Electrolysis, que dará soporte multihilo a Firefox, lo que lo hará aproximadamente un 400% más rápido, tanto en el motor JS como en rendimiento general. El problema de Electrolysis es que se requiere mucho tiempo y muchos recursos, requiere cambiar gran parte de todo el código, dado que afecta al núcleo principal de Firefox. Es decir… aun quedará tiempo para poder ver esto implementado de forma completa. Actualmente lo que ya se tiene es la separación de los Addons en otros procesos, es decir, que cualquier addons como Flash o JAVA serán ejecutado en otro proceso, aumentando su velocidad de proceso y haciéndolo mucho más tolerante a fallos, dado que si el addon es el que falla, en el peor de los casos tan solo tendremos que recargar la web, y no reiniciar el navegador entero. La integración completa con este proyecto no obstante no será en Firefox 4.0. Recordar que tanto Chrome, Opera o Safari son todos multihilos, lo que quiere decir que el gran rendimiento de Firefox es admirable si tenemos en cuenta que no tiene dicha ventaja.
  • Soporte para WebM, la nueva propuesta de Google para HTML5 <video>. De esto ya hemos hablado largo y tendido. Es muy probable que WebM sea escogido como estandar en HTML5, descartando el uso de H264 y AAC. Los mayores sitios de Video en internet ya están migrando a webM, mientras que aun funcionan con flash perfectamente (ambos convivirán juntos). Esto incluye evidentemente a YouTube. Esto implica más cosas, dado que con la guerra declarara de Apple contra el resto del mundo, Apple puede ver en cualquier momento como sus iPhone, iPad, iPod Touch dejan de poder acceder a videos en Youtube y de otros muchos sitios, dado que la única forma que tienen estos dispositivos de poder ver videos es a través de h264 sobre HTML5, y con casi toda seguridad este no sea tomado como estandar. Si declaras la guerra al mundo, te quedas solo y te dan por culo.

    Podemos ver WebM en funcionamiento perfectamente si disponemos de las ultimas build de firefox y acudimos por ejemplo a YT, al portal en pruebas de HTML5:

    http://www.youtube.com/html5

  • Inclusión de múltiples funciones HTML5 y CSS, que como ya se ha dicho en muchas ocasiones HTML5 es tan solo un borrador en continuo cambio, es decir, que cualquier función añadida ahora, mañana puede desaparecer o cambiar o… las palabras absurdas de Apple sobre todo lo que es o no es HTML5 es cuanto menos increíble. HTML5 no será una realidad mínimo hasta 2012 en el que las especificaciones sean más o menos concretas. Pero es que a partir de 2012, no será sino en 2020 cuando sean publicadas las especificaciones completas. Es interesante HTML5? Desde luego. Es el sustituto de Flash? Ni mucho menos.

    Si nos fiamos de la web http://beta.html5test.com/ para medir las características HTML5 del navegador, obtenemos que Firefox 3.7pre6a ya obtiene un bonito 196 199 sobre 315 con 9 puntos de bonificación. Pues bien, Firefox 3.6.4 creo que actualmente obtiene una puntuación de 140 sobre 315 aproximadamente. Aquí hay que citar pro tanto a Apple y toda la demagogia barata que ha realizado sobre sus iPhone, iPad e iPod Touch sobre HTML5. La verdad es que el recién salido del Horno Safari 5, tan «solo» alcanza una nota de 208 sobre 313. Sí, es más que Firefox actualmente, pero es lógico, esta versión ha salido hace unos días, tendremos que esperar que sucede con Firefox 4 cuando sea oficial. También hay que tener en cuenta los test que realiza dicha web, los cuales algunos desde mi punto de vista son cuestionables, dado que muchas especificaciones han cambiado y ya no son especificaciones HTML5. Por ejemplo, Safari 5 soporta bases de datos Web SQL, que era una especificación HTML5. En cambio, esta especificación ya no existe en HTML5 y ha sido sustituida por IndexedDB. Pues bien, dicha web puntúa positivamente tanto la especificación antigua como la nueva. Aun así, un 208 sobre 313 no está nada mal. Pero.. que sucede si comprobamos la puntuación obtenida por los navegadores de iPhone/iPad/iPod Touch? Que obtenemos un mísero 125 sobre 313. Y segúñn Apple estos dispositivos son compatibles con las últimas tecnologías y en especial con HTML5.

    En realidad mi queja es con las palabras de Apple, es completamente normal que ningún navegador obtenga puntuaciones mayores, HTML5 cambia constantemente y es un desperdicio enorme de recursos estar añadiendo funciones HTML5 que dos días después desaparecerán. Lo que si me sorprende es la demagogia barata que se hace para hacer publicidad de algo (o mejor dicho crícita sobre Flash).

    Dicha web mencionada es interesante, pero como he dicho desde mi punto de vista no es del todo fiable. Eso sí, es actualizada de forma asidua, los resultados de hoy no serán válidos para dentro de X días. Primero porque es posible que cambie el sistema de puntuación y por otro lado porque las builds de Firefox hasta el lanzamiento de Firefox 4.0 son continuas. Hace unos días, por ejemplo tan solo teníamos un 186 sobre 313 para Firefox, pero las últimas modificaciones han añadido algunos flecos pendientes. Dentro de unos días o semanas casi con toda seguridad el PRE soporte HTML5 de Firefox será aun mejor, estoy seguro de ello.

    CSS por otro lado es igualmente importante a día de hoy, y se están incluyendo muchas funcionalidades nuevas. Listarlas sería imposible, pero un buen ejemplo para ir testando estas sería la siguiente web:

    http://tools.css3.info/selectors-test/test.html

    Obteniendo 576 test superados de 578 disponibles. Aunque si se desea ver esto en profundidad la web buscada sería esta otra:

    http://samples.msdn.microsoft.com/ietestcenter/

    En dicha web se pueden ir comprobando una a una diferentes estándares y capas CSS. Los amigos de MS no han querido incluir ni Firefox 3.6.4 ni tampoco Firefox 3.7pre6a. Si tengo tiempo incluiré dichos resultados a las tablas de MS, posiblemente veamos como Firefox obtiene las mejores puntuaciones. Como hacer esto? Es muy facil, MS ha realizado un gran trabajo en dicha web, y es posible ir comprobando uno a uno cada test. Es decir, que se puede realizar la misma prueba con el navegador que se desee.

  • Actualizaciones no Intrusivas, aunque es una funcionalidad que aun no se ha incorporado al arbol principal del repositorio. El objetivo es obvio, el poder realizar actualizaciones tanto de extensiones como de software sin siquiera reiniciar en la medida que sea posible y sin molestarnos en ello, todo casi de forma automática.
  • Nuevo motor JS, lo que permitirá una mayor velocidad en el uso de código JavaScript. Mozilla revolucionó la era JB con el lanzamiento de su motor SpiderMonkey. Desde ese día, parece que los navegadores de la competencia tan solo se dedican a mejorar sus motores JS, usando la técnica de Mozilla (compiladores JIT). ¿Que ha sucedido? Que en cualquier lugar te miden ahora el rendimiento del navegador por su motor JS, así tenemos benchmark como SunSpider de Apple o V8 de Google. En realidad es un error medir el rendimiento de un navegador por esto. Sí, el motor JS es muy importante a día de hoy, puesto que casi cualquier web tiene código JS por debajo, y su procesamiento es vital para una navegación rápida y fluida. No obstante se usa demagogia para esto. Actualmente se dice que Chrome es el navegador más rápido que existe, y sea esto cierto o no, el 99% llega a esta conclusión por los test que existen que simplemente miden el rendimiento del motor JS.

    Aun así esto es importante. Actualmente Firefox en las últimas builds tiene un puntuaje de 550 aproximadamente en SunSpider, lo que le hace estar por debajo tanto de Chrome como de Safari 5 en cuanto a JS. OJO!! Y es muy importante a tener en cuenta de nuevo que Firefox NO ES multihilo, los otros navegadores sí. Aun así, se están haciendo buenos progresos en mejorar el motor actual. a SpiderMonkey se le añadió TraceMonkey, una serie de extensiones y mejoras para aumentar considerablemente su rendimiento. Pero eso fue hace ya tiempo. Actualmente se está trabajando para mejorar el rendimiento en general, y es cierto, dado que en las diferentes build de este último mes, usando SunSpider, he podido comprobar una disminución de casi 100 puntos (Cuanto menos mejor). Es decir, que por ver el resultado final (recordemos que aun estamos en fase Alpha)

  • Otros, es evidente que existen más cambios que se están realizando y que ya se han realizado, pero son a niveles más bajos, en los cuales el usuario normal posiblemente no le interese ni le importe de forma directa. Por ejemplo APIs para los programadores, fallos de seguridad, mejoras en rendimiento general, sockets para el acceso directo a servidores..

 

Ya sé que tan solo disponemos actualmente de versiones Alpha, pero son muy prometedoras. La versión Beta 1 ya no debería de tardar, y casi con toda posibilidad, la beta 1 sea renombrada ya oficialmente como Firefox 4.0b1. Desde mi punto de vista esto sí es realmente una versión nueva, y no una mezcla más para sonar en la prensa. El usuario medio notará grandes mejorías con estos cambios, tanto en rendimiento como en personalización y funcionalidades, así como las adaptaciones propias de las más nuevas tecnologías que van emergiendo.

Veremos que sucede dentro de unas semanas…

 

Un saludo.

HTML5

El problema de ir contra todo el mundo e intentar imponer tus ideas a base de repetirlas y de la crítica rápida, es que puede darse el caso de que todos comiencen a luchar por objetivos en común, y tú te quedas fuera. Pero antes de entrar en materia vamos a recordar un poco esta historia:

 

En estos días es raro encontrar algún lugar donde no se hable de Flash, HTML5 o H264. Ya hemos hablado de todo ello bastante en profundidad, pero es que estos días se ha vuelto a dar otra vuelta de tuerca más. Si bien hace unos días Steve Jobs publicaba una carta abierta y algunos días despues Adobe hacia lo propio, hoy es Google el que ha decidido tomar cartas en el asunto. Es cierto que no afecta directamente a Flash, pero sí indirectamente.

Recordemos como Apple no hacía otra cosa que defender de forma férrea el codec estandar H264 para la característica que tendrá la especificacion HTML5 para reproducir video sin necesidad de plugins como Flash. Igualmente recordamos Adobe diciendo o recordando la necesidad de Flash.

Si volvemos un poco más en el tiempo, recordemos que dijimos que actualmente los navegadores Firefox, Opera, Safari Y Chrome ya habían adaptado sus navegadores para poder hacer uso de la característica <video> de HTML5, pero que el problema que aparecía eran los Codec. Si, HTML5 permitirá reproducir videos, pero si HTML5 es un esntadar se tendrá que acordar también un estandar para el audio y otro para el video a reproducir. Y es aquí donde comenzaba la tragicomedia., puesto que no todos tienen intenciones meramente altruistas, y algunos de los afectados tiene intereses económicos.

Recordemos que por parte de Firefox, tenemos actualmente soporte HTML5 <video> (recordemos que todo lo que sea referente a HTML5 NO ES DEFINITIVO). En el caso de Mozilla optó por usar como codec de Video Theora y como codec de Audio Ogg Vorbis. Ambos codec son de código abierto y sin ningún tipo de licencias. Cuando se habló sobre implementar también H264 como codec de Video por ser el estandar actual de HD y por tener además mucha más calidad en todos los aspectos, Mozilla respondió que sería ideal, pero que H264 está fuertemente patentado, lo cual hace que esté constantemente sujeto a posibles royalties o compras de licencias, ya sea para la propia organización Mozilla por incluirlo en el navegador, como para los creadores de contenidos que quieren publicar sus videos en la Red.

Por otro lado tenemos la MPEG LA que administra las licencias de H264 (recordemos que H264 es otro nombre de MPEG4 AVC Part 10, que es como se llama formalmente el Codec). Desde el punto de vista de la MPEG LA le interesaría que el codec fuese usado extensamente, aun cuando su utilización web quedase completamente libre de cargos o royalties. Es así que ya anunció que a priori y hasta 2015 esto será así. No obstante, hay que tener en cuenta que en cualquier momento la MPEG LA podría comenzar a cobrar por su uso… y es evidente que esto no es del agrado de nadie. H264 posee muchas tecnologías fuertemente patentadas por diversas entidades que evidentemente dudo mucho que TODOS liberasen H264, con lo que H264 pese a ser el mejor codec q actualmente disponemos, no es una opción viable de cara a una Internet «libre».

En el lado del Ring de Firefox, aparece también Opera, el cual piensa prácticamente lo mismo que este, por el tema del navegador. Hay que tener en cuenta que de no afirmar la MPEG LA el libre pago hasta 2015, Firefox u Opera tendría que pagar 1 Millón de dolares en conceptos de uso… lo que no es calderilla para organizaciones sin ánimo de lucro. Pero al lado de estos no solo está Opera, sino muchos otros que H264 les cuesta el dinero, lo que sucede es que ahora mismo no hay ninguna alternativa viable… ¿o sí?

Pero la MPEG LA no está sola. Cuenta por supuesto con el apoyo incondicional de Apple, Intel o Microsoft por una razón muy muy simple: Ellos han contribuido en mayor y menor grado al desarrollo de H264, es en parte «su codec». Ellos no tendría que pagar por el uso de dicho codec, y dado que H264 es actualmente el codec más superior en el mercado… En cuanto navegadores Apple con safari y Microsoft con IE lo tienen claro, sus navegadores SOLO podrán usar H264 como codec de Video. IE9 aun está en fase Alpha, pero MS ya ha anunciado que así será. Safari ya dispone de soporte preliminar para HTML5 <video> con h264. Pensar que esto es un problema enorme!! Firefox y Opera no soportarán a priori H264 (y dudo q lo hagan despues de las últimas noticias), y por el otro lado, Safari y IE tampoco soportan Theora y solo H264. Recordemos que HTML5 ES UN BORRADOR!! actualmente no se ha optado por usar uno u otro. Si en un futuro se optase por H264 está claro que todos antes o después migrarían a él, y lo mismo con Theora. Pero el problema no es que sucederá cuando uno se estandarice, sino qeu hacen los creadores de contenido antes de ello. Si quieres ir adaptándote a HTML5, ¿como creas tus videos? Si los dejas en HTML5 actualmente solo Safari y Chrome pueden visualizarlos, lo que hace que sea un 15% aproximadamente de usuarios. Si por el contrario lo haces en Theora, entre Firefox,  Opera y Chrome tienes un 30-40% de usuarios que lo disfrutarían.

Pero no todos están en un lado u otro, en medio tenemos a un pesos pesados, Google. Google ha dado soporte en Chrome tanto para Theora como H264. Recordemos que Google uno de sus principales negocios es el video. Para google una tecnología de compresión superior (igual calidad y menos espacio) implica ahorros millonarios en ancho de banda y almacenamiento. Para Google esto es serio, y es por eso que actualmente prácticamente la totalidad de videos de YT están en h264. Google siempre ha sido más de la opinión de H264, pero hace unos meses, entre la compra de ON2 (una reconocida empresa de codec de videos, como el famoso VP6/7 y actualmente VP8) y las broncas qeu han tenido todos contra Apple le han echo dar el paso q se esperaba. Google en Enero compró como hemos dicho ON2, lo que hace automáticamente propietario de VP8. VP8 es un codec de video actual, que tiene unas capacidades de compresión interesantes. Desde mi punto de vista y de algunos expertos, H264 es superior. Por parte de Google y los interesados por supuesto VP8 es superior. Pero lo que está claro es que VP8 si es un codec más que decente, supera por bastante a Theora y puede al menos pelear contra H264, lo cual no es poco. VP8 era propiedad de ON2, un codec fuertemente licenciado, pero en manos de Google todo parecía que iba a quedar libre… y así ha sido. La filosofía de Google ha sido la más radical en estos tiempos en cuanto a hacer negocios. Mientras que empresas como Apple intentan exprimir sin aportar demasiado, Google ha estado constantemente innovando y haciendo todo (prácticamente) público y libre de cargos. Google obligó a Microsoft a actualizar Hotmail, y a día de hoy Gmail se ha convertido en la mejor plataforma de servicios de correo/calendario/contactos… A los amigos de Google les gusta el dinero como el que más, pero saben que a la larga aportando ganan más. Todo esto se traduce como? Con la publicación del código de VP8 y licenciando este bajo licencia similar a BSD, es decir, que cualquiera podrá usarlo para crear codec o contenidos con estos codec sin tener que pagar nada.

Pero Google ha ido aun más lejos!! No solo ha liberado VP8, sino que ha creado un consorcio entre algunas de las compañías de tecnología más importantes del mundo, como puedan ser la poderosa nVidia o ATI (por parte de AMD),  Adobe, Mozilla, Opera, Google (evidentemente), ARM, MIPS, Logitech, Marvell… y es evidente que se espera que muchas otras  se unan a esta iniciativa, que no es otra que trabajar en conjuntos para la creación de un estandar para el video en internet, basado en VP8 como video, Ogg Vorbis para el audio y un contenedor para ambos basado en Matroska. Google por otro lado ha comenzado la conversión de los videos de YT a VP8 también.

 

Pero como afecta todo esto a HTML5 o a H264?

Para Firefox u Opera es una salida más que satisfactoria. Ambos no tendrán problemas en adaptar sus navegadores para incluir VP8 en caso de que la iniciativa prospere. Estas tecnologías estarán totalmente libre de cargos, lo cual es bueno para ellos y bueno para nosotros.

EDITO: Los programadores de Mozilla Firefox han hecho los deberes y ya tienen las primeras compilaciones (en versión preview) con soporte para Webm (el proyecto comentado). Quien quiera puede probar en este enlace: http://download.mozilla.org/?product=devpreview-1.9.3a4webm&os=win&lang=en-US. Una vez más se demuestra la eficiencia y capacidad de trabajo de estos chicos. Es muy posible que Google haga lo mismo con Chrome

Para Apple y Microsoft es, y perdón por el lenguaje, una putada enorme. Apple lo tiene aun más crudo de los dos. Para empezar ambos son beneficiarios directos de h264, lo cual implica que se está optando por una tecnología de la cual no obtienen beneficios. ¿Por qué Apple lo tiene peor? Primero por sus dispositivos portátiles iPod Touch, iPhone e iPad. Recordemos que no tienen soporte flash!! lo que haría posible actualmente ver el 80% de webs, ya  que usan esta tecnología, pero tampoco pueden ver videos que usen Flash como contenedor. Estos dispositivos se limitan tan solo a poder ver videos de las web que estén creados con el borrador HTML5 y h264 bajo condiciones muy específicas. Si VP8 llega a estandarizarse para HTML5 realmente, los usuarios de iPhone, iPad e ipod Touch se quedarían completmaente a ciegas, dado que tampoco tienen Flash. A microsoft esto le importaría menos, dado que IE9 aun no ha visto siquiera la luz (y aun tardará). Además, los tiempos modernos nos dicen que Microsoft ha aprendido las lecciones del pasado, y si ve que VP8 empieza a ganar la batalla implementará VP8 si es necesario… pero honestamente dudo que Apple de su brazo a torcer tan fácilmente, más teniendo en cuenta que todo lo que ha hablado y criticado estos meses, TODO, se volverá contra él si H264 no aparece en HTML5

EDITO: Microsoft ha confirmado hace unos minutos que implementará soporte para VP8 en IE9, aunque el usuario tendrá que tener instalado el Codec en el Sistema. Esto deja a solas a Apple, y convierte VP8 en una opción cada vez más real. Como he dicho justo antes, Microsoft ha aprendido bien las lecciones de pasado.

¿Para Intel? No suelo hablar mucho de Intel por una razón muy simple. Como he dicho siempre Intel juega siempre en una liga aparte. Existen grandes empresas y por otro lado existe Intel. Intel estaba metido en el desarrollo de pleno de H264, pero es que es muy raro encontrar un proyecto que pueda tener futuro en el que Intel no esté incluido!!. No puedo asegurarlo, pero posiblemente la cartera de patentes de Intel sea la mayor que existe. Dicho de otro modo, posiblemente Intel (personalmente claro) sea una de las compañías con más poder en el mundo (sino la más). Esto es simple… podemos hablar de nVidia, AMD, IBM, Apple, el gobierno de Estados Unidos, la NASA… pensar en lo que queráis, pero Intel lo hace posible. Por poner un ejemplo sencillo, AMD puede fabricar procesadores porque Intel se lo permite. Podemos hablar del poder o importancia de Google por supuesto, o de Microsoft!! pero es un poder… «diferente». El poder de Intel llega a prácticamente cualquier rincon del mundo, no solo Internet. Todo esto que quiere decir? Que Intel prefiere H264, pero ni tiene un navegador ni creo sinceramente que se preocupe mucho por si VP8 o H264. De echo no me extrañaría lo más mínimo que Intel accediese unirse a la iniciativa de Google.

¿Y para nosotros? Para nosotros usuarios depende de que herramientas usemos, es evidente. Si somos tan solo navegantes con Firefox, Chrome u Opera, no tendremos que preocuparnos de mucho. Si somos usuarios de iPhone/iPod/iPad o Safari tendremos un gran problema si VP8 es aceptado como estandar para HTML5, dado que está por ver el soporte que pueda tener. Si somos creadores de contenido Web tampoco nos importará una vez el estandar está claro y vemos la tendencia, ya que lo que deseamos como creadores es que nuestras creaciones puedan llegar a TODOS. Si somos creadores de contenidos Web Y nos dedicamos a la codificacion de Video por aficción, trabajo y otros, puede ser un poco engorroso, ya que lo ideal sería estandarizar una tecnología para TODO, y así para contenidos HD en el PC o en casa tendremos H264 y para Web VP8

 

¿Personalmente que opino?
Bueno… mi corazón está dividido. Sin duda alguna soy defensor de H264 por su gran calidad, pero igualmente defensor de los estándares abiertos y accesibles para todos, si es código abierto mejor que mejor. Pero visto todo, creo que prefiero sin duda que la iniciativa de Google prospere, HTML5 incluya VP8 como codec y en casa continuaré usando H264 sin duda. Existiría la posibilidad de que el consorcio que estudia y crea HTML5 considere la inclusión de H264 y VP8 indistintamente? Sería una posibilidad, pero sería un problema más que una virtud, ya que quien quiera meter en el navegador H264 tendrá que pagar posiblemente a la MPEG LA, y en cambio VP8 estará en todos los navegadores de manera segura, lo que hará a los creadores de contenido crear los videos en VP8 y así asegurarse su visionado.

 

El tiempo nos dirá que sucederá. Recordemos que hasta 2012 no se esperan las especificaciones más o menos fijas de HTML5, y hasta 2020 aproximadamente su publicación final.

Volver a arriba

Sobre Mí

Alma Oscura por Theliel is licensed under a Creative Commons Reconocimiento-No comercial-Sin obras derivadas 3.0 Unported License.
Política de Privacidad.
Para otros permisos que puedan exceder el ámbito de esta licencia, contactar en blog.theliel.es/about/contactar.