Archivo de la categoría ‘Noticias’

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.

¿Que es el nuevo Reglamento General de Protección de Datos (RGPD), que no está dejando títere con cabeza?

 

LOPD (antigua) Vs RGPD

El día 25 de Mayo de 2018 será recordado, con bastante seguridad, por ser un antes y un después, porque han cambiado las reglas del juego, las reglas de un juego en el que el producto era el propio ciudadano, y el vendedor y el comprador empresas de medio mundo. Pero antes de entrar en detalles… ¿Que diablos es la RGPD?

En España llevamos años rigiéndonos por la Ley Orgánica de Protección de Datos (LOPD), supervisada por la agencia de protección de datos. Este organismo ha tenido un papel fundamental en los últimos años, sobre todo si tenemos en cuenta que cada año que pasa nos metemos más de lleno en una sociedad totalmente “tecnologizada”, en una sociedad donde cada vez vale más nuestra información, lo que hacemos, lo que nos gusta, todo. Y si tengo que ser justo, tengo que decir que al contrario de la opinión que tengo sobre como funcionan la mayoría de las cosas aquí en España, la agencia de protección de datos a cumplido con su cometido, ha sido tanto comprensible,  flexible, firme como implacable, en función de las irregularidades, y más importante, de la intencionalidad.

El Reglamento General de Protección de Datos (RGPD) no es una ley ni un reglamento Español, tiene un alcance Europeo, es el acuerdo de años de trabajo de la UE, y digamos que sienta las bases, unas nuevas bases, de como se deben de tratar, recolectar, vender… cualquier dato/información de carácter personal de sus ciudadanos. Esto no va (solo) del mundo digital, ojo, esto se aplica absolutamente a todo. En España, el RGPD sustituye/modificará por tanto la LOPD actual, para darle cabida. Y sí, es de obligado cumplimiento para todos. Nuestra ya vieja LOPD, si bien es cierto que en algunas cosas era más restrictiva, en muchas otras se quedaba corta. El RGPD unifica en territorio europeo las nuevas reglas del juego de los datos personales.

El que más o el que menos ya sabe lo que es la RGPD. Vale, puede que desconociesen lo que estaba detrás, pero lo lleva viviendo cuanto menos desde el 25 de Mayo de este año. Hay que tener bien claro que el RGPD se aprobó hace ya dos años, el 25 de Mayo de 2016, lo que sucede es que se dio un plazo de 2 años para que absolutamente todo el mundo pudiese adecuarse al nuevo reglamento, y la fecha del 25 de Mayo de 2018 sería la fecha límite para empezar a aplicarlo por obligación. Pero como pasa siempre, y pese a esos 2 años de plazo, ha cogido a una cantidad ingente de compañías, entidades, organismos… con un pie fuera, y con dos también. Mientras escribo esto es 6 de Junio, han pasado solo 12 días desde la fecha límite, y os puedo asegurar que la sacudida, la relevancia que está teniendo es épica.

¿Pero que tiene el nuevo RGPD tan “especial” como para afectar tanto? ¿Es tan diferente a la actual LOPD? La LOPD actual ha sido una ley muy positiva, que no siempre se ha cumplido sobre todo a un nivel más de calle, pero tuvo un impacto bastante bueno. El RGPD básicamente no solo devuelve el derecho sobre nuestros propios datos, sino que obliga a cualquiera que los recopile/use/venda/comparta… a:

1º. Especificar de un modo claro, entendible y sencillo que uso se van a hacer de ellos, a quienes se les va a vender/ceder/compartir, el uso a su vez que podrían hacer esas compañías… todo.

2º. Solicitar/requerir permiso explícito sobre todo ello y de un modo granular, nuestro consentimiento no puede ser tácito o sobreentendido, tiene que ser igualmente claro y sin “trampas”, sin denegarnos posibilidad de usar dichos servicios en caso de rechazar la explotación de nuestros datos, a menos que claro está que estos sean totalmente necesarios para el uso de dicho servicio/producto o lo que sea, pero en cualquier caso debe de existir un consentimiento expreso.

3º. Permitirnos acceder de un modo simple, legible, cómodo… a absolutamente todos nuestros datos que poseen, ya sea la finalidad que sea, incluyendo por supuesto la eliminación de todos ellos si así lo queremos, haciendo por ley por tanto el consabido derecho al olvido.

4º. El Reglamento no puede aplicarse de forma retroactiva, pero obliga también a que nos tengan que solicitar de forma expresa, en las mismas condiciones anteriormente citadas, nuestro consentimiento por los servicios y otros que en su día aceptamos al amparo de otras leyes.

5º. Transparencia y tomar las medida de seguridad y control que sea necesarias para salvaguardar los datos que se tengan. Eso quiere decir que ante cualquier fuga de datos, fallo del sistema.. tendrán que demostrar que cumplían con normas básicas de seguridad y que la privacidad era parte importante desde el principio, e igualmente informar tanto a las autoridades como a los afectados sobre dicho problema.

Obviamente el reglamento es mucho más complejo, pero de cara al ciudadano, lo más importante es eso.

Las multas serán ejemplares por otro lado para los menos cumplidores. Hablamos de un 2% a un 4% de la facturación o de 10 a 20 millones de euros, no es calderilla desde luego.

 

No parece tan malo el nuevo reglamento, ¿Por qué tanto revuelo y quejas?

A priori, para la inmensa mayoría todo suena muy bueno, somos felices con todo ello. El problema es que llevamos muchos años en una sociedad donde somos el producto, donde somos los que nutrimos y alimentamos a cientos y miles de empresas con nuestros datos. Esto es complicado de ver a veces, muchos se preguntan que valor puede tener para una empresa cosas en principio con tan poca importancia como saber nuestra edad, o nuestro nombre, o nuestro sexo… si hablamos del teléfono o el correo electrónico muchos podrán entenderlo mejor, porque el uso publicitario de ello es más inmediato, pero el resto de datos tienen el mismo valor. Servicios como Facebook, Instagram, Twitter, Google, Apple… recopilan ingentes cantidad de datos nuestros a cambio de usar sus productos/servicios. Esas empresas generan miles de millones de uros gracias a nuestros datos. Publicidad dirigida, big data, estudios…

La repercusión es inmensa, porque si bien es cierto que para muchas grandes empresas el negocio del bigdata es secundario, para muchas otras es de primer nivel, y el nuevo reglamento va a disminuir enormemente tanto la cantidad como la calidad de los datos, a fin de cuenta ahora el control va a tenerlo de un modo más férreo cada persona. Pensemos en cosas simples, no hace falta ejemplos sofisticados. Si entramos en una web que usa Google Analytics sencillamente para tener una idea de visitas y otros, aunque sea sin animo lucrativo siquiera, requiere confirmación expresa, denegarlo o simplemente no interactuar, implica que no puede usarse con nosotros, con lo que para empezar, la totalidad de Webs que “monitorizan” del modo que sea sus visitas van a ver un descenso brusco de estas. Y fijaros que el ejemplo más sencillo no puede ser. Bien pues si eso pasa con una web de cualquier individuo, pensar que pasa con una web de una compañía/empresa. Pongamos de ejemplo la web del diario “El PAIS”, el cual no cumple rigurosamente por cierto con la nueva normativa, y vemos en su política de Cookies una lista de terceras empresas con las que se colabora y usan nuestros datos.

En lo personal, entiendo que mis datos son necesarios para las empresas y que contribuye a que pueda usar ciertos servicios de forma “gratuita”. Lo mismo pasa cuando usamos aplicaciones gratuitas muchas veces, asumimos que lo “gratis” es pagar con algo de nuestros datos. Me parece bien, lo asumo, pero siempre que ese uso y esa recolección de datos sea proporcionada. Antes era el gran coladero, en el mejor de los casos tenías una opción escondida para compartir datos, y páginas incontables de condiciones legales. Ahora todo va a ser más simple y sencillo, quienes no quieran arriesgarse tendrán que ser claros, permitir granularidad y ante la duda no recopilar ni usar nada.

Muchas empresas tendrán que cerrar directamente, lo que antes era el pan nuestro de cada día hoy no será viable, sobre todo si tenemos en cuenta que una vulneración de nuestros derechos conllevará sanciones importantes. Otras se verán muy afectadas al ver como el gran volumen que manejaban cae enormemente. Y otras, las que menos, sencillamente tendrán las herramientas necesarias para que simplemente el usuario pueda hacer lo que alguna vez a lo mejor quiere hacer: Saber que datos tienen de uno, y permitir o denegar su uso en las condiciones que dicen, sin ser abusivo.

Se ha hablado mucho de que las sanciones son desproporcionadas, tal es así que muchas empresas no europeas, están denegando el acceso a sus servicios/webs/otros a ciudadanos Europeos por miedo de incumplimiento. Otras, no han optado por algo tan radical, pero si han creado versiones específicas (mismo contenido realmente) para los Europeos para poder cumplir con las normativas nuevas. Esto nos da una idea del tráfico actual que existe/existía de datos personales, de nuestros datos personales. Cuando una empresa prefiere denegar el tráfico a los Europeos a sus servicios por miedo a no cumplir con la RGPD, te da que pensar, a saber que barbaridades están haciendo. Pero lo mismo para aquellas empresas/servicios que crean versiones especiales ahora para poder cumplirla. Hace un rato, leía no recuerdo donde, que habían hecho experimentos en diferentes diarios extranjeros para ver cuan diferente podían ser estas “versiones” de webs para europeos y para el resto… los resultados estremecedores, las webs que cumplen ahora con la normativa europea pesaban algunas incluso un 90% menos!!, con lo que cargaban mucho antes también. ¿Por qué? Pues porque el grueso de una web a día de hoy es el contenido audiovisual, scripts y otros, y todo ello muy de la mano siempre de la publicidad, estadísticas, analíticas y tantas otras cosas.

No estoy diciendo que el RGPD sea el mejor, es más, llega muy tarde, llevan con él años y años y años… pero eso no quita con que no sea positivo. Existen flecos, existen algunas dudas, pero la mayoría de quejas que se han levantado son quejas de aquellos precisamente que lo hacen con la boca pequeña y mirando hacia otro lado. Es de esas leyes/normativas que aunque te contravenga, ponerte en su contra es casi imposible debido al sentido común, ética, impacto y derechos propios…se ha intentado criticarla poniendo de facto que al final el perjudicado serán las PYMES o usuarios particulares como bloggers, “influencers” y otros..  El reglamento viene para cumplirse, y a medio largo plazo se va a cumplir seguro, pero aunque las sanciones pueden ser muy muy duras, eso no significa que porque un bloggero de moda no ponga o se le olvide poner una casilla de verificación, le va a llegar una multa estratosférica. En primer lugar siempre se alertará, se dará un toque de atención se…. se es realista, eso sin contar que se tendrá muy en cuenta también tanto el volumen de datos que se manejan como su importancia y otras cuestiones.

Bien, llegado a este punto, para quien ande perdido y vea que esto va en serio. Yo no me dedico a venta de datos ni a compartirlos ni a nada, pero por ejemplo este blog es mío. Bien, yo estoy obligado a cumplir con el nuevo RGPD. Pero parece absurdo si realmente… ¿qué datos de caracter personal puedo recoger yo? No recopilo información de nadie, no vendo nada, no publicito nada… aun así, hay 3-4 cosas que tengo por ley que dejar claras:

1º. Lugar siempre visible de política de privacidad y cookies
2º. En mi caso, el único contenido externo creo recordar que es Google Analytics para contar visitas, pues aun así tengo por defecto que no usarlo, y solo usarlo si se me da un consentimiento expreso que saldrá en pantalla.
3º. El formulario de contacto ahora tiene que incluir por narices una casilla de aceptación de la política de privacidad y cookies. En mi caso es muy simple porque los únicos datos que se recogen son lo mínimo imprescindible, pero da igual, tengo que decir bien claro que voy a hacer con esos datos, para qué… etc etc

