Archivo de la categoría ‘MAC OS’

DNS Over HTTPS/TLS: Encriptado del tráfico DNS

 

A lo largo de los años, la mayoría de los protocolos “base” con los que se constituyó el Internet que hoy conocemos han ido evolucionando, algunos más algunos menos. Es cierto que la base en la que se sostiene es a groso modo la misma, pero no así los protocolos que están encima de la mesa. El mejor ejemplo es el propio protocolo HTTP, que aunque parezca muy antiguo, realmente su primera especificación es de 1991. Vale, son 27 años, pero Internet podemos datarla más o menos por 1980. Sí, a día de hoy el protocolo HTTP es la base de toda la Internet navegable, pero muy poco queda de esa primera especificación de 1991. En 1996 aparecería la especificación HTTP/1.0, en 1999 HTTP/1.1 (la más usada a día de hoy) y en 2015 HTTP/2.0. HTTP ha evolucionado y es posible que continúe haciéndolo, y HTTP/2.0 ofrece grandes mejoras en todos los aspectos frente a especificaciones más viejas.

HTTPS apareció en 1992, un modo ingenioso, práctico y seguro de poder enviar/recibir la información HTTP de forma cifrada punto a punto, es decir, se cifra y descifra en origen, permitiendo conocer si ha existido manipulación en medio y además añadiendo identificación de las partes por medio de certificados digitales. Ahora, en 2018, HTTPS lo vemos como imprescindible, y con los certificados digitales más a mano que nunca hemos visto como el % de webs que lo han implementado se han disparado. ¿Por qué? Porque después de años de hartazgo de las propias instituciones gubernamentales, de fallos de seguridad, de robos de datos… ahora somos más desconfiados que nunca, y nos gusta pensar que, aunque lo que estemos mirando en Internet sea donde comprar un colchón, nadie va a poder saberlo (Bueno, todo tiene sus limitaciones, claro). Realmente su importancia principal fue y ha sido y será, debido al intercambio de datos privados entre usuario y servidores. Desde usuarios y contraseñas, direcciones postales, tarjetas de crédito, expedientes médicos… todo. Cualquier información que no vaya cifrada punto a punto corre el riesgo de ser leída… y ya no solo por posibles “cucarachas” que se conecten a nuestra red interna, sino (y siendo un poco conspiranoicos), gobiernos, entidades, los mismos ISP…

Pero si existe otro protocolo de igual importancia en Internet, o incluso más, es sin duda el protocolo DNS (siempre por supuesto hablando de protocolos a nivel de aplicación).

 

DNS

Lo primero que debemos de tener en Internet es, como todo el mundo sabe, una IP. Una IP es un identificador numérico que no solo nos hace accesible desde el exterior, sino también poder ir a cualquier rincón de Internet. Las IPs son las verdaderas direcciones en Internet, pero en cambio rara vez tenemos que usarlas. El 99% del tiempo que estamos en Internet, nos valemos de un sistema de nombres (aka dominios) para poder acceder a un servicio/sitio u otro. ¿Por qué? Porque nuestra mente, nuestro cerebro, se le da infinitamente mejor recordar nombres o cadenas de caracteres que una sucesión de números. Para nosotros es infinitamente más sencillo recordar “google.es” que “216.58.201.163”. Basados en esta premisa fundamentalmente, se creó un sistema de nombres (de dominios), llamado DNS (Domain Name System).

Posiblemente el protocolo DNS es de los más sencillos de entender. DNS funciona como un “traductor”, algo así como unas páginas amarillas gigantes. Cuando introducimos un nombre de dominio en cualquier navegador o aplicación, esta envía la solicitud al servidor DNS que tenga especificado, y este será el encargado de resolver la dirección correspondiente al nombre de domino especificado, y el tipo de registro solicitado. En este artículo de hace tiempo puede verse mejor como funciona DNS. Es un poco más complejo debido a que el sistema DNS es distribuido e incluso jerárquico, pero en lo que nos atañe, es tan simple como eso.

El protocolo DNS no ha evolucionado en nada. Es cierto que se ha expandido con los años con la inclusión de nuevos tipos de registros DNS, e incluso mejoró notablemente la seguridad con la inclusión de DNSSec, pero el protocolo en sí mismo es el mismo que el que se empezó a desplegar en 1983. Eso no es malo, cuando algo ha evolucionado tan poco y aun así es usado tan extensamente, es que funciona realmente bien. No obstante, la sociedad ha cambiado, y tal como sucedió con HTTP, DNS no se creó con la privacidad en mente, por entonces había mejor voluntad y posiblemente mejores ideales. A día de hoy sería impensable crear un protocolo sin que la encriptación y autentificación no estuviesen desde el comienzo del desarrollo.

DNSSec ha dotado a DNS de un sistema de “autentificación”, de modo que las peticiones DNS resueltas por los servidores DNS pueden verificarse/autentificarse, que proceden realmente del servidor DNS raíz a quien pertenecen. Sin DNSSec, se podría envenenar la caché de un cliente DNS, de modo que peticiones realizadas de dicho cliente fuesen respondidas con una IP falsa. Este tipo de ataques ha sido muy efectivo en el pasado… los mismos resolvers tienen que escalar la petición DNS a los servidores DNS, y en ese proceso puede ser bombardeado con respuestas DNS falsas, con lo que el resolver creer que la IP falsa es la real, y ser la IP que al final devolvería al equipo en cuestión. Cuando DNSSec es usado, el servidor DNS firmará la respuesta DNS con cifrado asimétrico, y las enviará en otro registro DNS conjunto a la petición original, y dicha firma el resolver/cliente puede verificarla con los registros del servidor DNS, que contienen a su vez la clave pública con la que se firmaron. De este modo el cliente puede saber con exactitud si la respuesta que hemos recibido proviene realmente del servidor DNS legítimo.

DNSSec es importante, añade autentificación, pero… ¿que pasa con la encriptación?

 

DNS Over HTTPS/TLS

Los datos que se transfieren por DNS son muy importantes. Vale, no van a contener datos confidenciales de tipo contraseñas, usuarios y otros, pero todo el tráfico DNS que generamos indica perfectamente nuestra actividad en la red. Es por medio de DNS que se filtran contenidos (controles parentales por ejemplo), se bloquean contenidos (autoridades/entidades), los ISP pueden crear enormes bases de datos con nuestras costumbres… simplemente mirando el tráfico DNS podemos saber de una persona una cantidad de información que ni imaginamos!! Pues imaginar eso aplicado a una red local entera, o a una red de una empresa, o, por qué no, toda la red de un ISP.

El protocolo DNS se transmite en formato plano, “legible”. Desde hace muchos años han existido varias técnicas para “camuflar” o enmascarar el tráfico DNS, esto no es para nada nuevo. Estas técnicas han sido en su mayoría el uso de servidores VPN por ejemplo, donde las peticiones DNS se enviaban a través del mismo túnel, o usando el conocido DNSCrypt, una solución presentada hace tiempo por OpenDNS, unos servidores DNS independientes y gratuitos que ofrecen una buena tanda de opciones y filtrados para los hogares. No obstante este tipo de técnicas siempre ha tenido un impacto muy pequeño, y un poco por las razones de siempre: Soporte y estandarización.

Ya han pasado muchos años desde que Microsoft no dejase de implementar en su navegador Internet Explorer características propias. A día de hoy intentamos basarnos lo más posible en estándares, protocolos y técnicas que pueden ser usadas en cualquier sitio, que todos los dispositivos puedan entender y poder interaccionar unos con otros obteniendo resultados similares. Puede que DNSCrypt sea/fuese un sistema muy inteligente, pero sin ser un estándar ¿qué servidores DNS o que clientes iban a implementarlo? Por supuesto, era posible usando su servidor DNS y otros software, pero no es una solución real.

Por suerte, y aunque ha costado mucho mucho trabajo, se ve el final del problema gracias a DNS Over HTTPS/TLS (DoH). Me gustaría pensar que los retrasos se han debido al tiempo necesario para crear un estándar sólido, pero honestamente lo que creo es que a la gran mayoría de empresas, gobiernos y otros, cifrar el tráfico DNS es poner fin a un negocio multimillonario, a bloqueos, filtros… es una de esas cosas que públicamente nadie puede estar en contra, pero por detrás es raro encontrar quien esté de acuerdo. Sea como sea, y después de muchos tiros y afloja, DNS Over HTPS ya está “terminando” su camino para ser ratificado por la IETF como estándar, mientras que DNS Over TLS ya está estandarizado. Pero… ¿no son iguales? Bueno, en realidad no, son muy similares. Al igual que el protocolo DNS se usa mediante el puerto 53, DNS Over TLS usa un puerto específico para ello, el 853, y por él envía de forma serializada y ya bajo TLS las peticiones DNS. DNS Over HTTPS en cambio se basa en peticiones HTTPs estándares, usando por ello por defecto el puerto 443, y las peticiones son serializadas dentro de la propia petición HTTPS, creando una pequeña sobrecarga de protocolo inicial.

Aunque ambos sistemas encriptan por igual las peticiones DNS, realmente la diferencia de ellas desde un punto de vista práctico es que usar DNS Over TLS implica usar un puerto dedicado para ello, de modo que resulta mucho más sencillo bloquearlo, filtrarlo, discriminarlo o incluso como veremos luego obtener información de los dominios visitados de forma más sencilla… dicho de otro modo, es más fácil que terceros vuelvan a las andadas, aunque por otro lado es lógico que use un puerto propio. Por otro lado, DNS Over HTTPS usa el mismo puerto 443 que cualquier web HTTPS, con lo que el tráfico no solo pasa mucho más desapercibido, sino que además bloquearlo por puerto/servicio no sería una opción, a todos los efectos la conexión se vería como una conexión HTTPS más.

Usando por tanto DNS Over HTTPS enmascara todas nuestras peticiones DNS de forma doble. Por un lado encripta todo el tráfico DNS de modo que no pueda ser visible para terceros, y por otro lado “engaña” a cualquiera que pueda estar espiando el tráfico, a todos los efectos como si se tratase de tráfico HTTPS convencional.

Esto tiene infinidad de aplicaciones prácticas. Las más evidentes, nos blindan frente al exterior, impidiendo en la medida de lo posible que terceros puedan saber que Webs estamos o no visitando. Por otro lado este sistema permite “pasar por alto” innumerables filtros impuestos por gobiernos/ISP/entidades. Estos no pueden hacer filtros IPs por lo general, así que se filtran a nivel de DNS. Las primeras soluciones a esto eran usar servidores DNS alternativos, pero nada impide a un ISP interceptar las peticiones DNS a otros servidores. Con DoH no pueden evitarlo, las resoluciones nos son devueltas cifradas y bajo un tráfico que podría ser cualquier cosa.

 

Inconvenientes

Visto así, todo parecen grandes ventajas. No obstante el sistema no es perfecto, y además añade algunos “problemas” que no están presentes en las resoluciones DNS estándares.

El primer y posiblemente el mayor inconveniente es el retardo, la latencia. Negociar una conexión HTTPS completa con el resolver DoH, enviar la petición, y obtener la respuesta, consume sensiblemente más tiempo que una resolución DNS estándar. Este tiempo puede reducirse de diversas formas, por ejemplo manteniendo la conexión abierta con el resolver para futuras peticiones DNS o haciendo uso de HTTPS/2.0. Pero aun con todo, no podemos suprimir la negociación requerida para establecer una conexión HTTPS, que es la que se llevará la mayor parte del tiempo. Muchos creen que la mejor forma de evaluar un servidor DNS es ver la latencia hacia ellos, pero eso solo es un % del tiempo, lo que nos importa no es la latencia hacia el servidor DNS, sino el tiempo que va a tardar en respondernos con la dirección.

¿Cuanto es esta aportación a la latencia? Bueno, el mejor modo de comprobarlo es con pruebas reales. Para esta prueba se ha usado el servidor DNS de Google convencional 8.8.8.8, y por otro lado un resolver usando también el servicio DoH de Google, “https://dns.google.com/experimental”, en ambos casos deshabilitando todo tipo de cache

URL Servidor DNS 8.8.8.8 DoH https://dns.google.com/experimental
wikipedia.com 35ms 37ms
nic.es 31ms 39ms
facebook.com 11ms 38ms
google.es 32ms 42ms
theliel.es 32ms 38ms
twitter.com 12ms 38ms
elpais.com 38ms 40ms
microsoft.com 12ms 40ms
github.com 30ms 43ms
instagram.com 10ms 36ms

Los datos no son demasiado malos. Para dominios bien conocidos como Facebook, Twitter y otros, la latencia para resoluciones convencionales es mínima, ronda siempre los 10ms, mientras que el resto de hosts ronda una media de 33-34ms. Por contra, las resoluciones a través de DoH muestran un incremento claro, haciendo una media de 40-42ms. Estos resultados son simplificados y realizando medias entre 10 pruebas cada uno. En algunos casos existiendo gran variabilidad entre prueba y prueba.

 

El segundo inconveniente, es su soporte, su implementación. Mientras que el sistema DNS convencional está totalmente integrado en la propia estructura de Internet y podemos lanzar peticiones DNS desde nuestros equipos hacia cualquier servidor DNS, DoH es algo más complejo. Tal es así que actualmente requiere por un lado tener resolvers DoH, “servidores DNS” que sean compatibles con DNS Over HTTPS, que puedan traducir esas peticiones DNS encriptadas, resolverlas y devolvernos la dirección IP. Como es obvio, esos resolvers no elevan la petición DNS a servidores raíces por medio de DoH, sino por el modo convencional, pero esto no nos afecta, a menos que el resolver DoH fuese hackeado y guardase un registro de todas las peticiones realizadas. En todas las pruebas, en mi caso, he usado el servidor/resolver de Google DNS Over HTTPS que tienen habilitado: https:/dns.google.com/experimental.

Pero esto no es todo, así mismo requiere que los dispositivos sean compatibles también con DoH, ya sea a nivel integral en el propio OS, ya sea a nivel de aplicación. Esto es importante, porque como debemos de usar otro modo para realizar las peticiones DNS, requerimos de un software específico para ello, o que la aplicación esté preparada. En nuestro caso, por ejemplo, si usamos las últimas versiones de Firefox podemos habilitar el soporte para DoH de este, o podemos instalar un proxy en nuestro OS para que sea capaz de gestionar todas las peticiones DNS directamente de nuestra red.

En ambos casos, vemos que no es una opción que tengamos que habilitar si/no, requiere más que eso.

 

El tercer problema, y no menos importante, sea llama SNI. La idea detrás de DoH es cifrar las peticiones DNS, entre otras cosas para ocultar completamente los dominios que queremos visitar. El problema es que el uso de DoH no impida totalmente el “escape” de información que podemos tener referidos a los dominios visitados cuando son páginas webs HTTPS. Esto no es un problema de DoH realmente, sino del propio uso de los certificados digitales. Cuando realizamos una conexión HTTPS a cualquier host, el servidor remoto nos enviará en plano su certificado digital en el handbrake TLS. Los certificados digitales poseen una extensión llamada SNI, un campo que permite especificar los diferentes dominios para los cuales se aplica dicho certificado. Este campo no es obligado, es solo una extensión. Antes los certificados se emitían directamente para direcciones IPs específicas, pero con el agotamiento de estas ha sido cada vez más habitual que los servidores webs alojen bajo la misma IP muchas webs diferentes. Esto provoca que la emisión de certificados para una sola IP no sea viable, y se comenzó a usar SNI. Con SNI podemos especificar en el certificado los diferentes dominios, aun cuando todos ellos están bajo la misma IP.