Y todo eso en un blog que es, o intenta al menos, ser escrupuloso con la privacidad y el respeto a los usuarios, sin publicidad, sin tráfico de datos, sin absolutamente nada. Imaginad ahora que pasa cuando se trata de una empresa que se dedica a traficar con datos y un buen día de buenas a primeras tienen una filtración de datos, o se descubre que nos han engañado y han estado vendiendo nuestros datos sin nuestro consentimiento. Pues aun así, pese a los ya pequeños cambios que he realizado en mi propio blog, es posible que aun esté violando el RGPD en algún punto, no soy jurista a fin de cuentas, pero lo más importante que podemos ofrecer cualquiera que sea un comunicador, es ser transparente. Sin transparencia no hay confianza, y sin confianza…

Las empresas de cierto tamaño lo van a tener más complicado, pero también tienen infinitamente más medios. Desde designar delegados específicos, rediseñar la privacidad desde cero, auditorias.. pero señores, hablamos de cosas serias, no tengo nada que ocultar, pero no me gusta que se me use como moneda de cambio y sin yo saberlo.

 

Futuro Inmediato

El efecto ya lo estamos viviendo, y vendrá además por fases.

La primera fase la llevamos viviendo algunas semanas y meses, ¿cuantos correos electrónicos hemos recibido de diferentes sitios, muchos de ellos sin siquiera saber quienes eran, sobre actualizaciones de políticas de privacidad y para pedir nuestros consentimientos? Muchos, yo he perdido ya la cuenta…

La segunda fase ha empezado hace poco, y cada vez más vemos en todas las webs avisos mucho más concretos, posibilidades de denegar el rastreo o incluso la publicidad. En algunas nos dejan seleccionar cookie a cookie, empresa por empresa, que permitimos y que no. Y esto va a continuar, se acabaron carteles ambiguos o el aceptar de forma pasiva las cosas. Muchos que se están adecuando van a tener que volver a cambiarlas, lo estoy viendo a diario… sí, han cambiado 2 cosas pero siguen violando el RGPD. Como todo habrá que esperar a que pase un tiempo a que se asiente todo. Esto se aplica no solo a páginas webs, lo vemos también en aplicaciones, software, todo.

La tercera será más dramática, y serán cortes y cierres. Muchas muchas aplicaciones a día de hoy de App Store o Play Store se nutren de publicidad, de venta de datos de… serán ilegales si no cumplen con el RGPD, y eso implica consentimiento expreso, granularidad, explicación… aquellas, las más “dañinas” para nuestros datos se verán obligadas a cerrar porque no será rentable, ni los ciudadanos estarán dispuestos a dar los datos que exigen. Muchas otras podrían ver un decremento muy importante de sus ingresos indirectos/directos a los datos privados y hacer que dejen de ser rentables. Y repito, esto mismo se extrapola a Webs y otros negocios, ya se han visto muchos casos.

La cuarta fase, serán tribunales. Un negocio tan lucrativo no se va a abandonar así como así, y las trampas siempre han existido, desde moverse siempre en la fina línea de lo legal y lo ilegal, hasta simplemente las cazicadas de mentir/engañar y robar datos sin que se sepa. Pensar que no han pasado ni 12 días y las grandes compañías ya estan TODAS denunciadas. Sí, Facebook, Google, Apple… No creo que en ese punto haya a corto plazo sanciones importantes y poco a poco se adecuarán seguro, pero, y espero equivocarme, asistiremos a algun que otro escándalo multimillonario de alguna gran empresa por pasarse por el arco del triunfo la nueva normativa e ir con “maldad”.

 

Hay que ser realistas, y entiendo que muchos productos y servicios son posibles a que nosotros mismos nutrimos sus bases de datos, y lo acepto, y lo asumo. Pero quiero saberlo, quiero saber que se hacen con mis datos, quien los tiene y que uso le dan. Para mi la importancia no radica tanto en multas o en que no tengan mis datos. Siempre lo he dicho, cuando instalo una app interesante y se me solicita de forma adecuada si quiero compartir con los desarrolladores o incluso terceros datos anónimos de uso o alguna otra cosilla, casi siempre les digo que sí, entiendo el valor y la importancia que tienen para ellos y yo me estoy beneficiando. Pero siempre que entienda que es razonable lo que se pida. Tengo Facebook, pero en el equipo, no uso Facebook en el móvil. Lo desinstalé hace años cuando vi que, sin preguntar, sin necesitar y sin nada, Facebook estaba constantemente intentando recopilar datos de geolocalización propios, o mi agenda de contactos o… Repito, hay usos directos y necesarios, usos entendibles, usos “razonables”, y hay mucho mucho abuso. Y contra el abuso si me posiciono y lo denunciaré siempre que pueda públicamente… (estoy preparando un artículo sobre Movistar al respecto, no creo que les haga mucha gracia, y menos con el nuevo RGPD)

No hay que ser alarmistas, para los que podemos vernos afectados desde un punto de vista de “adaptar” webs o empresas o… es muy simple: Buen hacer, buena voluntad, transparencia, y pensar que nos beneficiamos todos. Si se va con buena fe y voluntad, en realidad es sencillo cumplir la nueva normativa, y como usuario que soy, también, me siento más seguro y más tranquilo.

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.

Fotografía RAW: Sensores CFA, Demosaicing y Dcraw

 

Los Objetivos de Hoy:

  • Poder realizar capturas RAW con la gran mayoría de terminales móviles
  • Entender como son realmente las capturas RAW
  • Ser capaces de “revelar” dichas capturas RAW sea cuales sea su formato
  • Crear nuestras propias herramientas cuando lo que tenemos fuera no nos soluciona el problema
  • Versión Dcraw Modificada para dar soporte específico al Xiaomi Mi6 (Ver apuntes finales)

Como pequeña introducción, los amantes de la fotografía que usen Android, sabrán que este tiene dos APIs fundamentales a día de hoy: Camera1 y Camera2/HAL3.x. En teoría la segunda viene a sustituir la primera desde hace mucho tiempo ya, pero la vagancia de algunos fabricantes y el uso para variar de APIs propias de otros, hace que como todo se tomen su tiempo. La ventaja de usar Camera2/HAL 3.x es enorme, ya que de forma nativa Android permite la captura RAW, controlar controles ISO, tiempo de exposición, focus… y de ahí existe la extraña creencia que todo ello no puede hacerse en Camera1. Sí se puede, ojo, la diferencia es que es más complicado y no tan eficiente. Y ahí es donde todo esto empieza, por mi cabezonería. El Xiaomi Mi6, por ejemplo, es totalmente compatible con Camera2, pero no está habilitado por defecto. Así que me decidí a lograr capturas RAW sin usar Camera2 (que es trivial). Lo que no tenía ni idea es que iba a dar para tanto.

Siempre he dicho que yo no soy un genio, genio son aquellos que tienen las capacidades y habilidades de crear los códigos tan ingeniosos que crean. Que yo sepa programar y pueda en un momento dado crearme mis herramientas, utilidades y otros es una cosa, pero la capacidad de algunos compañeros para plasmar tanto problemas matemáticos, algoritmos… en código, siempre la he envidiado. Con esto quiero mandar un saludo especial a los creadores de las mismas herramientas que he usado/uso, y algunas que he modificado.

La primera, pienso que es la mejor aplicación de cámara en Android en cuanto a versatilidad y grado técnico. Por desgracia recientemente su creador, troop, eliminó no solo el repositorio de github, sino que terminó borrando casi todo rastro de sí mismo. Llego a estar en el PlayStore, y cada actualización era mejor que la anterior. No se saben bien los motivos, unos dicen que se cansó, otros que realmente la aplicación tenia malware… sea como sea, está oficialmente retirada, pero tenemos forks en github. La última versión que lanzó fue la 4.1 Alpha 5, de este mismo Julio. Por cierto, hablo de FreedCam. Y tengo que decir que fue la que empezó todo esto. Esta app tiene una peculiaridad (bueno tiene muchas) importante, y es que te permite cambiar de Camera1 a Camera2 (si el terminal es compatible), y usar en cada caso lo mejor que tu cámara pueda darte. Y es mucho, porque posiblemente no vas a encontrar otra cámara que en Camera1 sea capaz de hacer una captura RAW. Y sí, la hace… bueno, siempre y cuando claro el terminal exponga en su Driver que admite al menos la captura en algún formato que no sea JPG, y ya os digo que la mayoría puede!! Y sin usar Camera2. Pero todo esto lo veremos más adelante.

La segunda, ha sido la que después de mucho quebrarme el coco, me ha dado todo el código que necesitaba para que con unas simples modificaciones (realmente añadidos) me haya permitido “revelar” mis RAW. ¿Por qué? Bueno, porque aunque con Camera1 es posible hacer capturas RAW, estas capturas nada tienen que ver con las clásicas capturas RAW de Camera2 (DNG generalmente) o de otras cámaras, estos RAW suelen ser RAW pero RAW, sin cabecera, sin nada. En este caso ha sido el software de Dave Coffin el que lo ha hecho posible. Ahí tenemos la gran importancia del código abierto, por sí mismo su software no pudo ayudarme, pero su simplicidad y su buena estructura me hizo que fuese relativamente sencillo modificarlo. Y en este caso me refiero a su utilidad DCRaw, cuyo código fuente tenemos en su propia Web y podemos compilar/reescribir o hacer lo que queramos.

 

¿Por qué RAW?

Tengo que confesar que, entre otros muchos problemas o defectos, llevo muy mal eso de no entender algo. Por supuesto que nadie tiene conocimiento universal, me refiero a estar con algo entre manos y tener más preguntas que respuestas. Soy bueno el algunos campos, pero es obvio que en muchos otros soy un principiante o un completo negado. Y es lo que me ha pasado siempre con la fotografía, es un campo que me apasiona desde un punto de vista técnico y físico, no estético. Si me hubiesen preguntado hace una semana que era un Sensor CFA Bayer sin ponerlo en ningún contexto, sinceramente habría respondido con un: “No tengo ni puñetera idea”. Y eso me encanta, porque si es algo que me interesa tengo asegurados unos cuantos días de estrujamientos de sesos, y en el peor de los casos habré aprendido unas cuantas cosas. Así que si algún aficionado a la fotografía encuentra algún error en mis palabras o algo que no sea así, por favor, que me corrija, soy “nuevo” en esto.

Como me suele pasar siempre, suelo tener algo entre manos, de eso salto a lo otro, de lo otro a otra cosa… y al final estoy hasta arriba. Todo lo que voy a contar a continuación está basado en un Xiaomi Mi6 (Mi terminal actual), pero es aplicable de un modo u otro a cualquier (o casi) dispositivo Android e incluso en muchos aspectos a cualquier cámara de fotos en general.  Hace ya tiempo escribí un artículo principalmente versado sobre software fotográfico, hablando de características principales de las cámaras, HDR, RAW: Luces, Cámaras y… Software!!. La idea no es hacer una segunda parte, sino centrarme en puntos muy específicos dentro de la fotografía digital: La captura RAW.