El problema se ve claro, si un certificado que nos envía un servidor especifica el dominio para el cual ha sido emitido (el mismo), esa información también es potencialmente interceptable y usarla para conocer que hemos visitado dicho servidor. Eso no quiere decir que DoH sea inservible ni mucho menos. Para empezar un mismo certificado se emite muchas veces para diferentes dominios, así como consiguientes conexiones al mismo dominio tampoco requerirían de nuevo el certificado del servidor remoto. Otros servidores no usan siquiera SNI, y dentro de poco con la llegada de IPv6 es posible que en un futuro incluso sea común volver a certificados pre SNI, donde lo normal era su emisión para IPs.

Si un servidor nos responde con su certificado donde se especifica en SNI el/los dominios, nada evita que de nuevo se use software que rastree cada certificado que nos respondan los servidores remotos para hacer un perfil de nosotros de las webs visitadas. Pero estos sistemas al margen de ser más raros, tienen muchas limitaciones que de otro modo sería extremadamente sencillo tener un mapa completo del uso que hacemos en Internet, simplemente mirando las peticiones DNS.

 

El cuarto y último problema es que a veces falla. El software actual es limitado y tiene aun fallos que podemos encontrarnos, sin contar los problemas que pueden tener los resolvers actuales. Repito, todo esto es bastante nuevo, con lo que es de esperar algunos problemas, los más normales son resoluciones DNS que no son respondidas correctamente. Para atenuar esto, la mayoría de software cliente que existe permite configurar un servidor DNS convencional como fallover, en caso que DoH nos falle en alguna petición.

 

Como configurarlo

Bueno, por desgracia, y lo hemos visto en sus inconvenientes, no es algo que sea ejecutar y listo. Vamos a depender primero de un resolver DoH que actuará a modo de “proxy” entre DoH y peticiones de resolución DNS estándares. Cuando a estos resolvers les llegue una petición por DoH, la resolverán y nos la devolverán. Obviamente la confianza es esencial, a fin de cuentas que pasaría si dicho Resolver igualmente guardase una base de datos con las IPs originarias de las peticiones y una lista de los dominios accedidos.

Por otro lado como decíamos, requerimos de software o aplicaciones que sean capaz y compatibles con DoH. Ahora que es un estándar es de suponer que el soporte será ampliado enormemente, sobre todo en aplicaciones que nos gustan que sean seguras. Actualmente hay que decir que quedan cosas por pulir, el estándar DoH aun no ha sido alcanzado y algunas cosillas pueden cambiar. Algunos proveedores conocidos ya han lanzado resolvers DoH para poder ser usados de forma pública y gratuita, como Google o CloudFlare. Así mismo existen actualmente también la otra parte, software cliente para que podamos hacer uso de dichos resolvers. En este caso, quizás los dos casos más importantes en este punto sería el propio Navegador Web Firefox y DNSCrypt-Proxy. Al margen de ello, Google ya implementó DoH en Android también.

 

Firefox

El caso más básico y más sencillo de todos vamos a verlo con Firefox. Para ello necesitamos al menos Firefox 62, que si la memoria no me falla debería de estar ahora mismo en el canal Beta, Firefox 63 en Alpha. A partir de aquí es muy sencillo. Por defecto el soporte para DoH viene deshabilitado, ya que es un cambio importante. Básicamente necesitamos sólo realizar un par de ajustes en el editor de configuración. Para quien no lo conozca, el editor de configuración de Firefox se accede desde la barra de direcciones accediendo a: about:config.

 

network.trr.mode: (el modo de funcionamiento de DoH)

0: Deshabilitado
1: Usa ambos modos, DoH y resoluciones convencionales, el navegador usará la que resuelva antes
2: Usa DoH de forma predeterminada, y DNS convencionales como fallover
3: Usa solo DoH
4: Lanza ambas peticiones, pero solo usa las resoluciones convencionales.

network.trr.uri: (URL del resolver a usar)

Google: https://dns.google.com/experimental
CloudFlare: https://cloudflare-dns.com/dns-query
Mozilla/CloudFlare: https://mozilla.cloudflare-dns.com/dns-query

network.trr.bootstrapAddress: (opcional)

Si forzamos el uso del modo 3, como en mi captura, es necesario especificar la dirección IP del resolver. No podemos usar DoH sin conectarnos al resolver, con lo que necesitamos su IP, pero si forzamos usar solo DoH entramos en un bucle del que no salimos. De este modo preestablecemos la IP del resolver. No se requiere para el resto de los modos.

 

Hay muchos modos para conocer si DoH está funcionando en nuestro equipo. Un modo sería consultar la página de estado de Firefox sobre las peticiones DNS:

about:networking#dns

Podemos localizar la columna TRR y ver si para dicha resolución se está usando DoH o no.

Otra opción es usar un analizador de paquetes, y comprobar que no aparece tráfico DNS, al menos generado por el navegador web.

 

DNSCrypt-Proxy

DNSCrypt-Proxy es un proyecto de código abierto y multiplataforma. Actúa básicamente como un proxy que toma las peticiones DNS convencionales y las envía a un resolver por DoH. El proyecto lo tenemos en Github.

DNSCrypt-Proxy no es para nada nuevo, pero si ha sido recientemente cuando han añadido soporte para DoH. Anteriormente funcionaba con DNSCrypt de OpenDNS, de ahí su nombre, pero actualmente es compatible también con resolvers DoH. Este software es muy interesante porque nos permite pasar por ejemplo todas nuestras peticiones DNS (de todo el equipo, con independencia de que aplicación se use) a DoH. O mejor aun, si lo instalamos y configuramos en un Router, podemos asegurar directamente toda la red local, haciendo que absolutamente todas las peticiones DNS pasen por él. Esta última alternativa sería la ideal en entornos domésticos, pero ojo, de hacerse así no nos protegería de terceros conectados a nuestra red local, ya que las peticiones que se enviasen de nuestros equipos al Router si serían resoluciones DNS convencionales, sería el Router quien las convertiría en peticiones DoH y las enviaría hacia fuera.

En mi caso he optado por este último esquema, configurarlo directamente en el Router y no tener que tocar absolutamente ningún equipo ni dispositivo de mi red. El como hacer esto, es algo ya más complejo y que excede el artículo original. Para poder instalarlo en un Router se debería de descargar los binarios precompilados (o compilarlos) para nuestro dispositivo, crear la configuración necesaria, crear scripts para levantar los servicios… y como último paso decidir si queremos añadir reglas en iptables para forzar las peticiones DNS enviadas a servidores externos ser tratadas también de forma interna. En mi caso, y por cuestiones varias, prefiero no forzar las peticiones DNS externas. Es decir, que si alguna aplicación lanza una resolución DNS hacia un servidor DNS específico que no sea mi Router, serán convencionales, si usa las DNS del sistema, usará el Router y por ende irán bajo DoH.

La mejor forma de ver si funciona en este caso, es colocar un analizador de paquetes en la interfaz WAN PPPoE del Router, y capturar las peticiones DNS.

Esta primera prueba lanza una petición DNS a los servidores convencionales de google, 8.8.8.8. Dig es lanzado desde cualquier equipo de la red, tcpdump desde el Router:

dig theliel.es +noall +answer +stats @8.8.8.8

theliel.es. 599 IN A 188.121.46.128
;; Query time: 50 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Jul 20 18:19:02 Hora de verano romance 2018

tcpdump -i ppp0 udp port 53

16:19:02.137737 IP xxx.red-xxx-xxx-xxx.dynamicip.rima-tde.net.57185 > google-public-dns-a.google.com.domain: 14372+ [1au] A? theliel.es. (51)
16:19:02.384289 IP google-public-dns-a.google.com.domain > xxx.red-xxx-xxx-xxx.dynamicip.rima-tde.net.57185: 14372 1/0/1 A 188.121.46.128 (55)

Esto es el comportamiento normal, tcpdump está escuchando el tráfico en el puerto 53 que es por donde se realizan las peticiones DNS, y por tanto no solo registra la petición DNS realizada con Dig, sino que además incluso nos muestra directamente tanto la petición como la respuesta del servidor de Google.

Esta segunda prueba lanza la misma petición, pero esta vez usando los servidores DNS predefinidos por el servidor DHCP del Router (el mismo Router), que a su vez enviará las peticiones hacia el resolver configurado en DNSCrypt-Proxy:

dig theliel.es +noall +answer +stats

theliel.es. 573 IN A 188.121.46.128
;; Query time: 43 msec
;; SERVER: 192.168.2.1#53(192.168.2.1)
;; WHEN: Fri Jul 20 18:25:49 Hora de verano romance 2018

tcpdump -i ppp0 udp port 53

tcpdump -i ppp0 tcp port 443

16:28:41.849811 IP xxx.red-xxx-xxx-xxx.dynamicip.rima-tde.net.57197 > mad07s09-in-f14.1e100.net.https: Flags [P.], seq 8119:8303, ack 48627, win 4006, options [nop,nop,TS val 16309141 ecr 1452692457], length 184
16:28:41.859322 IP mad07s09-in-f14.1e100.net.https > xxx.red-xxx-xxx-xxx.dynamicip.rima-tde.net.57197: Flags [.], ack 8303, win 1050, options [nop,nop,TS val 1452694899 ecr 16309141], length 0
16:28:41.881146 IP mad07s09-in-f14.1e100.net.https > xxx.red-xxx-xxx-xxx.dynamicip.rima-tde.net.57197: Flags [P.], seq 48627:48721, ack 8303, win 1050, options [nop,nop,TS val 1452694921 ecr 16309141], length 94
16:28:41.881295 IP mad07s09-in-f14.1e100.net.https > xxx.red-xxx-xxx-xxx.dynamicip.rima-tde.net.57197: Flags [P.], seq 48721:48811, ack 8303, win 1050, options [nop,nop,TS val 1452694921 ecr 16309141], length 90

En este caso, a pesar de que Dig lanzó la petición DNS y quedó resuelta correctamente, tcpdump no es capaz de detectar tráfico por el puerto udp 53. Para poder “capturar” el tráfico, tendríamos que escuchar con tcpdump en el puerto TCP 443, como podemos ver… o no ver, porque el tráfico va encriptado, como mucho podemos saber que se está lanzando tráfico https a un servidor de google, pero imposible saber de que se trata, y menos aun pensar que es tráfico DNS.

 

Conclusiones

Es muy interesante que por fin tengamos un sistema fiable (y más importante, usable) para el cifrado DNS, y que por supuesto esté siendo estandarizado. Mozilla se ha puesto a trabajar duro en ello, Google está dando pasos agigantados también en la misma dirección, con lo que es de esperar que el resto se vayan uniendo a la fiesta. Esto no quiere decir que en dos días, un mes o un año todo el tráfico DNS irá cifrado, ni muchísimo menos. Del mismo modo que desde hace años disponemos de DNSSec, lo cierto es que solo un % pequeño lo usa, la mayoría de las Webs tampoco están adaptados para esto. DNS no se puede sustituir, pero si podemos imaginar que cada vez más servidores DNS convencionales permitirán su uso como resolvers DoH. Esto, sumado a que puede ser incorporado de forma transparente en las aplicaciones que se requieran, hace previsible su uso en muchos campos.

De los modos sistemas mostrados aquí, posiblemente para el usuario normal el que puede empezar a usar si así lo quiere es a través de Mozilla Firefox. Que yo sepa, a día de hoy Chrome no puede configurarse de un modo similar, pero es solo cuestión de tiempo, si es que no se puede ya. Esto no nos protegerá la red de nuestra casa, pero si todo el tráfico que generemos desde el navegador.

Para quien quiera aventurarse un poco más, puede instalar en local DNSCrypt-Proxy y configurarlo en su equipo para aplicarlo de un modo integral a su propio equipo, y por último, los más osados, pueden hacerlo en el Router, y afectar a todo el tráfico que genere nuestra red local.

Esto no va a saltarse de golpe todos los bloqueos existentes, no va a hacer que nadie bajo ningún concepto pueda saber las direcciones que visitamos, pero sin duda alguna es un plus muy importante a nuestra privacidad, sobre todo si tenemos un portatil o un dispositivo móvil el cual usamos en redes de datos de los ISP o en redes WIFIs públicas o que no controlamos, es aquí donde la configuración por aplicación es igualmente importante. Es decir, ya se use en el Router o en las propias aplicaciones, un uso no sustituye el otro.

Los problemas de rendimiento están presentes, no podemos engañarnos, pero es cierto que la inmensa mayoría de las veces son imperceptibles, y solo de cuando en cuando notamos realmente un “parón” en la resolución DNS y tarda algo más de lo habitual. Pero el 99% del tiempo no notaremos ninguna degradación.

Hay que entender que de cualquier modo todo es muy experimental, el estándar no se ha terminado de aprobar y algunas cosas aun cambiarán, por suerte para mejor con seguridad.

Saludos.

Vuelve a pasar, “un carácter de la muerte” vuelve a los equipos de Apple

Para quien no esté al corriente de otras ocasiones, digamos que actualmente cualquier dispositivo de Apple (iOS o MacOS) por actualizado que esté (excepto versiones betas) provocará el cierre/bloqueo de la aplicación si esta tiene que renderizar un carácter concreto. En este caso es un carácter Telegu, un dialecto Indio: జ్ఞ‌ా

Sí, eso significa que incluso este mismo post producirá el bloqueo/cierre de la aplicación que lo abra en los dispositivos de Apple. Pero esto no es nuevo. Hace ya algunos años pudimos ver algo similar, aunque en aquella ocasión era más bien una cadena de texto: “سمَـَّوُوُحخ ̷̴̐خ ̷̴̐خ ̷̴̐خ امارتيخ ̷̴̐خ”. Ya en su día escribí un pequeño artículo al respecto:

La Cadena de la Muerte

La historia es la misma, de echo todo lo que puse en ese post se podría volver a poner aquí. La única salvedad es que en esta ocasión es un carácter, en vez de una pequeña cadena.

Vemos fallos de seguridad y bugs a diario, nadie se salva de ellos. La mayoría no suelen tener una gran transcendencia por grave que sean debido a que explotarlos es algo complicado. Es aquí donde este tipo de errores alcanza una importancia capital, aunque sea algo inocuo y que no afecte demasiado. Es decir, para que un fallo de seguridad o un bug sea realmente importante se deben de dar una de estas dos premisas: O que el grado de peligrosidad, a lo que afecta, sea enorme aunque sea muy complicado usarlo, o que con independencia de lo peligroso que sea, sea extremadamente sencillo disparar el fallo.

Algo similar vimos hace poco cuando se descubrió que cualquier usuario de MacOS podía resetear la contraseña de administrador de forma extremadamente sencilla, sin conocerla, sin tener los credenciales necesarios. En dicho caso, la peligrosidad, al margen del efecto logrado, es que era algo tan simple como hacer clic dos veces en un botón.