La captura RAW ha ido aumentando en popularidad desde hace ya mucho tiempo, imprescindible para los profesionales, querida por los aficionados, y generalmente ignorada o desconocida para el resto. Llamamos fotos en RAW de forma genérica a cualquier foto digital que haya sido tomada por una cámara (DSLR, móvil, compacta…) sin que haya sido procesada por el propio dispositivo, o mínimamente procesada. Ya digo que para el aficionado o profesional esto es de primero, pero para la mayoría lo único que saben es que disparan y se genera un archivo digital, generalmente una imagen JPG. Pero esa imagen final que obtienen es el resultado de una serie de procesados internos que transforman/convierten las señales eléctricas recibidas por el sensor, la organización de estos datos, la interpretación, correcciones, interpolaciones… Digamos que el JPG es la foto revelada, mientras que la foto en RAW es el negativo, por tanto. ¿Y esto es importante? Bueno, para el usuario casual es indiferente, las cámaras hacen un procesado y post-procesado bastante decente y no necesitan más. Pero para quien busca ese digamos… “punto extra” o toque artístico añadido, o un resultado mucho más limpio y certero… entonces necesitas trabajar tú personalmente ese negativo. Hay una lógica aplastante en esto: Si un móvil o cualquier cámara de fotos a día de hoy es capaz de realizar todas esas conversiones, adaptaciones, interpretaciones… para obtener al final la imagen JPG, y lo hacen en tiempo real (de forma más o menos aceptable), imaginad el resultado que podría obtener un equipo de sobremesa que tiene infinitamente más potencial, sin necesidad de hacerlo en tiempo real y pudiendo usar filtros/algoritmos mucho más exactos, o que nos gusten más.

A todo ello hay que añadir un enorme problema adicional que hay en la fotografía digital. Los formatos de imagen como pueda ser JPG (el más usado), es un formato con pérdida, lo que significa que aun cuando el procesamiento de las señales fuese perfecto y todo acorde a nuestros deseos, el simple echo de inscribir dicha información como un archivo jpg, estaría ocasionando una pérdida importante de información. A lo mejor en una imagen de 20MP con una cámara profesional y para una foto de tamaño normal no se aprecia, pero para una foto con resoluciones más bajas o cuando necesitamos sacar un detalle concreto o… no son pocas veces las que vemos claramente los errores de compresión que provoca JPG, como “anillos”, “pixelado” de color y otros artefactos debidos a la cuantificación.

Si ampliamos y nos fijamos bien, se pueden apreciar diferencias en cada uno de todos los pasos, siendo por supuesto los dos últimos muy extremos. Entre Q100 y Q75 pude parecer correcta la imagen en cierto modo, pero si nos fijamos bien con Q75 la imagen tiene mucho más ruido, y la hélice ya empieza a generar un pequeño halo. Para Q50 los colores de la mitad derecha, sobre todo el cuarto superior empiezan a verse incluso bloques, para Q25 el efecto es visible en toda ella y a Q1… bueno, no es que quede mucha imagen. La mayoría de cámaras permiten seleccionar de un modo u otro este grado de cuantificación que por defecto suelen establecer entre 80 y 90. A valor más alto, la imagen como es natural tendrá un mayor tamaño.

RAW es indistinto a todo esto. No es que se trate de un formato de imagen sin pérdidas como pueda ser PNG, puesto aun así lo que se guardaría en el PNG sería la imagen procesada. Una imagen en RAW por lo general contiene casi con exclusividad la información pixel a pixel que se ha tomado. Ya depende de la decena de archivos RAW que usan los fabricantes, el como incluyan la información, en que formato, si añaden metadatos… y esto es un gran dolor de cabeza, porque al no existir un estándar de facto, cada fabricante genera el que cree mejor, y así al final se requieren suites como Adobe CameraRaw o RawTherapee (O por supuesto DCRaw del que ya hablaremos) para poder tratar dichos ficheros. Al contener en la medida de lo posible la información en crudo, por otro lado, son archivos mucho más pesados que sus homólogos comprimidos como JPG.

Pero… ¿Donde empieza todo?

 

Sensores CFA: Bayer

La fotografía digital es totalmente diferente a la tradicional en cuanto a como la luz queda al final plasmada en un formato digital. En la fotografía tradicional es una película fotosensible la que capta la luz externa desde el objetivo. En la fotografía digital, el sensor de imagen es el que es bombardeado por los fotones de la luz, los hace converger, y es capaz de generar pequeñas tensiones en función de la intensidad/variaciones de estos fotones. Como es de suponer su versión más simplista sería un sensor que tan solo fuese capaz de percibir la intensidad de luz, pero a día de hoy sabemos que tenemos sensores de alta definición con una gama de colores enorme. 

El color es un problema, puede que para el ojo humano sea bien sencillo, pero para la electrónica causa dolores de cabeza. Pensar en un sensor en realidad es sencillo, imaginar algo así como una superficie plana rectangular como un colador, que tiene un agujerito por cada pixel de resolución que tiene dicho sensor. Si el sensor es de 4032×3016 pues tendría dicho número de agujeritos. El sensor sería capaz de tomar la luz por cada uno de esos agujeritos, y registraría el estado de cada una de esas celdas fotosensibles, que pasaría luego a un formato digital. ¿Pero que pasa con el color? Esas “células” fotosensibles que habría debajo de cada agujerito no pueden conocer de forma genérica la longitud de onda que les llega… podrían saber si es rojo o azul, azul o verde, verde o… pero no tener una lectura completa de todo. A este problema existen varias soluciones.

La más obvia es usar sensores con diferentes “capas”, las cuales, cada una de ellas es capaz de atrapar la intensidad de uno de los tres colores primarios (Rojo, Verde y Azul, RGB), pero esto es caro. Así que al final, prácticamente la totalidad de cámaras de fotos usan una aproximación realmente al problema, y usan sensores CFA: Color filter array. Los sensores CFA son mucho más baratos, pero hacen trampa. Cada “celda” del sensor no es capaz de capturar la intensidad de más de un color, cada celda sólo sabe capturar el de uno sólo, pero se crea una matriz, un mosaico compuesto de dichas celdas, organizados de un modo muy concreto, y así dar la sensación de que cada celda (pixel) posee color propio. Pero es una ilusión. La efectividad de un sensor CFA empieza por tanto en el patrón o la organización concreta de esas celdas (que pueden ser rojas, verdes o azules) que tendrán en el propio sensor:

(Wikipedia)

 

 

Dentro de los sensores CFA, nosotros nos vamos a centrar a su vez en los sensores Bayer. Bayer fue el inventor del patrón mostrado en la imagen anterior. Bayer se dio cuenta que el ojo humano es mucho más sensible al color Verde que al color Rojo y Azul, tomando pues el Verde como el componente lumínico y el Rojo y Azul como componentes cromáticos. Así que estableció lo que a día de hoy se conoce como Mosaico Bayer o patrón Bayer, que es sencillamente la repetición de un mosaico/bloque de 2×2, que contienen dos componentes verdes siempre enfrentados, y un componente azul y otro rojo. Estos patrones Bayer se nombran en función del orden en el que aparecen dichos componentes, y como es lógico solo hay 4 posibilidades: RGGB, BGGR, GRBG y GBRG. Recordar que el patrón es un bloque de 2×2, no 4 celdas alineadas. En la imagen anterior vemos un patrón BGGR, que se repite indefinidamente. El por qué de tomar el sensor Bayer de ejemplo, es porque a día de hoy es de lejos el tipo de sensor más usado. Pero ojo, no es el único, y no es tampoco nada raro ver sensores CFA de otro tipo, con otros patrones diferentes.

Si nos fijamos en la imagen de arriba, vemos la trampa y en parte el problema. Vale, tenemos distribuidas celdas capaces de captar los tres colores (e intensidad de estos claro), pero si hemos dicho que cada celda representa por así decirlo un pixel… ¿¿como diablos representamos eso?? Que cada celda recogiese en sí misma toda la información RGB tendría sentido, un pixel, un color RGB asignado. Pero en el sensor bayer cada pixel sólo recoge un color, una intensidad. Si tenemos una imagen de 2MB (1920×1080), según el patrón BGGR mostrado, el resultado sería de todo menos fotográfico, veríamos claramente un efecto “mosaico” en la foto, no una imagen colorida y hermosa. Además, tendríamos la peor parte… si usamos bloques de 2×2, podríamos pensar que realmente “1 pixel” real correspondería a cada bloque, lo que implicaría que el sensor tuviese que tener el doble de tamaño. Y ya os digo que esto no es así.

 

Demosaicing (Teoría)

(Nota: Cuidado, si se hace clic pasa a la versión completa, 11MB)