Vivimos ahora mismo en el mundo de las comunicaciones. Es más, la mayoría que lea este artículo lo hará posiblemente desde un teléfono. La mayoría del tiempo que pasamos con nuestros dispositivos es usando aplicaciones de mensajería instantánea, redes sociales, webs… es decir, precisamente los vectores por donde cualquiera, repito cualquiera, podría usar dicho carácter. Muchos podrán pensar que bueno, es cuanto menos “divertido” pero realmente no tiene mucha importancia, quien ha visto alguna vez ese carácter, y que en nuestros círculos no va a suceder. El problema es que mientras que Apple lance la actualización o no, y más sitios se hagan eco, más copias de dicho carácter veremos, en todos lados.

Usas WhatsApp?? No importa, como alguien lo use de esto, los usuarios de iOS que lo tengan a él en la agenda y vea la lista de estos no podrán abrirlo. Y en grupos?? Prueba y verás la gracia. No es peligroso desde el punto de vista que no van a robarte información ni acceder a ella, ni van a producir un daño a tu dispositivo irreparable, ese no es el problema. El problema es que sencillamente cualquiera puede dejarte inutilizada la mayoría de aplicaciones que se usan a día de hoy, ya sea por diversión, a modo de prueba…

Actualmente, como he dicho, no hay solución. Sólo la versión Beta de iOS última parece solucionarlo. Pasarán posiblemente días o alguna semana antes de que Apple lance una actualización formal. Quien use Apple, no puede protegerse de otro modo, en todo caso actuar si se ha recibido el carácter o hay sospecha de ello. Dependiendo del medio, tendrá que realizar diferentes acciones. Así por ejemplo si el carácter lo recibió por Safari al acceder a una web, tendrá que evitar dicha dirección, e incluso a lo mejor necesario eliminar del historial la página. Si es por WhatsApp en un estado, eliminar a dicho contacto, si es en un mensaje, eliminar dicho mensaje o incluso es muy posible que eliminar el historial de dicho contacto, o todo el historial… etc etc etc.

Así que amigos manzaneros, cuidado, si estos días el terminal se bloquea en algunas aplicaciones, cierres forzados de estas, congelaciones… puede ser que algún bromista (me declaro culpable de serlo también) esté causando estragos en tu dispositivo. Pero antes de las consabidas críticas, tener presente algo: No justifico en modo alguno quien lo haga de forma lesiva o para molestar o producir mal a otros, pero en el peor de los casos pensar que es como darle un caramelo a un niño pequeño, si se lo das se lo va a comer, lo que tendría que tener más cuidado Apple (o los padres) es que estos escenarios no vuelvan a producirse, que con este ya son 3-4 las veces que ha sucedido.

¿Y por qué sucede? Es por el modo que Apple renderiza las fuentes. Mientras no se cambien o al menos modifiquen como interacciona con el sistema, es muy posible que antes o después vuelva a aparecer otro “carácter” o frase o… y que la historia, de nuevo, vuelva a repetirse.

Saludos.

¿Un fallo de seguridad en High Sierra (MacOS) permite acceso Root a cualquiera? Sí, y más simple imposible

Generalmente no suelo hacer eco de estas noticias a menos que el fallo de seguridad (o el exploit) tenga una relevancia/peligrosidad tan elevada. Y es que creo que a estas alturas el que más o el que menos (y si tiene High Sierra espero que seguro) que esté en el “mundillo” habrá escuchado las noticias por todos lados. Sinceramente, creo que nos tenemos que remontar a la famosa “Cadena de la Muerte“, en 2013, para encontrar algo tan flagrante, y en esta ocasión Apple se ha superado, lo ha logrado, nadie lo sabe bien pero lo ha conseguido, basta invocar la cuenta Root en el sistema para que este la cree en ese momento y le asigne una contraseña en blanco. Dicho de otro modo, si cualquiera se pone delante del sistema tenga la cuenta que tenga e intenta entrar/usar el usuario “root”, sin especificar ninguna contraseña, al segundo intento generalmente entra (El primero la crea, el segundo accede).

Bien, no hace falta decir que el usuario root es por lo general la cuenta/usuario maestro en casi todos los sistemas UNIX/Linux, el super administrador. Es decir, que como tal usuario tendremos acceso total al sistema. La cosa es aun peor, porque si el equipo tiene habilitados servicios de acceso remoto, la gracia se puede mascar en el aire.

No es un exploit remoto que permita ejecución arbitraria de código, es un bug en principio con alcance local, y como tal requiere acceso físico al equipo. No obstante a nadie se le escapa la gravedad del asunto. Para usuarios particulares que usen el equipo en entornos digamos de confianza o familiares o… generalmente no va a suponer un gran problema si los que nos rodean tenían acceso igualmente al equipo de forma indiscriminada, pero en entornos más empresariales, equipos portátiles que en cualquier momento puede ser “dejado” en cualquier lugar, el problema no tiene parangón.

La cosa es aun peor, y es posiblemente una de esas políticas que tanto tiempo llevo recriminando a Apple con más intensidad. La falta de actuación y transparencia. Este fallo no ha sido descubierto hoy, Apple lleva tiempo con conocimiento de ello. Es más, hace más de dos semanas se comentaba abiertamente en los foros de soporte, e incluso por lo que dicen, se daba como solución a usuarios que necesitaban acceder a sus propios equipos como Root. En cambio, como siempre, silencio. Hoy, por el motivo que sea a saltado a la prensa, y nos hemos enterado la mayoría (personalmente no tenía constancia de ello), y como Apple hace siempre, es cuando lanza un comunicado diciendo que tendrán la actualización lista para solucionarlo “pronto”. No dudo en absoluto que lo solucionen pronto, eso no me preocupa, ni siquiera en realidad este bug por grave que sea, lo que me preocupa es la falta de inacción por parte de Apple, y que sólo se pone las pilas cuando el problema se escala a los medios de comunicación. La “cadena de la muerte” estuvo funcionando durante semanas sin que se solucionase incluso siendo ya un “vox populi”. Dicho de otro modo… si algo tan sencillo y tan absurdo como este bug (y tan grave) lleva semanas rondando por los foros oficiales de Apple y no han hecho nada, ¿qué exploits/bugs habrá en la trastienda (con conocimientos o sin ellos por parte de Apple) que no conocemos?

Siempre he dicho y “defendido” el error humano. Nadie es perfecto y todas las empresas cometen errores, y de todos los tamaños por cierto. A veces esos errores son tan tontos como es este caso y otras veces la gran genialidad de expertos de seguridad logran meterse en los resquicios más insospechados para hacer saltar un sistema. Esto sucede constantemente y no pasa nada, lo asumimos y lo aceptamos porque en cierto modo nos fiamos de los desarrolladores que, en función de la gravedad y la importancia, tal como los problemas vayan apareciendo, se irán solucionando de igual modo. Puedo perdonar a Apple de que alguno de sus programadores haya metido la pata hasta donde la ha metido, lo que no puedo perdonar es que la vulnerabilidad lleve circulando semanas por su propio foro, y no haya dicho ni hecho absolutamente nada. Eso sí, hoy que salta la noticia a la prensa es cuando se mojan. Deleznable.

La cadena de texto “de la muerte” de iOS y OSX: سمَـَّوُوُحخ ̷̴̐خ ̷̴̐خ ̷̴̐خ امارتيخ ̷̴̐خ

Por desgracia no he tenido tiempo antes para hablar sobre la ya famosa “cadena de la muerte” que afecta a los productos de Apple, así que aprovecho para dedicarle unas cuantas letras a ello, puesto creo sin duda alguna que merece la pena por lo absurdo del caso. Pero antes que nada hagamos un poco de recapitulación para aquellos que no saben nada de ello.

¿Algún usuario de iPhone ha observado últimamente que sus aplicaciones se cierran sin mucho sentido?

Hace ya más de 6 meses, expertos de seguridad reportaron a Apple un fallo crítico en sus sistemas operativos, tanto iOS como OSX, afectando en ambos casos incluso sus versiones más actuales. El fallo provoca un ataque de denegación de servicio (DoS) producido por el motor de renderizado de texto del sistema operativo ante una cadena unicode concreta: “سمَـَّوُوُحخ ̷̴̐خ ̷̴̐خ ̷̴̐خ امارتيخ ̷̴̐خ”. En términos profanos, cada vez que cualquier dispositivos de Apple (iPhone, iPod Touch, OSX…) tiene que renderizar (dibujar/interpretar) en pantalla dicha cadena de texto (pues usa el motor de texto del OS), la aplicación que esté en primer plano que esté accediendo a dicho texto se cerrará. Si mandamos un WhatsApp con dicha cadena, el usuario de iOS no podrá abrir WhatsApp (por poner un ejemplo sencillo)

En primer lugar, encontrar un fallo en cualquier aplicación que pueda producir un DoS en ella, no es algo demasiado extraño. Encontrar un fallo en un OS que pueda producir un DoS en él es algo que suele ser mas extraño pero todos los años solemos tener unos cuantos. Lo que realmente hace peculiar este fallo (y de ahí su gran importancia) es el método para “dispararlo”, puesto que tan solo es necesario una sencilla cadena de texto unicode que cualquiera puede enviar, copiar/pegar… o hacer el uso que sea de ella. No es necesario dispararlo por medio de un exploit complejo, no es necesario un conocimiento avanzado informático, no es necesario ser un experto… cualquier persona puede producirlo en un dispositivo objetivo, sencillamente haciendo llegar al objetivo dicha cadena de texto. Tan simple como eso.

En segundo lugar, otra cosa que hace de este fallo crítico en los productos de Apple algo tan severo, es la inacción por parte de Apple (como de costumbre) ante un fallo de seguridad o de cualquier otra índole en su software y sistema operativo. El error fue reportado hace más de 6 meses, 6 meses en los que cualquiera ha podido estar explotando dicha vulnerabilidad a su antojo. Pero aun peor que todo ello, es que después de que hace una semana saltara en todos los medios de noticias, Apple sigue sin hacer absolutamente nada, siendo afectados todas las versiones de iOS (exceptuando la beta de iOS 7) y prácticamente todas las versiones de OSX.

Para cualquier usuario de iOS (y mayoría de OSX) no pueden hacer sencillamente nada. Si el texto es puesto en cualquier sitio y sus dispositivos lo reciben, la aplicación que lo muestre en pantalla se cerrará sin remedio alguno. Esto es un problema, porque incluso el simple echo de escribir un artículo con ello, provocará que a los usuarios de iOS/OSX se les cierre el navegador web si abren mi blog. Para tener constancia de la gravedad de ello, voy a exponer unos sencillos ejemplos y el efecto que tendría en los dispositivos de Apple. Otro gran problema de todos los ejemplos que veamos, es que el usuario de Apple ni siquiera será consciente de que ha pasado o porqué sus aplicaciones no funcionan correctamente.

-En una página web

El navegador del dispositivo se cerrará cada vez que se intente acceder a dicha web, puesto que la cadena de texto hará por mostrarse en él. La única solución pasa por no acceder a dichas webs, lo cual es complicado, cualquier webmaster podría poner la cadena de texto en cualquier parte de su web/blog/foro… En este caso el ataque sería indiscriminado, no iría dirigido concretamente a nadie.

-En un correo electrónico

En el caso sencillo, bastaría incluir la cadena de texto en el cuerpo de cualquier correo electrónico dirigido a cualquier usuario de Apple. Este al abrir dicho corro provocará que el gestor de correo electrónico o el navegador web (en caso de acceso por web) se cierre.

Un caso más maligno de este sería usar dicha cadena de texto como asunto y no como cuerpo de mensaje. En este caso, dado que los gestores de correo y los webMail tienen a mostrar directamente el asunto del mensaje SIN NECESIDAD de abrir el correo, sería suficiente de nuevo para provocar el cierre del navegador web o del gestor de correo.

Usado de forma “maligna”, cualquier usuario de forma muy muy sencilla podría dejar inutilizable de un modo efectivo el gestor de correo de los usuarios de iOS o de OSX (puesto que por lo general el asunto se muestra directamente lo cual provocaría el cierre de la aplicación), y de forma menos agresiva también el navegador cuando se acceda por webMail

En este caso, tan solo sería necesario conocer el correo electrónico del usuario al que dirigirse.

-Facebook, Twitter, Google+…

Independientemente de si se accede a estas aplicaciones desde una aplicación móvil o desde el navegador, parece evidente pensar que pasaría si se publicase en las redes sociales dicha cadena de texto, y el efecto que tendría a todos los usuarios de Apple. Este pensamiento no son pocos los que lo han tenido… y muchos los que lo han hecho. Así pues, son muchos los que han twitteado el mensaje, haciendo que a los usuarios de Apple les fallase tanto la aplicación como e navegador web al intentar visualizar dichos Twitts.

En caso de Facebook, estos bloquearon prudentemente la posibilidad de poder escribir dicha cadena de texto de forma directa, pero existen multitud de formas de evadir este sistema, como por ejemplo estableciendo manualmente como ubicación de la publicación la cadena de texto, pero las opciones son múltiples. La cuestión siempre es la misma, cuanto más ingenioso se sea a la hora de exponer la cadena de texto…

En este caso, se podría usar las redes sociales sin tener un objetivo concreto, o por supuesto bastaría con poder enviar un mensaje o publicar lo que fuese en el perfil del usuario.

-HangOut, SMS, WhatsApps…

A nadie se le escaparía tener en cuenta la mensajería instantánea y los SMS. En estos casos posiblemente el vector de ataque sería mucho peor.

En el caso de los SMS el daño a provocar es evidente, tan solo basta con mandar un SMS a cualquier iPhone para bloquear de forma sencilla la aplicación iMessage del dispositivo. Si la aplicación realiza un pequeño preview del texto maligno, será suficiente para provocar el cierre de la aplicación, y de volver a intentarlo el resultado sería el mismo. En este caso tan solo sería necesario tener el número de teléfono de la persona a afectar.

En el caso de WhatsApp las opciones son múltiples. En primer lugar sería suficiente con mandar un WhatsApp a cualquier dispositivo. Esto provocaría que al abrirse (o incluso en la previsualización) fuese suficiente para provocar la inutilización de WhatsApps. El usuario se vería forzado a tener que reinstalar WhatsApps en algunos casos. Otra opción de WhatsApps sería establecer el texto como mensaje de estado, un sistema pasivo que provocaría que cualquier usuario que nos tuviese en su lista de contactos (usuario de iPhone) no pudiese acceder a su lista de contactos, puesto que cargaría nuestro estado y de este modo WhatsApp se cerraría. Como tercera opción en WhatsApp, y la más efectiva, pasaría por crear un grupo de WhatsApp y establecer en su nombre el texto dañino. Dado que los grupos se regrean aun cuando WhatsApp se reinstala, a cualquier atacante le bastaría el número de telefono de cualquier usuario con iPhone para crear un grupo de WhatsApp, establecer el nombre a la cadena de texto dañina y añadir a dicho miembro al grupo. Dado que el nombre del grupo es visible en la lista misma de WhatsApp, el usuario de iPhone no podría abrir WhatsApp, y aun cuando reinstalase los grupos se recrearían igualmente, haciendo muy complicado evitarlo. De este modo se quedaría totalmente inutilizada la aplicación, se cerraría nada más abrirla constantemente.