Puede parecer una broma, pero, en la imagen podemos ver realmente la información que capta un sensor Bayer (El Xiaomi Mi6 usa un sensor RGGB). Vista en la previsualización es posible que no lo percibamos, y sólo veamos una imagen completamente verde (poco que ver con la imagen con la que empecé este artículo. Pero si tenéis una conexión mínimamente decente, os invito a hacer clic, ampliar y ver que está pasando. Y se ve, creerme que se ve. Si ampliamos la imagen unas 1600 veces, para quien no tenga ganas de abrirla, esto es lo que va a ver:

 

Ahora no parece tan verde… ahora podemos apreciar perfectamente cuales son los píxeles con las distintas intensidades verdes, y cuales los azules y rojos. El patrón siempre es el mismo, bloques 2×2 RGGB, RGGB…

Pero falta información en la imagen o eso parece… ¿¿donde están realmente los colores?? Es cierto que sabemos que con RGB podemos crear cualquier color, pero aquí tenemos filas y filas del mismo patrón, y dado que hay el doble de píxeles verdes, toda la imagen toma en este caso un color claramente verdoso, El color final se encuentra codificado en la información de la intensidad de los píxeles que les rodea. El patrón Bayer hay que deshacerlo para reconstruir los colores reales, el valor RGB de cada pixel, y no sólo uno de sus componentes. A este proceso es al que se llama demosaicing, que realmente es una interpolación de colores. Como tal, y como ya se dijo, es siempre aproximada, el sensor jamás será capaz de captar los colores “reales” en toda su resolución, pero gracias al software y a la física podemos reconstruir de un modo muy fidedigno la imagen original. Sí, no deja de ser un truco, pero en este caso un gran truco.

Por supuesto el resultado por tanto va a depender en gran medida del modo de interpolación que sea usado. No existe un modo de hacer este proceso de forma única, hay tantos como algoritmos de interpolación existan o queramos crear. Y esto no es exclusivo del sensor Bayer, de echo casi todas las cámaras a día de hoy sino todas, si no usan Bayer usan otro sensor CFA con otro patrón, que también hay que interpolar. Un equipo de sobremesa podría en todo momento aprovecharse de esto para cargar la foto sin “desmosaizar”, y aplicar diferentes algoritmos para ver cual de todos ellos da mejor resultado para dicha toma, o por fines puramente artísticos. Además un equipo puede permitirse el lujo de hacerlo ya no en tiempo real, sino todo tipo de algoritmos que sean complejos y sobrepasen la capacidad de cálculo de cualquier móvil o cámara de fotos.

Cuando empecé a ver todo esto, sinceramente me pareció una locura, sabía como funcionaban más o menos los sensores de imagen, pero creía que cada “celda” del sensor en realidad se subdividía en 2-3 subceldas cada una de ellas captando la intensidad de un color y conformando en sí misma un pixel completo, no tenía ni idea que realmente cada pixel tomado de forma independiente no poseía en sí mismo un valor completo de color RGB. Muchos pueden pensar que puede ser más o menos interesante, pero que a fin de cuenta que importa, si al final es el resultado lo interesante. Por supuesto, pero desde un punto de vista técnico, hay una importancia infinita, y es por culpa del desconocimiento que tenía en estas cosas por el cual no era capaz de “revelar” mi primera captura RAW que realicé con mi terminal con Camera1.

Soy un amante de Photoshop, pero si quieres un control más fino del revelado RAW o tener opciones más flexibles, quizás es mejor probar en esos momentos un poco de RawTherapee, además de ser gratuito. Puede mejorar en millones de cosas, pero a veces nos da ese algo más que no tenemos en PS. Por ejemplo, entre otras cosas, diferentes algoritmos  para “desmosaizar”

 

Parsear archivos RAW

Se desde hace tiempo que se podían hacer capturas RAW con algunas aplicaciones y potencialmente obtener del sensor los datos tal cual los captura, pero de ahí a interpretar dichos datos hay un abismo. Si fuera tan sencillo no existiría Adobe CameraRaw y sus constantes actualizaciones, precisamente para ir soportando poco a poco más formatos. Como he dicho cada fabricante usa sus propios formatos. Al menos incluso en esos casos podemos llamarlos “formato” de archivos. Si lees la información directamente del sensor, poco o nada tiene que ver con esos archivos. Cuando una cámara normal hace una fotografía en RAW o incluso con las APIs “normales” de Android, se genera un archivo RAW generalmente conocido, que además de incluir información a nivel pixel a pixel, incluye la información necesaria que después cualquier “revelador” RAW podría necesitar. Por ejemplo, los parámetros con los que se tomó la foto (exposición, distancia focal, lente, marca, modelo….), el tipo de sensor que usa, si Bayer que patrón Bayer usa, que matrices de color o multiplicación se han aplicado… un largo etc de lo que podemos llamar “metadatos”. Algunos tan importantes, por supuesto, como la resolución de la foto, la profundidad de bits de color… Realmente no componen la imagen en sí mismos, pero si aportan información de todo ello necesaria. Sin ella es poco probable que algún revelador RAW puede interpretarla.

Este es el caso que nos atañe. Sí, después de capturar una imagen RAW con Camera1 con Mi6 obtengo efectivamente un archivo pesado, de unos 15Mb, exactamente (y esto es importante) 15482880Bytes. Hace ya días me preguntaban que sí, que sabían que podía capturarse en RAW con Camera1, pero que les había sido imposible “abrirlas” (revelarlas). A diferencia de otras formas de captura, aquí la información que tenemos es mínima, y solo podemos empezar a teorizar, después de intentar pasarlo sin éxito por diferentes aplicaciones RAW. Cuando las herramientas disponibles no nos valen, hay que hacerse las herramientas, y ver que pasa. Por suerte no es la primera ni la segunda vez que parseo archivos… es decir, analizo archivos en principio de índole binaria, soy capaz de encontrar o identificar cabeceras, datos… y en función de la estructura de estos crear un parser que pueda interpretarlos de algún modo. Con el tiempo aprendes a ver “patrones” en los editores hexadecimales que te hacen pensar sobre que tipo de contenido pueden tener: Comprimido, cifrado, información de color, espacial… y siempre por supuesto no con un archivo, a ser posible al menos con 2 o 3 diferentes, así poder encontrar patrones similares, ideales para cabeceras, tamaños/offsets y otros.

Distribución más o menos uniforme, sin cabecera visible. Si tenemos en cuenta que estamos tratando con archivos de imágenes, y dada la estructura que a simple vista podemos ver, parece razonable pensar que el archivo generado es sencillamente la sucesión de pixeles de la imagen. En principio cada uno de los Bytes podría ser cualquier cosa, pero para empezar podríamos pensar que cada Byte representa la intensidad de color de un Pixel, y aun cuando no conociésemos que es un sensor Bayer, lo primero que pensaría es que los pixeles estarían representados por cada 3 Bytes, pongamos que el primer byte es la intensidad Roja, el segundo Verde y el tercero Azul, y se repite por cada pixel. No parece que exista cabecera y eso es un problema, ya que el archivo en sí mismo no nos da ningún tipo de información extra, que es totalmente necesaria, así que hay que extrapolarla de las cosas que sí sabemos.

Lo que sabemos:

Archivo: 15482880 Bytes
Resolución Foto Tomada: 4032 x 3016

Por lo general un archivo JPG tiene una profundidad de color de 8Bits por canal (24Bits en total), es decir que tanto para el canal Rojo, El Verde y el Azul, se usan 8bits en cada uno que indican su intensidad, y los 3 Bytes conforman el pixel. 1Byte permite 256 valores diferentes, así que una profundidad de 24Bytes podría darnos unos 16.7 Millones de colores posibles. Esto es más que suficiente, pero cada vez exigimos más, y en fotografía profesional, Juegos (ahora de moda), HDR y otras cosillas, se requieren profundidades de color mayores. No es nada raro a día de hoy por tanto ver cámaras que disparan RAW a 10, 12 y 16 Bits por canal, incluso los propios monitores soportan profundidades ya mayores a los 32Bytes de siempre (24Bytes+8 Bytes más del canal Alpha). Sin especificaciones en la cabecera y sin que nadie nos pueda ayudar, sólo nos queda presuponer y hacer cuentas, que no es complicado.

El archivo parece mantener la estructura de principio a fin, aunque si mirásemos al final del archivo veríamos una parte que está totalmente vacía y si miramos otros archivos siempre es el mismo tamaño… así que no es mala idea apuntar ese “extra” de archivo, siempre 282240 Bytes. Bueno, pues si es así sólo hay que multiplicar/dividir para adivinar que pasa. Si suponemos que cada byte es un pixel (un componente RGB), ¿cual debería de ser el tamaño final del archivo?? La resolución la conocemos de antemano

4032 x 3016 = 12160512 pixeles x 3Bytes (1Byte por componente, 8 bits de profundidad) = 36481536 Bytes. Un valor bastante superior al tamaño que realmente tenemos de archivo, con lo que si usásemos una profundidad de color aun mayor, el tamaño sería mucho mayo, y obviamente no vamos a tener menos de 8bits por canal.

Podríamos hacer otra hipótesis, y pensar que realmente no existen 3 componentes por cada pixel, es decir, 24bits por pixel, y tan solo 8bits por pixel, pero entonces tendríamos la percepción de tener una resolución 3 veces inferior. Aun así, vamos a ver como quedaría:

4032 x 3016 = 12160512 pixeles x 1 Bytes= 12160512 Bytes. Un valor mucho más cercano al tamaño original, pero aun no coincide, ni siquiera si sustrajésemos el espacio vacío de 282240 de final de archivo.

Una opción es seguir probando, otra sería hacerlo al revés, partir del tamaño original y ver que pasa:

 

15482880 Bytes x 8 = 123863040 Bits / 4032  = 30720 / 3016 = 10,185 Muy cerca, demasiado… podrían ser 10 Bits por componente, o 10 bits para los tres componentes. El caso es que teniendo en cuenta la resolución y el tamaño, cada pixel está codificado por algo más de 10bits. A ver que pasa si descontamos al tamaño completo el espacio en blanco final de archivo:

15200640 Bytes x 8 = 121605120 Bits / 4032 = 30160 / 3016 = 10 clavados.

Así que una de dos, o cada pixel se codifica con 10 Bits para las tres componentes, o cada “pixel” se representa con una sola componente y 10Bits, que teniendo en cuenta es una imagen RAW, es lógico que se use una profundidad de más de 8bits por canal. Aquí es donde automáticamente recordamos los sensores Bayer y como funcionan, y podemos sacar en conclusión que:

-El archivo no contiene ninguna cabecera
-El contenido del archivo es una sucesión de pixeles consecutivos, cada uno de ellos codificado a 10Bits
-Cada pixel codificado de este modo tan sólo posee una componente, lo cual coincide con lo que cabría esperar en un sensor Bayer.

Todo esto es sólo hipótesis, por ahora no hay una imagen de nada. Lo bueno de Bayer es que como cada pixel se codifica sólo como una componente, podríamos tratar toda la imagen como si no existiese color, y cada pixel sólo tuviese información en la escala de grises. Si fuese así, representar eso en cualquier editor tendría que darnos una imagen en escala de grises de la fotografía original. Eso sería trivial con cualquier aplicación, incluso en PS podemos forzar la apertura de una imagen RAW indicando la resolución, los bits por componente y cuantos canales. El problema que tienen todos esos editores es que la mayoría no contemplan profundidad de 10 Bits. Photoshop por ejemplo te permite forzar la apertura para 8, 16… pero no para 10. Otros si te lo permiten pero entonces no te permiten forzar que lo interpreten sólo como un canal… y ya sin entrar en las diferentes formas de codificar en 10 bits pueden existir.

Aunque sólo fuese para ver si vamos por buen camino, podríamos intentar usar alguna herramienta de conversión para transformar esos 10bits en 16 o en 8. Por ejemplo, cada 10bits leídos escribir 2 Bytes en otro archivo. El archivo final aumentaría el tamaño claro está, por usar 16bits por canal. Otra opción sería el proceso inverso, pasar esos 10bits a 8bits por interpolación, y el archivo final tendría un menor tamaño. Pero de cualquier modo por desgracia no existen herramientas sencillas para esto.

Lo más cercano que tenemos, sin entrar en programar nosotros mismos, quizás sea con ImageMagick, y su utilidad Convert, que precisamente hace cosas similares. Si definimos nuestra imagen de entrada como una sencilla representación gris en 10bits y con la resolución concreta, podemos pedirle que nos lo pase a 16bits:

convert.exe -size 4032×3016 -depth 10 GRAY:MiImagen.raw -depth 16 imagen_16bits.raw

Vemos que efectivamente el tamaño crece para acomodarse a 16bits por componente, y ser mucho más sencillo poder verla con cualquier visor. Tal cual, usando Photoshop o cualquier editor, especificando repito resolución profundidad (16bits ahora) y canales (1 en este caso, gris), tendríamos lo siguiente:

No es una imagen muy definida que digamos, pero sí que podemos ver realmente el motivo. Así que desde luego desencaminados no vamos. Ojo, si no hemos cometido error a este paso la imagen tendría que verse en escala de grises de forma correcta. Pero por ahora pueden ser muchas cosas… podría ser debido a la conversión realizada por ImageMagick y como ha mapeado los niveles de 10 a 16bits, o podría ser que pese a que cada 10bits represente un pixel, podría ser que dichos píxeles no estuviesen organizados, como hemos presupuesto, uno tras otro. Podrían estar organizados de otros modos. Está claro que muy diferente no puede ser, o no tendríamos imagen. De todos modos podemos ver que hace algo mal… podemos apuntar la cadena de Bits y comprobar a mano el valor que tendrían por ejemplo los 10 primeros pixeles en 10bits, y compararlo con el valor que después de la conversión a 16bits estos mantienen… y vemos que el valor no se corresponde, ni siquiera se acerca. Posiblemente porque ImageMagick remapee todo el rango y lo escale, o simplemente tomemos mal los bits.

A este punto, se nos han acabado los amigos que nos solucionen la papeleta. Toca picar código. Para la tarea de crear un pequeño parser según lo que sabemos y a ver que pasa, podríamos hacerlo de cero de forma simple casi en cualquier lenguaje, o podemos hacerlo sobre alguna aplicación ya pensada para estos menesteres. En realidad hacer nosotros el parser por nuestra cuenta tiene la ventaja de no depender de nada mas y el código es simple, pero usar en este caos Dcraw nos da muchas más opciones a la hora de procesar. En principio la tarea es “sencilla”, un script/app que lea el archivo original y cree otro transformando cada 10bits en 16Bits. Mi primera idea, y creo que la lógica, es no mapear ningún tipo de color, sencillamente tomar  de 10 en 10bits, y meterlos cada uno en 16bits, conservando el mismo valor. Así si los primeros 10bits poseen un valor de por ejemplo 958, codificado en 2 Bytes sería 0x03be. El archivo final debería de poseer un tamaño 1.6 Veces mayor, ya que cada pixel pasaría a tener en teoría una profundidad de 16bits, aunque de ellos sólo se usarían 10. Recordamos que buscamos un resultado que podamos abrir y veamos claramente una imagen adecuada en escala de grises. El pseudocódigo de esto sería algo así, pensando en el stream de bytes como si se tratase de una “matriz” de bytes

Ancho_de_matriz = (Resolución_horizontal * 10) / 8
Columna = Fila = 0
Imagen = prueba.raw
Puntero_ArchivoNuevo = ImagenFinal.raw
Buffer, Buffer_Aux

Para (Fila < Resolución_vertical, Fila ++)
  Almacenar en Buffer la cantidad de Ancho_de_Matriz Bytes desde imagen //En cada interacción lee a partir del último valor leído
  Para (Columna < Resolución_horizontal, Columna += 4, Puntero_ArchivoNuevo += 5. Buffer_aux = Buffer)
    ArchivoNuevo [Fila, Columna] = (Buffer_aux [0] << 2) | (Buffer_aux [1] >> 6)
    ArchivoNuevo [Fila, Columna+1] = ((Buffer_aux [1] & 0x3f) << 4) | (Buffer_aux [2] >> 4)
    ArchivoNuevo [Fila, Columna+2] = ((Buffer_aux [2] & 0xf) << 6 )| (Buffer_aux [3] >> 2)
    ArchivoNuevo [Fila, Columna+3] = ((Buffer_aux [3] & 0x3) << 8) | Buffer_aux [4]

Visto así no hay quien lo entienda… pero en realidad es muy sencillo, es lioso porque hay que trabajar a nivel de Bits, y no de Bytes. La premisa es que hay un patrón que se repite, constantemente, y de ahí los dos bucles anidados. El patrón que se repite son las 4 sentencias finales. El bucle externo itera sobre cada fila, el interno por columnas. La única salvedad es que la iteración de columnas no toma columna a columna (byte a Byte) sino de 5 en 5 bytes. La razón es sencilla, si se codifican 10bits por pixel, el valor entero más cercano que a la vez sea múltiplo de 10 y de 8 es el 40. 40 Bits son 4 píxeles (columnas en archivo viejo) y a la vez son 5 Bytes leídos. Así que tratamos directamente con 5 Bytes a la vez, y repetimos hasta terminar.

La conversión lo único que hace es ir almacenando en otro archivo/buffer cada 10bits extraídos en 16bits, y para hacer eso lo más cómodo es desplazando los bits para un lado u otro. Vamos a ilustrar esto, pero de un modo mucho más sencillo, imaginemos que estos son los primeros 5 Bytes, y para facilitar la visualización vamos a obviar que usamos binario y que obviamente no podemos usar otros caracteres que no sean 0/1. pero hacer el seguimiento a los números es más cómodo.

Queremos pasar de esto: 11111111 22222222 33333333 44444444 55555555
A 16 bit, algo como esto: 00000011 11111122 00000022 22223333 00000033 33444444 00000044 55555555

Ejemplo paso a paso de las dos primeras columnas, las otras dos serían similares

Columna 0

Tomamos el primer Byte completo: 11111111, pero ahora tratamos los datos como 16 bits puesto que ArchivoNuevo está definido como tal, luego realmente tenemos: 00000000 11111111.
Lo desplazamos 2 posiciones hacia la izquierda: 00000011 11111100
Tomamos el segundo Byte competo: 22222222, y al igual que antes, tenemos realmente 00000000 22222222
Desplazamos hacia la derecha 6 posiciones: 00000000 000000022
Operamos con OR lógico los dos resultados previos: 00000011 11111100 OR 00000000 00000022 = 00000011 11111122

Columna 2

Tomamos el Segundo Byte completo: 22222222, realmente tenemos: 00000000 22222222.
Aplicamos una máscara AND antes de desplazar para evitar propagar los 2bits superiores, seteándolos a cero: 00000000 22222222 & 00000000 00222222 = 00000000 00222222
Lo desplazamos 4 posiciones hacia la izquierda: 00000022 22220000
Tomamos el Tercer Byte competo: 33333333, realmente 00000000 33333333
Desplazamos hacia la derecha 4 posiciones: 00000000 000003333
Operamos con OR lógico los dos resultados previos: 00000022 22220000 OR 00000000 00003333 = 00000022 22223333

 

Por desgracia, este primer parser nunca me funcionó. Tenía un resultado ligeramente mejor que el anterior expuesto, pero muy muy similar. Quizás ImageMagick hacía un trabajo parecido después de todo. Pero lo bueno de hacerlo uno mismo es que una vez realizado, modificar algunos detalles es trivial, solo hay que modificar, compilar y probar de nuevo. Después de darle unas cuentas vueltas opté por algo muy sencillo… pensemos en compatibilidad… en 5 Bytes tenemos 4 píxeles, ¿¿y si realmente la mayoría de esa información que nos interesa estuviese realmente en esos 4 píxeles?? Es decir, que pasa si eliminamos el quinto Byte y tratamos realmente cada Byte como tal (con una profundiad de 8 bits y no de 10) Contamos 5, usamos y asignamos los 4 primeros y descartamos el quinto. Además es mucho más fácil programarlo, es trivial, sólo hay que asignar directamente sin desplazamientos ni historias.

    ArchivoNuevo [Fila, Columna] = Buffer_aux [0]
    ArchivoNuevo [Fila, Columna+1] = Buffer_aux [1]
    ArchivoNuevo [Fila, Columna+2] = Buffer_aux [2]
    ArchivoNuevo [Fila, Columna+3] = Buffer_aux [3]

Compilamos, convertimos, el quinto no será usado nunca, ya que en el iterador interno contamos de 5 en 5:

No sé como tendréis calibrado los monitores, porque está algo oscura, pero para mi que eso es una imagen perfecta en escala de grises (bastante oscura eso sí), a la original. Pero entonces, ¿para que sirve ese 5 Byte? Bueno, en realidad cuando llegas a este punto piensas que es lógico. El sensor manda los datos en 10Bits, y que mejor forma que hacerlo por cuestiones de compatibilidad que “empaquetados” en Bytes normales, + 1Byte adicional que porta los 2Bits restantes de cada uno de los 4Bytes (píxeles) anteriores. Como en la prueba simplemente fueron eliminados, la conclusión es clara, el quinto Byte contiene los 2 bits LSB de cada uno de los otros, es decir, los Bits de menos peso en esos 10 Bits. La idea original era errónea:

11111111 22222222 33333333 44444444 aabbccdd
No pasa a ser:
00000011 11111122 00000022 22223333 00000033 33444444 00000044 aabbccdd

Pasa a ser:
00000011 111111dd 00000022 222222cc 00000033 333333bb 00000044 444444aa

Lo cual implica una gran diferencia. En realidad podrían asignarse al revés, y suponer que la asignación se hace al contrario, es decir que al primer byte le corresponde los dos MSB del 5º byte, y no los 2 LSB. Por desgracia los resultados son demasiado similares como tener una certeza exacta ahora mismo de cual de las dos asignaciones es la correcta. Sería necesario hacer capturas muy concretas para que las diferencias se diesen en un borde o un cambio suficientemente brusco como para percibirlo. Actualmente he optado por la segunda, por ser más simétrica, los 2 MSB para el primero, los dos siguientes para el segundo… pero da igual una que otra realmente. La implementación, teniendo en cuenta ya expuesta las otras dos, creo que es sencilla, así que la dejo en manos de quien le interese como ejercicio, y en todo caso si le interesa a alguien y no puede, que la pida. El resultado es similar al anterior, aunque una imagen bastante más clara. Si ampliásemos, podríamos observar, aunque en escala de grises, el patrón Bayer, en este caso en monocromo. Se podría multiplicar la imagen anterior para obtener una imagen mucho más clara, Si podemos capturar 10 Bits en vez de en 8 Bits, es precisamente para poder tener una mejor precisión de color y poder representar una paleta mayor, si en la conversión eliminásemos esos 2 bits de más empaquetados en el 5º byte, , pues la verdad es que le quitamos gran parte de la gracia al asunto.

La importancia de la imagen en escala de grises es por la propia naturaleza del sensor Bayer. En realidad cada pixel no representa una tonalidad de gris, sino una intensidad Roja, Verde o Azul, pero mientras que no se deshaga el mosaico bayer, podemos tratarla como si cada pixel fuese ni más ni menos como un pixel gris. Podríamos representarla tal como es, pero al menos que yo sepa no existe ningún visor digamos… Bayer, que represente el color de cada pixel en función de un patron dado, para dar una imagen similar a la expuesta en la apertura de la sección de Demosaicing. No obstante se podría hacer uso de Photoshop para representar el mosaico de un modo bastante fidedigno, creando el patrón RGGB, rellenando una capa sobre la imagen con dicho patrón… pero sería complicar las cosas, cuando lo principal está terminado. Photoshop es cierto que no posee ningún filtro o sistema sencillo para realizar la interpolación de colores (a menos que se haga desde CameraRaw e identificando la imagen), con lo que dcraw nos va a servir para hacer la interpolación. De ahí que, una vez creado el parser, si lo implementamos dentro de dcraw, tendremos en la misma herramienta todo lo que necesitamos. Por supuesto este es el caso específico del Mi6, pero como dije en su momento es extrapolable a cualquier otra imagen RAW capturada por los teléfonos/cámaras… con los correspondientes ajustes, por supuesto.

 

Dcraw

Una gran utilidad, y al ser además de código abierto podemos meternos en sus tripas, editar lo que deseemos, añadir… en realidad nos viene perfecta, ella misma está preparada para gran cantidad de formatos de cámaras, y hace precisamente todo lo que queremos hacer nosotros. Si hemos sido capaces de crear un parser para nuestra cámara, siempre y cuando no esté incluida ya, implementarlo/añadirlo a dcraw es sencillo, además de poder luego procesarla. El código de dcraw está publicado en la propia web del autor ya mencionado, quien quiera una copia fresca la puede obtener de AQUI. Está creada de forma sencilla en C sin dependencias raras y se compila sin problema con gcc:

gcc -o dcraw -O4 dcraw.c -lm -DNODEPS -l ws2_32

En este caso sería compilado para Windows, de ahí la inclusión de ws2_32 por ejemplo, pero se puede compilar para cualquier OS realmente.

Llos cambios necesarios son escasos. Necesitaremos crear el parser por un lado, una metadescripción de nuestro formato y una llamada a nuestro parser cuando se encuentre/identifique nuestra imagen. Como digo el código de dcraw es bastante limpio y con un poquito de tiempo se comprende bastante bien.

Así pues nuestra primera parada es la descripción de nuestro archivo. Sobre la línea 8300 vemos una tabla ya creada con lo que parecen descripciones de diferentes cámaras, así que la idea es incluir la nuestra. Esto podemos hacerlo no sólo con una, sino con las que queremos. Pero recordar que aquí sólo describimos por así decirlo la cámara. Para nuestro caso sería algo así:

{ 15482880,4032,3016, 0, 0, 0, 0, 1,0×94,0,0,”Xiaomi”,”Mi 6″ }

Es necesario buscar en el código el significado de cada campo, en la misma estructura queda más o menos puesto:

fsize: Tamaño del archivo en bytes
rw, rh: Resolución horizontal y vertical respectivamente
lm, tm, rm, bm: Márgenes izquierdo, superior, derecho e inferior
lf; load_flag (usado en varias partes del código para “marcar” ciertos archivos
cf; Filtro a usar, en este caso tendremos que especificar que queremos usar un filtro Bayer RGGB, 0x94.
max: máxima profundidad de bits usada
flags: Diferentes flags, como inversión de imagen y otros.
make: Fabricante
model: Modelo

Hay que tener en este caso concreto algo claro e importante. Recordemos que en el caso del Mi6 el archivo que se genera añade al final del archivo unos miles de Bytes adicionales. Si queremos procesar el archivo directamente sin necesidad de eliminar previamente dichos Bytes, tendremos que especificar el tamaño completo, con dichos bytes incluidos, y en nuestro parser asegurarnos que no se lee más allá. En el pseudocódigo anterior esto no es problema, ya que se lee hasta que la fila leída coincida con la resolución vertical, con lo que el resto se ignorará. Pero hay que tenerlo en cuenta, si el parser lee el archivo completo hasta final de archivo, podría incluir dichos Bytes. Es más cómodo especificar el archivo completo, y no hay que estar metiendo tijera, o en el propio parser tener que cortarlo. La captura RAW lee todo el sensor, así que la resolución siempre será la  máxima por regla general, y el tamaño de archivo también.

Una vez definido nuestro archivo, esta tabla permitirá que el archivo sea reconocido y pueda seguir adelante, aunque no significa que hayamos terminado. Esta tabla es muy útil porque si por ejemplo tenemos otro terminal que captura de un modo muy similar, casi tan sólo tendríamos que añadirlo a la tabla para que directamente funcionase, y usar el mismo parser creado. Sea como sea, lo siguiente es crear el parser tal como quedó dicho anteriormente, cada uno que lo desarrolle como quiera. Podemos colocar el código por ejemplo encima de “minolta_rd175_load_raw” y para seguir con la misma nomenclatura llamar a nuestro parser: “xiaomi_load_raw”. Podemos servirnos de los propios métodos ya creados en dcraw para facilitarnos el parser, pero la cuestión es que al final la “imagen” final resultante quede en raw_image, accedida desde RAW(row,col)

Y para finalizar, sólo queda añadir el salto a xiaomi_load_raw cuando detectemos el archivo en cuestión. Pensar que el parser creado no es específico para xiaomi, en realidad es un parser MIPI de 10bits, y dcraw carecía de él. dcraw sí incluye ya parser parecidos incluso para parsear raw bayer en 10bits, pero tendríamos algo similar al primer resultado que obtuvimos al presuponer que que los bits estaban totalmente serializados, y no empaquetados, como al final fue el caso. Así que podemos hacer uso de esa misma función, sobre la línea 8595 más o menos vemos diferentes case, para 8, 10, 12… bits. Desdoblamos el Case 10, y simplemente llamamos a  nuestra función del mismo modo que hacen otros:

load_raw = &CLASS xiaomi_load_raw; break;

Eso es todo, compilar y listo. Si todo es correcto tan sólo tendremos que invocar dcraw como dice en su propio manual y con los parámetros que queramos. La idea de usar Dcraw es múltiple. Por un lado podemos hacer uso de sus propias funciones para facilitarnos la tarea de crear nuestro parser, pero además nos va a permitir realizar a la imagen diferentes transformaciones/conversiones. Por supuesto, principalmente lo que haremos será la interpolación de colores para convertir nuestro mosaico Bayer en una imagen todo color, pero también es muy útil para ajustar algunos parámetros antes de realizar la interpolación. Recordar que es una imagen RAW, es decir, vemos lo que ha tomado el sensor, sin procesar, sin aplicar matrices correctivas, cambios de espacios de color… nada. Pero precisamente por eso usamos RAW, ¿no? Si queremos precisamente una imagen procesada, nos quedamos con el JPG.

 

Uso de Dcraw

Dcraw es algo así como un revelador RAW, toma una imagen RAW de entrada y la convierte/interpreta a un formato más amigable. Ya sabemos que cuando se lo ordenemos nos va a decodificar la imagen Bayer en una ¿bonita? imagen, pero depende de lo que le digamos, la salida será realmente sin procesar o podrá realizarle algunos ajustes básicos. Cuando una cámara dispara una foto en RAW, por lo general adjunta en ella un perfil DCP que especifica las transformaciones de color, tipo de sensor… y otros ajustes que deberían de ser necesarios (al menos de forma orientativa), para que la imagen sea visualizada de forma correcta. De echo gracias a estos perfiles incrustados la mayoría del software RAW que existe en el mercado (Como Adobe CameraRAW) se basa en estos perfiles para automáticamente aplicar dichos ajustes a la imagen y tener nosotros algo bonito en pantalla.

Muchos podrían pensar que estos ajustes matan el principio del propio RAW, que es tomar una imagen sin procesar. Realmente los perfiles no dictan como se ha procesado la imagen, sino como se podría procesar en función de la información del sensor que el aporta. Así podemos usar el perfil tal como está, o podemos realizar en el editor los ajustes que deseemos, pero desde luego nos suelen servir de base. Aquí de todos modos tenemos un pequeño problema añadido… al archivo RAW nuestro no se le añade ningún tipo de información adicional, ni cabecera. Eso quiere decir que la imagen que vamos a obtener en este caso es totalmente RAW sin perfiles que especifiquen nada… ya no sólo información para que el software de tercero sea capaz de parsearla, sino tampoco ajustes básicos que habría que tener en cuenta del sensor: Matrices de Color, de conversión de espacio de Colores, punto negro… y no es una tontería, porque la no tener una referencia de estos, tendremos que valernos de nuestras habilidades para ajustar correctamente tanto colores como balances de blancos y otros, de nuestra imagen. Sobre la pregunta obvia de si sería posible implementar en Dcraw igualmente matrices de ajuste específicas para cada cámara/dispositivo, la respuesta es que por supuesto, pero esto varía enormemente de sensor en sensor, con lo que no se trata de poder usar una de otro modelo para ajustar la nuestra. Por supuesto si damos con los parámetros que nos gustarían, podríamos hacer que aplicase dichas transformaciones, cosa que hacen muchos otros modelos/dispositivos. Yo no he tocado las matrices, no hay correcciones de nada en principio, quitando eso sí los ajustes al vuelo que permite realizar Dcraw y que ahora veremos. Recordamos que en Dcraw realmente ya especificamos resolución, tamaño de archivos… así que será por este tipo de identificadores por los cuales Dcraw sabrá que imagen estamos metiendo de entrada, no importa la extensión o el nombre.

Algunos ejemplos sencillos y las salidas resultantes:

1. Conversión “estándar”. Imagen resultante no lineal, en 8bits, interpolada, y escalada: dcraw -v -c Camera1_bayer10.bayer > Test1.pgm

Es muy similar a lo que sería la imagen JPG resultante procesada, excluyendo el balance de blancos y un estrechamiento en los niveles. Por razones evidente este tipo de conversiones no son lo que deseamos, para eso menos lío realizando la fotografía normal. La idea de RAW es poder jugar con el máximo de información de la propia imagen para procesarla nosotros de un modo mucho más fino, y en este caso hemos de un plumazo eliminado la linealidad de la imagen, así como la mayor profundidad de colores. Esto se puede solucionar especificando que se realice la conversión en 16bits (manteniendo los 10bits que capturó el sensor), o directamente especificando que se mantenga la linealidad en la imagen, que por defecto también fuerza la salida en 16bits, en vez de 8.

 

2. Conversión manteniendo la linealidad de la imagen y los 10bis de profundidad (convertidos a 16), interpolada y escalada: dcraw -v -c -4 Camera1_bayer10.bayer > Test2.pgm

Pese a lo que pueda parecer, es muy diferente a la anterior. En este caso no sólo existe un mayor rango de colores (no apreciables aun), sino que la imagen es lineal, de ahí a que parezca más oscura (incluso estando escalada). Esto es importante. Prácticamente la totalidad de los sensores de las cámaras tienen un comportamiento lineal, es decir, que el “valor” de cada celda/pixel que es recogido debido a la intensidad de los fotones que llega a ellos, es siempre proporcional. Dicho de otro modo, si por ejemplo para 10 fotones el sensor registrase en dicho pixel un valor de 20, para 20 fotones recogería un valor de 40. Esto puede parecer una tontería, pero la cuestión es que el ojo humano y nuestra percepción es de todo menos lineal. Las imágenes lineales suelen comprimirse sobre todo en las sombras, mientras que las no lineales se expanden hacia los medios tonos e iluminaciones, produciendo un comportamiento, aparente, de más homogeneidad:

Se puede apreciar perfectamente los dos efectos. Los picos o “vacíos” que se encuentran entre las diferentes curvas en la primera imagen se deben a la reducción de la profundidad de color, no presentes en la segunda. Así mismo se puede observar perfectamente la linealidad de la imagen, mientras que el primer histograma se esparce por la mayoría de la escala, la segunda imagen, lineal, se condensa en la parte izquierda, en las sombras. La cuestión es simple, si queremos tratar lo más RAW posible una imagen, es de sentido común que no la transformemos en no-lineal como se hacía en el anterior ejemplo. Aquí no no la convertimos en lineal, sino que la mantenemos lineal, al igual que mantenemos su profundidad de 16bits (1obits). Obtenemos una imagen mucho más fiel a lo que realmente capturó originalmente el sensor.

 

3. Salida RAW pura (sin interpolar), escalada y sin escalar: dcraw -v -c -4 -d/-D Camera1_bayer10.bayer > Test3.pgm

Cuando hablamos que la imagen no está interpolada, significa que no se ha revertido el filtro Bayer. Como ya dijimos no es que la imagen esté en escala de grises, es que realmente cada pixel corresponde a la intensidad de un color concreto. Esta imagen la hemos visto anteriormente. Si se representase en vez de en escala de grises en color, el resultado sería la imagen verdecina que vimos anteriormente. Por lo general, cuando se representan las imágenes sin deshacer el mosaico Bayer, es así como lo hacemos.

Por otro lado, hasta ahora todas las imágenes que se han puesto están escaladas. ¿Que significa esto? Recordar que estamos tratando con imágenes de 16 bits de profundidad y encima lineales. Eso quiere decir que en teoría cada pixel de dicha imagen puede tomar un valor entre 0 y 65535 (debido a los 16bits), y que debido a la linealidad “empezamos” en el cero (negro absoluto, ausencia de fotonos). Pero en cambio el blanco absoluto no existe como tal concepto, dado que el sensor en teoría siempre podría ser más sensible, captar más fotones y aumentar el valor aun más, con lo que hablaríamos del concepto llamado blanco más allá del blanco. Por eso vemos siempre una condensación en el extremo izquierdo en fotos lineales. Bien, ya hemos hablado de la linealidad, ¿pero el escalado? Bueno, es útil/necesario por dos motivos. El primero como se ha dicho debido a la linealidad y la compresión en el lado izquierdo, pero también porque nuestro sensor no es sensible a 16bits, es decir, a los 65536 posibles valores. Para 10bits, nuestro sensor “solo” es capaz de distinguir entre 1024 valores diferentes (recordar que todas las imágenes que vemos en fotos y otros generalmente están a 8bits, 256 valores diferentes), con lo que a efectos prácticos si no escalamos los valores esta sería negra o prácticamente negra entera (de ahí que no vaya a poner una imagen haciendo la prueba). Esto se soluciona de un modo sencillo, y es multiplicando literalmente el valor de cada pixel. En este caso tenemos 10bits = 1024, 65536 / 1024 = 64. Es decir, un factor de escala de x64. Dado que el sensor no es capaz de ir más allá de los 10bits, no vamos a tener pérdida de información, aunque por supuesto no se nos escapa que si el sensor fuese más sensible podríamos captar más detalle en los colores.

Si hacemos, esto, si escalamos la imagen, el resultado pasa de ser negro a ser la imagen que he puesto anteriormente. El parámetro d/D en Dcraw especifica siempre que la salida será sin interpolar, sin deshacer el filtro Bayer, la elección de un parámetro u otro, es que D no escala la imagen, mientras d la escala automáticamente en función del valor que el estima que es el adecuado analizando internamente la imagen. En este caso acierta, y aplica un escalado de x64. Hay que indicar que el mismo resultado lo podemos obtener perfectamente sin escalar la imagen, y haciéndolo manualmente. Por ejemplo en Photoshop, podemos acceder a los ajustes de niveles de la imagen y modificar la salida. Photoshop independientemente de la profundidad de color que se use, usa sliders de 256 valores, pero pese a que sólo muestra 255 saltos mantiene igualmente la información intacta y escala en función a ello. En este ejemplo concreto si no escalásemos la imagen, para tener el mismo resultado tendríamos que desplazar el slider de photoshop al valor 3. Sí, desplazar el medidor derecho que está en 255 al 3. Y magia, la oscuridad desaparece (256/64 = 4, 3 teniendo en cuenta que el cero cuenta.)

 

4. Conversión lineal, interpolada, escalada, con ajuste de balance de blancos, y otros: dcraw -v -c -4 -T -a -k 50 Camera1_bayer10.bayer > Test1.tiff

El parámetro k permite especificar el punto negro. Dado que escalamos la imagen, esta tiene a desplazarse hacia la derecha, haciendo que se produzca un “agujero” en la zona inferior. El cero absoluto originalmente es el cero, pero si cuando se tomó la imagen el valor más pequeño era el 100 (por ejemplo), al multiplicarse por 64 deja un hueco más… “grande” en el negro. Este ajuste permite desplazar de nuevo la imagen hacia la izquierda, restaurando el negro “puro”. Obviamente eso produce un oscurecimiento generalizado debido a que el desplazamiento es a toda la imagen, cosa que luego se podría corregir. Aun en este punto la imagen seguiría siendo lineal.

El otro punto importante es el balance de Blanco. El sensor capta lo que capta, y aquí no está calibrado hacia nada. Es por eso que la imagen se muestra verdosa si se interpola y no se toca nada más, los colores no son los que deberían de ser. El ajustar el balance de blancos pone punto y final al problema. Por desgracia esos ajustes dependen de la fotografía tomada y del sensor. Dado que no tenemos datos más o menos fiables del sensor, sólo podemos probar diferentes ajustes en función claro está de lo que vemos… prueba error. Dcraw incluye el parámetro “a” que permite evaluar la imagen completa y estimar el balance de blancos adecuado, pero como todo es siempre relativo. Por ejemplo para la imagen anterior, dcraw calcula que los valores adecuados para el balance de blancos sería:

1.122304 1.000000 1.947417 1.000437

Dcraw especifica el ajuste de blancos multiplicando cada componente (antes de la interpolación por supuesto) por un valor concreto. En un filtro Bayer tenemos 4 componentes recordemos, en nuestro caso es un sensor RGGB, así que cada multiplicador se aplica a cada uno de ellos, aunque no en ese orden. El orden de aplicación es R G1 B G2. Si nos fijamos, la imagen es muy verdosa, y efectivamente ambos componentes tienen un valor de 1 (o cercano a él). Por el contrario aumenta de forma considerable el componente azul. La imagen resultante es mucho mejor, pero como es natural no está a la altura.

Si creásemos el parser como un complemento en Photoshop para CameraRaw, este tipo de cambios serían totalmente interactivos, al igual que lo usamos para otro tipo de formatos. Por desgracia Photoshop no tiene forma humana de interpretar nuestro archivo, pese a que no es muy complejo. Eso nos “limita” en tanto que si queremos realizar un ajuste de blancos antes de la interpolación, lo tenemos que hacer manualmente. Por supuesto podemos corregir luego todo lo que queramos a la imagen, pero recordemos que ya será sobre la imagen interpolada. De cualquier modo, aun estaríamos con una imagen lineal, y de ahí la apreciación de una imagen “triste”, sin un colorido importante. Ya hemos dicho que el ojo humano no percibe la realidad igual que la tecnología, así que para que la imagen se ajuste a algo más vistoso, el paso final sería retocarla en cualquier editor para romper la linealidad y ajustar correctamente el resto de parámetros.

 

Apuntes finales

Aunque la modificación realizada a Dcraw afecta únicamente en primera instancia al Mi6, es extrapolable a cualquier otro teléfono o dispositivo que sea capaz de capturar imágenes de un modo similar. Gracias a la granularidad de Dcraw, añadir o quitar “perfiles” de cámara es sencillo, y si usan un sensor similar o un sistema que transfiera los datos de igual modo, es suficiente con añadir resolución, tamaño y patrón bayer correspondiente a la lista. No importa que sea un Mi6 o un Mi5 o por supuesto terminales de otros fabricantes, si la cámara reporta que es capaz de capturar RAW en algún formato, podemos añadirlo. Como es lógico, añado sólo el terminal con el que he andado jugando, pero animo a cualquiera que pruebe si le interesa.

No me gusta distribuir binarios, prefiero que el usuario se las apañe y aprenda a compilar por si mismo, pero dado que voy a publicar la herramienta en otro lado también, no creo que haga mal en esta ocasión a nadie distribuirla, y ahorrar el trabajo a algunos. La versión usada es la más actual hasta la fecha de Dave, 1.477, que he cambiado a 1.478. Los únicos cambios realizados son los expuestos: Añadir el parser, desdoblar la rutina de reconocimiento de 10bits para llamar al parser e incluir el Mi6 dentro de la tabla de cámaras. Realmente debido a las pruebas que hice tengo creado 4-5 parser diferentes, pero a efectos del código compilado es indiferente:

Enlace a dcraw compilado

 

Dado el interés que se han tomado algunos, en la medida que tenga tiempo y me manden los archivos necesarios, añadiré soporte a otros dispositivo, incluyendo obviamente el Mi6.

 

Actualizado (15 Sept 2017):

Soporte adicional para los siguientes dispositivos:

-Xiaomi Mi 6
-Xiaomi Mi 5

HTTPS no añade legitimidad o credibilidad a una Web, brinda seguridad

Llevo ya días que al despertarme me topo con alguna noticia relativa a HTTPS, supongo que los responsables son Mozilla y Google, que desde primeros de años decidieron aplicar algunas medidas coercitivas en sus navegadores, lo que sucede es que como siempre si el usuario medio no entiende lo que quiere decirle un cartel de advertencia, al final da igual.

 

Brevemente, sobre el mensaje “nuevo” que estas dos compañías han instaurado. Es un ejemplo más que muestra el trabajo que cuesta a veces a los usuarios de perfil medio la diferencia entre seguridad y legitimidad de una página. Muchos empezaron a decir incluso que Google iba a advertir con mensajes a los usuarios sobre que una web no era segura… no tiene nada que ver con eso, de echo tanto Firefox como Chrome muestran exactamente lo que tienen que mostrar, la lectura que otros le quieran dar es diferente:

La primera es el mensaje que muestra Firefox, el segundo Chrome, este último también traslada un mensaje en la URL. En esencia dicen exactamente lo mismo. Ambas compañías simplemente muestran en pantalla ese mensaje cuando se dan dos circunstancias: La primera, estamos en un formulario que se reconoce un campo de contraseña donde vamos a introducirla. La segunda es que la Web en cuestión en la que vamos a introducir dicha contraseña no está bajo HTTPS con un certificado válido. Dicho de otro modo, al no estar la web bajo HTTPS, los datos que pongamos tanto en la contraseña como en el nombre de usuario, es posible que sean enviados en “texto plano”, es decir, tal como los introducimos, y por ende podrían ser potencialmente interceptados por alguien que “pinchase” la conexión en cualquier punto de esta.

Hay que entenderlo, no significa que la web sea insegura realmente, o que no sea legítimas. Lo que nos avisa es que si nuestra red no es segura (nos están robando WIFI, tenemos un familiar/amigo travieso conectado a ella, usamos una red pública…), alguien podría potencialmente leer ese tráfico, y claro… a lo mejor no importa tanto saber que visitas una web concreta o incluso el contenido de ella, pero si importa y mucho si lo que capturan es la contraseña de tu correo electrónico, de acceso a un servicio. Pero repito, nada tiene que ver con legitimidad o fiabilidad, y es más, esa advertencia puede no ser importante si sabemos perfectamente desde donde nos conectamos.

 

Volviendo al asunto original del artículo, estoy aburrido de leer “noticias” sobre HTTPS, Certificados TLS/SSL, “seguridad”… y casi todos ellos sesgados. El último ha sido esta tarde… no me gusta tirar tierra a nadie y respeto el trabajo de cualquiera, pero creo que hay que ser más riguroso en lo que se escribe, y por citarlos, hablo de un artículo en Xataka. A veces una coma o el modo de decir las cosas no importa y se sobre entiende, pero otras veces el significado es muy diferente sólo con que falte un acento. En este caso, y cito textualmente encontramos el problema de siempre, algunas frases muy poco afortunadas:

“Esto quiere decir, que una dirección web en la que tengas que empezar escribiendo https:// en vez del clásico http:// será siempre mucho más segura, ya que certifica que la web visitada es legítima…”

“Chrome están empezando a señalar como inseguras todas las páginas que no lo utilicen”

No voy a valorar el resto del artículo, por supuesto dice cosas totalmente ciertas, el problema es que hay otras que no lo son.

Por un lado, sobre el comentario que se hace de Chrome, es falso, siempre he dicho que una media verdad no deja de ser una mentira, intencionada o no. Chrome NO SEÑALA las webs como inseguras cuando no están bajo HTTPS, Chrome, al igual que Firefox, lo que hacen es mostrar un aviso en el campo contraseña (y Chrome también en la URL) cuando existe un campo contraseña, y ese aviso, aunque pueda usar la palabra “insegura”, especifica bien claro a que se refiere, al envío de información cuando se rellena un formulario o cualquier otra cosa. Este aviso no aparece si dicha web carece de cualquier campo de este tipo, esté en HTTPS o no.

Sobre la primera frase, realmente es lo que me llevó a volver al blog, no por Xataka realmente, lo de ellos ha sido una noticia más haciendo alusión a eso de dar legitimidad a una web o no.

 

¿Qué es y qué no es HTTPS?

HTTPS se basa en autentificación y cifrado entre el equipo de origen, y el servidor destino, de forma bilateral (por lo general la autentificación la realiza sólo el cliente, no el servidor). Que un servidor use HTTPS para servir sus webs, poco o nada tiene que ver con que esa Web sea más segura, o que dicha web sea quien dice ser, con la única excepción de que use certificados tipo EV en todo caso (en lo relativo con la identidad, es decir legitimidad).

La necesidad de HTTPS nace precisamente de los cartelitos que ahora muestran Firefox o Chrome. Cada vez más usamos las conexiones inalámbricas, cada vez más hay desconfianza de los ISP (proveedores de internet) e incluso de los propios estados!! Quien no conoce a día de hoy los casos de Wikileaks y tantos otros. El cifrado no es algo nuevo, y creo que todos lo entendemos bien… algo que no esté cifrado no significa que no sea seguro, significa que si alguien lo intercepta lo va a poder leer.

No veamos HTTPS como un ente tan extraño, se puede simplificar enormemente, pensemos en vez de HTTPS y páginas web en una carta, en que quiero hacer llegar una carta a mi amada, y para ello no tengo más opción que dársela a un amigo para que a su vez se la entregue a ella. A nadie se le escapa el problema, incluso si pusiésemos un lacre sellado, mi amigo podría abrirla y leer el contenido, y si el contenido de la carta no usa un código secreto que sólo entendiese ella y yo, pues mi amigo se enteraría de todo. En función de la relevancia de las letras que ponga en esa carta, usar un código secreto entre los dos puede ser simplemente un juego, a ser totalmente necesario.

En Internet, el amigo puede ser tu hermano conectado a tu misma red, puede ser un vecino que te roba WIFI, puede ser un desconocido conectado a la misma red pública (WIFI o cable), puede ser incluso si quisiese tu ISP, por supuesto el gobierno… y eso sin contar absolutamente cualquier punto por el que tus datos son transferidos hasta llegar al servidor final. Al margen de conspiraónicos y que los gobiernos y los ISP nos espíen, el principal problema no son ellos, son las redes en las que nos conectamos. Puede que no me haga gracia que, en caso de hacerlo, un gobierno quiera interceptar mis comunicaciones, pero a fin de cuentas tampoco tengo nada que considere “personal” para ellos, más me preocupa que desconocidos puedan conocer mis datos personales, cuentas y otros.

 Sí, el cifrado puede ser algo positivo, pero desde luego desde mi punto de vista indispensable cuando manejamos información personal o evidentemente confidencial, y HTTPS soluciona esto. Ya hablé en su día largo y tendido sobre ello en uno de mis artículos, y recientemente también en el de Let’s Encrypt, donde por encima explicaba todo esto, aunque en menor medida.

Inicialmente hablaba de legitimidad… HTTPS trata sobre cifrado de datos, no sobre legitimidad. Sí, el servidor se autentifica/identifica de cara al usuario, pero no para certificar que el contenido de la página es legítimo, ni siquiera que la propia web lo sea!! Lo que certifica en todo caso (de tener un certificado digital reconocido y excluyendo los certificados EV que veremos luego) es que dicho certificado fue emitido para dicho dominio específicamente, nada más. Dicho de otro modo, que el certificado que nos llegue a nuestro equipo, poder ser validado para estar seguros que quien nos los mandó es la web que tenemos delante.

Y en ese párrafo está toda la madre del cordero. Xataka dice que certifica que la web que tenemos delante es legítima… no es cierto, la web puede decir que es Paypal, la web puede ser un calco perfecto de cualquier página de un banco, e incluso podrían tener un dominio similar!! y por supuesto, podrían usar perfectamente un certificado digital (y usar HTTPS) validado. Evidentemente a mi modo de ver las cosas, no considero eso como una web legítima. Esto es algo que se está empezando a hacer de forma masiva, por la falsa creencia precisamente del usuario de creer que si ve el candado verde la web es fiable, y es un error de base. Sí, la comunicación con dicha web se hace de forma cifrada y ningún vecino nos intercepta la comunicación, pero los datos que enviamos llegan igualmente al servidor, y si esa web la hace una persona malintencionada, evidentemente tiene acceso a dichos datos, datos que nos acaba de robar por creer nosotros que por tener candadito verde la web era legítima de fiar.

Pero por supuesto, que son unas letras sin una buena imagen. Ni siquiera he tenido que invertir tiempo en hacer una prueba propia sobre esto, simplemente me ha bastado con  mirar en cualquiera de los servidores usados para los registros de transparencia de certificados (por ejemplo https://crt.sh), que registran los certificados emitidos por las diferentes agencias CA que los usan, y mirar los dominios para los cuales se registran. Yo he buscado por Paypal, que contengan los dominios “Paypal”, por ejemplo, y el primer certificado que he encontrado que contenía su nombre ha sido el que pongo ahora en la imagen:

Antes de terminar de escribir este artículo, habré reportado dicha web, con lo que es posible que si alguien intenta acceder Google SafeBrowser la esté ya indicando como página de Phising, pero ahora mismo esta totalmente operativa. Como podemos ver perfectamente, la web está protegida por HTTPS, con su candadito verde, su “Es seguro”, con una URL similar a alguna que pueda tener una página real de Paypal, y por supuesto su contenido un calco. Bien, este es un ejemplo sencillo, poco o nada tiene que ver con que esté bajo HTTPS y el certificado sea válido, el contenido puede ser totalmente fraudulento. Ni que decir tiene que posiblemente de meter ahí los datos, se los enviaríamos a una personal mal intencionada, pero muchos creerían que como la URL parece ser “buena”, y que pone “es seguro”, es de fiar. ERROR!!

 

Let’s Encrypt, el CA del que ya hemos hablado en otra ocasión, está siendo foco de grandes críticas por muchos (no hace falta ser un genio para saber que la mayoría de todas ellas por no decir todas vienen de los otros CA). Se les acusa de emitir certificados fraudulentos. Bien, primero tendríamos que matizar que es un certificado fraudulento, porque el ejemplo que he puesto anterior de Paypal, no es un certificado fraudulento, es un certificado totalmente legítimo, lo que no es legítimo y lo que es fraudulento es el contenido de la web mostrada, así como el uso evidentemente de la propiedad intelectual de Paypal y la suplantación de identidad. El certificado es legítimo siempre y cuando quien lo solicitó demostrase que era el dueño de dicho dominio, y recordemos que el dominio no es Paypal.com, el dominio comprado en este caso es “paypal-secure-info.gq”. Dado que las normativas sobre dominio permiten el registro de dicho dominio (lo cual es normal, no pueden vetar un dominio simplemente porque contenga una palabra que es marca comercial), sería totalmente injusto vetar la emisión de un certificado para dicho dominio. El problema no es el dominio, el problema no es el certificado… el problema es el uso que se haga de ello.

Algunos dicen que Let’s Encrypt en la “poca” vida que llevan, ya ha emitido muchísimos más certificados de este tipo que llaman “fraudulentos” que el resto de CA juntos. No lo dudo, es muy posible, pero por una razón sencilla… con los otros CA tienes que rascarte el bolsillo, 50-100€, pero te los emitirían igualmente por mucho que digan algunos que no permitirían certificados en dichos dominios, a fin de cuentas si el dominio está registrado correctamente, la emisión de un certificado estándar (de tipo DV, validación de Dominio) solo requiere para cumplir con las estrictas normas de seguridad la validación del propio dominio, nada más.

Ante esto Let’s Encrypt ya ha dicho más de una vez lo mismo. Ellos no son la policía ni el organismo competente para censurar el uso que puedan o no dar otros a las web, eso será cuestión de otros, y que por suerte herramientas como Google SafeBrowser o Internet SmartScreen, están para eso. Repito, lo mismo sucede con cualquier otro CA. De echo, para curarse en salud, Let’s Encrypt tan solo emite certificados DV.

Muy diferente es el caso cuando se desea un certificado EV, esos certificados que añaden antes de la URL el nombre de la compañía. Esos certificados emitidos por un CA requieren una serie de verificaciones y burocracia muy superior, que precisamente buscan eso, que se pueda tener cierta confianza de que la web visitada corresponde al contenido que tienen. En el caso de la web de paypal fraudulenta puesta arriba, les sería imposible lograr que pusiese delante de la URL lo que realmente veríamos en una web de Paypal:


El contenido es exactamente el mismo, y al margen de que la URL sean diferentes, evidentemente, en esta vemos el “sello” del certificado EV “Paypal, Inc. US”. La anterior sería imposible que lo lograse, incuso lograr algo similar sería casi imposible, a caso iban a crear una empresa llamada Paypal Secure bla bla bla y lograr todo lo que se requiere?? No, no lo lograría. Pero eso no invalida el certificado DV, ni tampoco le quita la gran importancia/necesidad que estos certificados (DV) tienen. De echo, como explicaba en el artículo de Let’s Encrypt, los certificados EV son muy caros, y la mayoría de entidades no los usan por no ser necesarios, mucho más importante que mirar el sello EV es mirar la URL, que ojo… puede engañar también (otro día hablaré de ello), pero pensar que si tomásemos una empresa no conocida podría tener legítimamente su sello EV y ser igualmente fraudulenta por el contenido que tiene.

 

Hace unos días apareció la noticia de que Google castigaba duramente a los certificados EV de Symantec (uno de los grandes CA) por detectar durante años la emisión de EVs de estos sin las necesarias y más estrictas condiciones. Recordar que un CA es fiable sólo en la medida que los navegadores Web y otros software se fían de ellos y añaden en sus productos los certificados raíces de estos. Dicho de otro modo, en cualquier momento tanto Google, Mozilla, Microsoft… podrían bloquear/anular los certificados raíces del CA que quisieran, dejando los miles o millones de certificados emitidos por ellas totalmente inservibles. Es por eso que son aquellos que crean el software que nos conecta los que deciden que certificados añadir y que normas y condiciones tienen que cumplir para permitirles estar dentro de su software, y si no lo cumplen o detectan irregularidades, no tienen problemas en eliminarlos o castigarlos del modo que estimen. Y sí, han caído empresas grandes cuyo principal volumen de ingresos era la emisión de certificados porque los navegadores los bloquearon por emitir certificados fraudulentos.

Vale, pero he dicho que los certificados fraudulentos no son tales… en que quedamos. Bueno, he dicho que el ejemplo anterior no es un certificado fraudulento, pero claro que se pueden emitir certificados fraudulento. El ejemplo más sencillo, si mañana me pongo en contacto con un CA y les pido que me emitan un certificado para google.es, y me lo mandan, es un certificado fraudulento, y no porque ya exista uno legítimo, eso es indiferente, es fraudulento porque el dominio google.es no es mío, e incluso un certificado DV se debe de emitir sólo si se puede verificar la propiedad de dicho dominio. Peor aun si hablamos de certificados OV o EV.

En el caso de Google y Symantec, según se ha dicho en la nota de prensa, Google detectó irregularidades en la emisión de certificados tipo EVs, y ha optado por medidas bastante serias, y durante un año irá invalidando dependiendo de las fechas de emisión de estos, los certificados EVs de Symantec (si leí bien). Y esto no es poca cosa, eso causa un daño enorme a Symantec. Es en una de esas pocas cosas que vemos el tremendo poder que puede tener una empresa que desarrolla una navegador Web para con otras multinacionales de gran peso e importancia.. bueno, google es un gigante, pero pensemos en Google como desarrollador de Chrome. Por supuesto Symantec les ha respondido, que han exagerado los datos, que les parece un “castigo” desmedido, que en el peor de los casos que Google lo lleve a cabo re-emitirá certificados nuevos para todos los afectos para que no se vean afectos… etc etc etc.

 

Conclusión

Por supuesto la credibilidad y fiabilidad de un sitio es o debería de ser muy importante, el problema es que no existe un sistema para ello. La mejor forma de legitimar una web es conociéndola, mirando siempre muy bien las URL, usar tecnologías como Google SafeBrowser (usada en Firefox o Chrome) o Smart-Screen usada en Internet Explorer. Tener siempre la seguridad, sobre todo cuando vamos a introducir cualquier dato sensible que la web que tenemos delante ES la web que dice ser, y no fiarnos de si usa HTTPS para eso o no. HTTPS nos asegura un cifrado, no la identidad que pueda parecer decir ya sea por el contenido o por la URL. Eso no invalida para nada la necesidad de HTTPS, puesto que incluso aunque una web sea fraudulenta, puestos a escoger, dentro de los males el menos malo sería que usase HTTPS, al menos tendremos la seguridad de que los datos sólo nos lo roba quien hizo la web fraudulenta, y no además otro que nos espíe la conexión por no usar HTTPS.

Con la aparición de Let’s Encrytp la web ha dado un buen giro, y donde antes nadie usaría certificados, ahora el uso se está expandiendo enormemente, ya sea un blog personal (ya, lo sé, no se lo tengo puesto al blog, en casa del herrero cuchillo de palo), ya sean empresas, tiendas online… y eso es bueno, con independencia de que algunos los quieran usar para otros fines.

Pero no nos equivoquemos, la culpa no la tienen esos desalmados, ellos simplemente se aprovechan como siempre del desconocimiento de los usuarios, las empresas de CA se han empeñado durante años a decir que los certificados son necesario para la confianza, para la fiabilidad… y muchas campañas se han hecho acerca de esto, así que el usuario normal ha tomado por válido ciertas cuestiones, como que si la web tiene un certificado seguro, la página es segura = fiable = de_confianza.

HTTPS sí, siempre que sea posible y el certificado sea válido, pero por favor… no dejéis nunca de revisar bien y mucho ante la duda la web que los use.

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.