En realidad, cualquier sistema de mensajería instantanea los efectos serían similares. La diferencia quizás radica en quien puede o no mandarnos mensajes. En el caso de los SMS por ejemplo, cualquiera con nuestro teléfono puede mandarnos uno. En caso de WHatsApp cualquiera con nuestro número puede hacerlo… esto hace de este fallo de Apple un problema en mayúsculas sin duda alguna.

 

Podríamos expandir la lista todo lo que quisiésemos. Desde establecer el SSID de nuestra red WIFI al texto en cuestión y ver que le ocurre a los iPhone cercanos, códigos QR, firmas… en realidad cualquier sitio donde podamos escribir un texto en unicode y que vaya a ser leído por el usuario en sus pantallas.

Lo peor de todo ello como ya he dicho, es que al contrario de otros fallos de seguridad, en este caso puede dispararse el error sencillamente con una cadena de texto, lo cual no solo hace que el vector de ataque sea increiblemente grande, sino que cualquiera puede explotar esta vulnerabilidad. Si a eso le sumamos que Apple continúa sin solucionar este problema que se conoce desde hace más de 6 meses…

Cada cual que haga sus propias conclusiones… o pruenas

Un saludo amigos, y ser buenos… no seamos demasiado… “traviesos” con los fanboys 🙂

Evento de Google del 24 Julio: Nuevo Nexus 7, Android 4.3 y Nuevo dispositivo ChromeCast

El Google IO 2013 dejó claro que iba a ser orientado casi en su totalidad para los desarrolladores, y quitando Play Services no se anunció ningún producto ni actualización de los ya existentes. Quizás el motivo fuese que este año el Google IO se celebró casi un par de meses antes que el año pasado. Dicho así, era lógico pensar como dijimos muchos que Google lanzaría novedades en Julio, y así han sido. Fundamentalmente han sido 3 novedades en las que se ha centrado toda la conferencia: El nuevo Nexus 7, Android 4.3 y como sorpresa ha sido un dispositivo que han bautizado como “ChromeCast”.

Por supuesto, Google a aprovechado para recordar que las ventas de este último año de Android son superiores al doble del año pasado, que el dinero que se ha pagado a los programadores de aplicaciones estos últimos meses es de 2.5 veces superior al año pasado. Realmente no son números para obviar.

 

Nexus 7

Hace un año Google presentó el que sería el primer Tablet con su sello, el N7. A día de hoy ha resultado ser un éxito indiscutible, un hardware más que capaz a un precio que la competencia podía siquiera acercarse. Un año más tarde, era evidente que Google tenía que mejorarlo… y así ha sido.

-Mismo tamaño, 7,02 Pulgadas, pero no obstante se pone a dieta, ahora es ligeramente más estrecho (conservando el mismo tamaño de pantalla), un pelín mas alto, pero sobre todo más delgado y pesando menos.

-Pantalla FullHD! Si el N7 original ya tenía una gran pantalla HD Ready de 1280×800 con 216ppp, han dado un salto significativo al emplear una pantalla FullHD de 1920×1200, con 323 ppp. Es interesante anotar que Apple llamó originalmente “Pantallas Retinas” a cualquier pantalla con una densidad superior de 300 ppp porque según ellos el ojo humano no era capaz de percibir algo mejor. El iPad 4 actual, llamado retina, posee una densidad de 264 ppp (lo que estrictamente según la definición que Apple daba a sus pantallas Retina, no es Retina). Bien, pues como digo el nuevo N7 tendría una densidad de 323 ppp (El N10 actual posee 300 ppp).

-Incorporación de cámara trasera de 5MP: Muchos se quejaron inicialmente por no poseer una cámara trasera (yo personalmente es algo de lo que podría prescindir, quiero una cámara frontal para videoconferencia, pero no voy a ir haciendo fotos con un tablet). Aun así han implementado una cámara de 5MP traseras para completar aun más el dispositivo.

-CPU/GPU: También se ha modificado el Procesador, y se ha implementado el mismo que usa actualmente el Nexus 4, un SnapDragon Pro 8086 de 4 núcleos a 1.5 GHz, frontera con los Cortex-A15. Según afirma Google, el procesador sería aproximadamente un 50% superior a su predecesor, y hasta un 150% superior que su predecesor gráficamente, en conjunción de Adreno 320. Es decir, que no solo de pantalla vive el hombre. Esto es totalmente lógico. Muchas veces se olvida que el poseer una pantalla con mayor resolución implica tener que trabajar el procesador y la GPU mucho más. No es el caso, pero muchas veces incluso aun aumentando el procesador y la GPU un producto nuevo puede ser más lento que su antecesor por tener una pantalla superior.

-Batería: No tengo los datos de capacidad de la batería actualmente, creo qeu es la misma que su antecesor, pero han mejorado el consumo. Según claman, es capaz de estar reproduciendo sin parar durante 9 horas seguidas contenido en HD.

 -Por último, posee conector HDMI para su conexión a la televisión.

Si lo comparásemos actualmente con el iPad Mini, esto es lo que tendríamos:

Nexus7

El Nexus 7 anterior, que salio a la venta 6 meses antes que el actual iPad Mini, ya era superior al iPad Mini, con lo que es evidente decir que el actual Nexus 7 es muy superior al iPad Mini actual, y posiblemente lo sea al iPad Mini nuevo que saque Apple este año (si lo saca). Lo Cuadriplica en RAM, lo duplica (que se dice pronto) en densidad de píxeles!! Si pusiésemos una foto de calidad en ambos dispositivos, la calidad de la imagen en el iPad mini sería de chiste en comparación. Repito, es evidente que el iPad Mini actual tiene ya algo más de 6 meses y habrá que esperar al nuevo para realizar otra comparación más, aunque en ese caso será el iPad mini el que lleve una ventaja de 6 meses.

 

Android 4.3

Google está tardando en lanzar su Android 5.0 (Lime Pie), es posible que para que la gran mayoría de dispositivos Android estén usando JellyBean, y lo cierto es que a día de hoy ya se ha confirmado que JellyBean posee una penetración superior a GingerBread, que ostentaba el mayor uso. Eso no quiere decir que Google esté parado, y estoy seguro que Android 5.0 está más que avanzada y casi preparada, y todo el tiempo de más que se le de será para mejorarla aun más. Mientras tanto, mientras que eso ocurre (supongo que se lanzará en Noviembre), Google ha añadido algunas mejoras en Android 4.3, sin realizar cambios demasiado dramáticos. De echo para el usuario final, no notará prácticamente nada nuevo, que no quiere decir que no las use sin saberlo o que no se beneficie de las mejoras.

Google Play Game App: En realidad no forma parte de Android 4.3, pero si de android, y está disponible para todos. Es la aplicación de Google que hará de hub par alos juegos, para centralizar de este modo los progresos de ellos, tablones de puntos, logros… cualquiera puede descargarla si lo desea desde ya.

– Control de permisos para Tablets con múltiples usuarios: Recordemos que Android en las tablets posee (tiene la opción) de tener diferentes perfiles de usuarios desde hace tiempo. Así por ejemplo dos personas podrían tener sus configuraciones totalmente diferentes. Bien, la gran novedad es que podrá existir lo que llamaríamos un “Administrador” que podrá definir el control de acceso y permisos que tendrá otro usuario. Así por ejemplo, no solo podrá definir a que aplicaciones tendrá acceso o no el otro usuario, sino que incluso podrá definir algunos permisos por aplicación incluso. Esto evidentemente está enfocado para tablets como el N7 orientadas a un público más juvenil. Básicamente, estoy viendo al Padre impidiendo que el hijo acceda a juegos que el si puede, películas que el padre no quiere que vea… o simplemente facilitarle el uso al pequeño quitandole todo aquello que él no entendería.

-Soporte para Bluetooth 4.0 Smart, un tipo de dispositivos Bluetooth de muy bajo consumo, generalmente dispositivos biométricos que envían constantemente datos a nuestro dispositivo Android. Básicamente aquellos dispositivos que sean compatibles con BT Smart tendrán un consumo energético mínimo.

-Perfil de Bluetooth AVRCP en su stack de BlueTooth, lo cual permite el control remoto de video y audio por Bluetooth en dispositivos compatibles.

-Soporte para OpenGL ES 3.0: Es otra de esas grandes novedades que solo los programadores apreciarán, y es una sorpresa. OpenGL es junto DirectX las API gráficas más comunes que existen en el mundo. DirectX solo es para Windows por supuesto, mientras que OpenGL posee un soporte completo tanto en Windows,  móviles, Linux, OSX, iOS… OpenGL ES epor otro lado es por así decirlo la adaptación de la API OpenGL en dispositivos portátiles, es un subconjunto de OpenGL.  OpenGL ES 3.0 es la versión más actual, y no hace falta siquiera decir que ni iOS ni Windows Phone son compatibles, incluso el nuevo iOS 7 que aun no ha salido, tan solo es compatible con OpenGL ES 2.0, que es lo que usan el 99% de todos sus juegos. ¿Esto que implica? Implica mejores efectos y realismo en juegos, más facilidad a la hora de programar y mayor rendimiento en cualquier aplicación que haga uso de OpenGL.

-APIs para DRM: En realidad Google lo ha tenido bien organizado todo, y con el lanzamiento del nuevo Nexus 7 con pantalla 1080p y el nuevo dispositivo que hablaremos más adelante, se ve que implementar medidas DRM para películas sobre todo era casi una obligación, que por cierto seguro les ha hecho poner proveedores de películas como Netflix.
 
-Mejoras en la introducción de teclado, posiblemente alguna versión nueva de su teclado para Android, me pregunto si habrán dado ya acceso al selector de temas del teclado que sabemos ya incorpora desde hace tiempo.
-Mayor rapidez en el cambio rápido de usuario (para tablets multiusuarios)
 
-Autocompletado al marcar un número. La mayoría de todos los dialers que traen por defecto los dispositivos Android de los fabricantes poseen este tipo de dialers, en los que puedes llamar escribiendo el nombre o empezando a poner el teléfono. Por fin Google lo implementa, espero que permita también la búsqueda por nombre.
 
-Mejora de la localización WIFI en segundo plano… lo cierto es que no sé exactamente que se han referido con esto, habrá que diseccionar el código fuente y ver los cambios reales al respecto.
 
-Incorporación del hebreo y el árabe (idiomas de escritira inversa) y otros idiomas.
 
En realidad no son cambios de calado, pero si desde luego Google quiere cubrir algunos puntos más deficitarios en su Nexus 7, e incorporar mejoras significativas a los programadores. El precio en cambio es ligeramente superior. En realidad era algo que se veía venir, Google lo iba a tener realmente complicado mejorar los 200€ que costaba el Nexus 7 anterior. Aun así se ha acercado bastante, teniendo en cuenta que en cuanto a hardware hay un gran cambio significativo, posiblemente solo la pantalla ya fuese suficiente para entender ese precio adicional.
 
La OTA para Nexus 4, Nexus 7, Nexus 10 y Galaxy Nexus está ya circulando, así como las imágenes completas de todos ellos en el centro de siempre
De igual modo, los repositorios oficiales AOSP de Google están también terminando de ser rebasados con Android 4.3, lo que significa que cualquier ROM personalizada basada en AOSP será actualizada en los próximos dias (seguramente claro, y siempre que así lo deseen)
 
 

ChromeCast

El invitado especial en esta ocasión ha sido ChromeCast. El año pasado vimos en el lanzamiento del Nexus 7 el novedoso e ingenioso Nexus Q, un dispositivo ciertamente interesante, pero lo cierto es que era extremadamente caro para lo que ofrecía, y aunque su potencial era realmente importante, fue un, podemos llamarlo así y sin paños menores, fracaso. Tampoco hay que olvidar que el Nexus Q ni siquiera llego a estar a la venta masiva, y fue presentado más que nada como un experimento.

12 meses después, Nexus Q es historia. No obstante Google entendió lo bueno que podía resultar Nexus Q en muchas ocasiones, así que tomó lo bueno de Nexus Q, añadió algunas ideas más y busco la forma en la que poder poner todo ello en un dispositivo que merezca la pena comprar (caro o no). Y es evidente que así es como ha nacido ChromeCast.

Técnicamente hablando, ¿que es ChromeCast?

chromecast

Eso es ChromeCast. ES un dispositivo de 5 centímetros similar a un simple PenDrive, con una salvedad que lo hace diferente:

-Funciones de Adaptador WIFI
-Salida HDMI
-Versión de Chrome OS en su interior minimalista y personalizada
-Cuesta 35$

Que tenemos si juntamos todo ello? Es sencillo, un dispositivo que puede conectarse virtualmente a cualquier televisor por HDMI y a la par a nuestra conexión WIFI. ¿Y que hace? Básicamente permite “enviar” contenido de CUALQUIER DISPOSITIVO con independencia de la plataforma usada a la tele. Es decir, es compatible tanto con Android como con iOS como con equipos de sobremesa con Chrome.

De este modo, los usuarios pueden por ejemplo entrar en YouTube en su tablet/movil/PC y simplemente dándole a un botón en su aplicación de YouTube y el contenido empezará a reproducirse en HD en la televisión. Algo tan sencillo en concepto pero que sin duda alguna muchos hemos querido hacer mas de una y mas de dos veces. Todo ello sin configuración alguna de nada, simplemente tener conectado el dispositivo a la tele y conectado a nuestra red. Google ha anunciado que actualmente, ChromeCast permite la “recepción” de contenido desde YouTube, Google Movies, Google Music (música también), Google+ Photos, Chrome, Pandora, Netflix… y por supuesto Google asegura que muchos mas están en camino.

Al anunciar conjuntamente el SDK para ChromeCast, nos permite pensar que en realidad cualquier aplicación actual como reproductores de audio o vídeo e incluso juegos, podrían usar esta tecnología en un momento dado. Habrá que ver las limitaciones del servicio.

ChromeCast además funciona usando los servicios en nube de Google. De echo si mandas un vídeo a la tele desde el tablet, y añadir a la cola de reproducción 10 videos más, puedes irte de casa si lo deseas que la tele no tendrá problema en su reproducción. Es más, si cualquier usuario llega a casa podrá controlar inmediatamente la reproducción actual. Esto es aplicable a películas o a cualquier otra cosa, evidentemente no hay que ser muy listo para pensar que el contenido no se envía realmente de un dispositivo a otro en estos casos, sino que es la tele quien por la conexión WIFI De ChromeCast accede a dicho contenido y lo reproduce. Si puede realmente también recibir datos directamente desde otros dispositivos, esto podría hacer de ChromeCast algo muy muy jugoso.

Lo más importante quizás, y lo que realmente ha sorprendido a muchos y ha hecho que ahora mismo ChromeCast esté totalmente agotado, es el precio. Nexus Q era bonito, genial en esencia e idas pero extremadamente costoso para lo que ofrecía. En este caso, ChromeCast cuesta 35 dólares. aun cuando hiciésemos un cambio de 1:1, 35€ es algo que realmente cualquiera en un momento dado puede permitirse, teniendo en cuenta sobre todo cuando les cuesta su pantalla de televisión. Y por 35€ lo que te llevas es algo totalmente portable, útil, ingenioso… Personalmente es evidente que aunque por ahora tan solo se ha lanzado en EEUU, ya me las ingeniaré para tener el mío. Creo sinceramente que en este caso merece la pena.

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.