El pasado sábado, el Instituto Nacional de Ciberseguridad de España (INCIBE) vivió un episodio que ha provocado que se levanten muchas cejas en las redes sociales: los visitantes de su web pudieron comprobar de primera mano que el certificado digital de seguridad de la misma había caducado.

Esto es, que la web del organismo que vela por la seguridad informática de millones de ciudadanos y empresas españolas se volvió repentinamente "no segura" para la navegación, y todo por un trámite menor que una sencilla alarma podría haber evitado.

Pero esta situación, a priori anecdótica según muchos usuarios, revela profundas carencias en la gestión pública de infraestructuras digitales críticas.

"La conexión con este sitio web no es segura"

¿Qué es un certificado digital y por qué es crucial?

Un certificado digital es una herramienta criptográfica que garantiza que una página web es auténtica, segura y que cifra la información intercambiada con el usuario (es decir, permite que una web sea segura y cuente con el 'HTTPS://'). En la práctica, cuando accedemos a una página web segura, el navegador consulta el certificado digital del sitio para verificar tres aspectos fundamentales:

1. Autenticidad: Confirma que el sitio web es realmente quien dice ser y no una copia maliciosa que intenta suplantar la identidad (phishing).
2. Integridad: Asegura que los datos enviados y recibidos no han sido alterados durante la transmisión.
3. Cifrado: Protege la confidencialidad de la información intercambiada mediante algoritmos criptográficos.

¿Qué ocurre cuando un certificado caduca?

Cuando un certificado digital caduca, los navegadores modernos emiten una advertencia de “sitio no seguro” que desalienta a los usuarios de continuar. Técnicamente, esto significa que la garantía de autenticidad y cifrado ya no es válida.

Aunque la web aún pueda funcionar, el canal ya no es fiable, lo que abre la puerta a ataques como el Man-in-the-Middle (MitM), donde un atacante intercepta la comunicación sin que las partes lo sepan.

¿Por qué es especialmente crítico en organismos públicos?

Las webs institucionales del Estado tienen la responsabilidad de dar ejemplo en materia de ciberseguridad. Un error tan básico como dejar caducar un certificado puede:

• Dañar la imagen del organismo como autoridad técnica.
• Generar vulnerabilidades reales durante el tiempo que el certificado no es válido.
• Provocar pérdida de confianza tanto entre ciudadanos como entre empresas que dependen de esos servicios.

En Genbeta

España lleva años tirando dinero en "Amazons municipales". Así que un pueblo de 3.000 habitantes acaba de gastar otro medio millón

Ironías, parches y silencio

El incidente fue rápidamente difundido por el activista y 'hacker' Jaime Gómez-Obregón, que señaló la obvia ironía de que el organismo encargado de velar por la ciberseguridad nacional se dejara vencer por un descuido administrativo básico, y por carecer de una adecuada automatización de tareas elementales como la renovación de certificados.

Al poco tiempo, el problema ha sido 'resuelto' —recurriendo a un certificado gratuito de Let's Encrypt, que debe renovarse cada tres meses—, pero sin ninguna explicación oficial del INCIBE en sus canales habituales.

Síntomas (y más allá del INCIBE)

Como apuntaban varios usuarios, la solución a este tipo de problemas técnicos es trivial desde el punto de vista técnico: existen scripts, cron jobs y herramientas como Certbot que permiten renovar certificados automáticamente sin intervención humana. Que una entidad como el INCIBE no haya implementado estos mecanismos pone en entredicho la madurez tecnológica del sistema público de ciberseguridad.

Otro usuario revela otro dato sobre el INCIBE, en esta ocasión relativo a la transparencia sobre la seguridad de las webs de la Administración:

"Me acuerdo de que hice una solicitud de información al INCIBE sobre cuantas webs oficiales de organismos del Gobierno no tenían el certificado de seguridad, y me dijeron que eso era revelar datos sensibles y exponer la superficie vulnerable del gobierno".

En cualquier caso, este suceso no es un hecho aislado: el pasado mes de abril, se denunció una situación similar de caducidad de nada menos que el propio certificado con el que la FNMT firma el instalador para Mac del 'Configurador FNMT', junto con toda una serie de otros problemas que afectaban a la web del organismo.

Imagen | Marcos Merino mediante IA + Captura

En Genbeta | Miles de dispositivos perderán el acceso a la World Wide Web el 30 de septiembre, cuando caduque uno de los primeros certificados SSL 

Cuando navegamos por Internet, uno de los consejos de seguridad más comunes es revisar que la URL de los sitios web que visitamos comienza con "https://" (o, como suele decirse, "que tenga candado"), especialmente si vamos a introducir en ellos datos personales. Sin embargo, es importante entender que no siempre que una web cuente con HTTPS ésta estará libre de estafas u otras amenazas. Aclaremos algunos datos al respecto.

¿Qué es el HTTPS?

El protocolo HTTPS (Hypertext Transfer Protocol Secure) es una versión segura del tradicional HTTP, ahora diseñado para asegurar que la información transmitida entre el navegador del usuario y el sitio web esté cifrada. Esto impide que terceros (insistimos: terceros) puedan interceptar o leer los datos enviados durante la sesión...

... pero eso no garantiza que el sitio web sea seguro en su totalidad: puede utilizar HTTPS y aun así ser una fuente de amenazas como malware o estafas de phishing.

El candado de marras.

¿Qué son los certificados SSL/TLS?

HTTPS utiliza certificados SSL o TLS para asegurar una conexión segura, validando así la autenticidad del servidor al que se conecta el usuario... pero organizaciones como Let’s Encrypt ofrecen certificados SSL de forma gratuita, lo cual ha sido aprovechado por ciberdelincuentes para dar una falsa apariencia de seguridad a sitios maliciosos.

Recuerda: Los certificados SSL sólo validan que tus datos se envían cifrados al servidor, pero no nos dicen nada sobre qué hacen con ellos una vez llegan allí.

Estamos despistados

Según un estudio de Phishlabs de 2017, ya entonces el 25% de todos los ataques de phishing se realizaban desde sitios HTTPS... cuando sólo dos años antes ese porcentaje era menor del 1 %. Han pasado ya siete años desde entonces, y puedes estar seguro de que esa cifra no ha hecho más que subir.

Pero, a pesar de todo, muchos medios generalistas (¡e incluso las fuerzas de seguridad del Estado!) siguen repitiendo machaconamente y casi por costumbre el peligroso consejo de que nos fiemos de las webs con HTTPS.

Por aquel entonces, más del 80% de los usuarios creían que la simple presencia de un candado verde en la URL significaba que un sitio eraseguro y, por lo tanto, no se lo pensaban dos veces a la hora de introducir sus datos. Pero incluso con HTTPS, si el sitio pertenece a un atacante, éste puede visualizar y manejar la información que el usuario ingresa.

Recapitulando...

• Un sitio con HTTPS no siempre es seguro, así que intenta utilizar criterios complementarios para verificar su seguridad.
• Es importante estar alerta y no introducir información personal en sitios que no son de confianza, incluso si tienen "el candado".

Imagen | Wikimedia + Marcos Merino mediante IA

En Genbeta | El Banco de España ofrece estos siete consejos contra el fraude bancario digital

La apuesta por los dispositivos constantemente conectados a Internet requiere garantizar una mínima seguridad de sus conexiones, para dificultar que éstas puedan ser intervenidas de alguna forma. Y esa seguridad se garantiza, entre otras formas, mediante el uso de certificados SSL.

Empresas y entidades sin ánimo de lucro como Let's Encrypt se dedican a expedir estos certificados a los servidores online: son los conocidos como Certificate Authorities (CA). Normalmente, estos certificados deben ser renovados cada pocos años…

…pero, para que los dispositivos conectados a Internet puedan confiar en dichos certificados, deben tener preinstalados ellos mismos su propio tipo de certificados, los 'certificados raíz', cuya duración puede prolongarse entre 20-25 años.

Parecía que 20 años no pasarían nunca, ¿verdad?

El problema es que los primeros certificados raíz empezaron a expedirse hace ya, precisamente, dos décadas, por lo que ya han empezado a caducar. Concretamente, el primer certificado raíz expedido por Let's Encrypt, el IdentTrust DST Root CA X3, expirará dentro de tres días, el 30 de septiembre (a las 16:01:15 hora española, siendo exactos).

En Genbeta

Heartbleed y certificados SSL: por qué hay que renovarlos y por qué no se está haciendo bien

Para la mayoría de nuestros dispositivos ése será un día de lo más normal, pues hace tiempo que los proveedores de software y hardware habrán actualizado sus firmwares y sistemas operativos…

…sin embargo, aquellos otros dispositivos abandonados por sus fabricantes tras el fin de su soporte oficial y que, por lo tanto, han dejado de recibir actualizaciones, se verán de pronto sin acceso a la WWW. Eso incluye, por ejemplo,

• Sistemas integrados diseñados para no actualizarse automáticamente.
• Smartphones que ejecutan versiones de software de años de antigüedad.
• Versiones de macOS anteriores a macOS 10.12.1.
• Versiones de MS Windows anteriores a Windows XP Service Pack 3.
• Las PlayStations antiguas que aún no han recibido actualizaciones de firmware.
• En general, todo aquel software basado en OpenSSL 1.0.2 o anterior.

En el caso de Android, Let's Encrypt ha anunciado que ha lanzado un sistema de firma cruzada que 'compra' otros tres años de validez para los dispositivos equipados con Android 7.1.1 o inferior, si bien usuarios que usan versiones a partir de la 5.0 se les recomienda instalar un navegador Firefox para evitar problemas durante la navegación (incluye su propio certificado, al margen del sistema operativo).

Según afirma en su blog el investigador de seguridad Scott Helme, a causa de su gran popularidad la caducidad del IdentTrust DST Root CA X3 causará muchos más problemas que la de AddTrust, otro certificado raíz que ya caducó el pasado mes de mayo, y que ya entonces causó interrupciones en la disponibilidad online de Red Hat, Roku o Stripe:

"Al menos alguna cosa, en algún sitio, se va a romper".

Google Chrome sigue siendo el navegador más utilizado, y sus usuarios pronto podrán beneficiarse de una funcionalidad muy importante. Chrome 63 introducirá una nueva opción de seguridad que detectará cuando un software de terceros está realizando un ataque Man-in-the-Middle (MitM).

Los ataques Man-in-the-Middle (o ataque de intermediario) permiten leer, insertar y modificar los mensajes entre dos partes sin que ninguna de ellas sepan que han sido atacados.

Gracias a esta nueva medida de seguridad, los usuarios de Chrome 63 recibirán un aviso cuando haya demasiados errores en las conexiones SSL en muy período de tiempo muy corto. Dicho aviso te informará de que se podría estar produciendo un ataque.

Esta nueva funcionalidad de seguridad ha sido desarrollada por Sasha Perigo, estudiante de Stanford que desarrolló este software cuando estaba realizando las prácticas en Google.

Ya puedes probarlo en Chrome Canary

Si todo va bien, esta nueva opción llegará a Chrome el día cinco de diciembre. Mientras, los usuarios que estén interesados, pueden activar esta funcionalidad en Chrome Canary.

Para activarlo en Windows, solo tienes que seguir los siguientes pasos:

1. Hacer click derecho sobre el icono de Chrome Canary
2. Buscar la pestaña de "Acceso Directo" en las propiedades
3. Añadir "--enable-features=MITMSoftwareInterstitial" al final de "Destino" y aplicar.

En Genbeta | Cinco trucos que te ayudarán a sacar más partido de Google Chrome

"Comprometida una autoridad certificadora, todos sus certificados revocados". Suena mal, ¿verdad? Es probable que hayáis leído algo parecido a esto durante los últimos días a raíz de un descubrimiento de Google, o incluso con lo del desastre de Superfish y Lenovo. La cuestión es, ¿qué significa eso? ¿Qué es un certificado? ¿Qué es una autoridad certificadora (o CA)?

Desde luego, son cosas que no necesitas saber para vivir un día más. Pero igual que la mayoría sabréis qué es un troyano o qué hace un antivirus, saber qué es un certificado viene bien: al fin y al cabo, es una de las cosas que evita que alguien pueda ver qué páginas visitas y tus datos personales. Así que hoy nos vamos a dedicar a explicar qué son los certificados SSL.

"Hola, ¿quién eres?"

Supongamos que estás buscando a Pepe Pérez para contarle algo privado. No parece difícil, pero no sabes quién es Pepe. No sabes siquiera cómo es, si es un anciano, si es rubio... sólo sabes dónde está. Así que vas a donde suele estar, y ves a un hombre. Puedes preguntarle si él es Pepe Pérez, pero sería un poco ingenuo fiarse de lo que te dice un desconocido por la calle. Igual no es Pepe. Una forma de asegurarse de que es realmente él sería pedirle un documento, algo que certifique que esa persona se llama Pepe Pérez. En la vida real (pasando por alto lo poco real de esta situación) le pedirías su DNI, por ejemplo.

Necesitamos un DNI, pero para servidores de Internet.

Pues bien, en Internet pasa lo mismo. Necesitas un "DNI" para los servidores, un documento "oficial" que te asegure que ese servidor es el de Google y no un impostor. La cuestión es cómo lo hacemos oficial: necesitamos una autoridad de la que nos fiemos (como en el ejemplo de Pepe Pérez nos fiamos del Estado para expedir DNIs).

La solución a este problema son los certificados SSL, que más que un documento como el DNI son sellos. Tienen una parte privada, que se queda el servidor, con la que "sella" y deja una firma en las comunicaciones. El sello contiene el nombre de dominio y acredita que efectivamente te estás comunicando con Google. Además, nadie más puede replicarlo: no puedes coger un documento, recortar el sello y pegarlo en otro documento. De la misma forma, un intruso no puede interceptar una petición a un servidor, modificarla y reenviártela porque entonces el "sello" (firma) no sería válido.

La cuestión es que el proceso para hacer certificados SSL es público. Igual que puedes hacerte un sello que ponga "Presidente del Gobierno", puedes hacerte tú un certificado SSL para _google.com_. Para solucionar este fallo, los certificados SSL vienen firmados por las autoridades certificadoras (CA), o terceros de confianza. Estas autoridades se encargan de expedir los certificados, y sólo lo hacen si la organización o persona que los pide puede probar que efectivamente es propietario del dominio. En otras palabras: si vas a la autoridad certificadora a pedir un dominio para _google.com_ se van a reír de ti y te vas a quedar con las manos en los bolsillos.

Los navegadores y sistemas operativos se guardan las claves públicas de las autoridades certificadoras en sus almacenes. Con esas claves públicas, son capaces de verificar las firmas y comprobar que los certificados SSL de los servidores a los que te conectas son válidos y que por lo tanto no te estás conectando con un impostor.

Una vez que te has asegurado de que el servidor es quien dice ser, ya se puede establecer la comunicación cifrada con HTTPS (que ya vimos cómo funcionaba) y empezar a intercambiar datos privados sin que nadie más los vea.

Cuando el sistema falla

Sabemos que este hombre es un hacker porque lleva pasamontañas y un palo. Los hackers siempre llevan un palo.

Las autoridades certificadoras o CA no son más que empresas gestionadas por personas. Y las personas fallan (fallamos). A veces, esos fallos se convierten en fallos de seguridad enormes. Por ejemplo, en 2011, un _hacker_ entró en DigiNotar, una CA holandesa, y consiguió las claves privadas para firmar certificados SSL.

¿Qué se puede hacer con esas claves? Pues firmar certificados SSL, obviamente. El _quid_ de la cuestión está en que si la clave la tiene un _hacker_, lo más posible es que decida firmar certificados SSL para dominios que no tiene. Es decir, que puede hacerle creer a tu ordenador que su servidor "malvado" es el de Google y le engañe para que le envíe tu correo y contraseña (por poner un ejemplo). Divertido, ¿verdad?

En algún otro caso, directamente son las autoridades certificadoras las que hacen lo que no deben. En el caso del lunes, una CA estaba usando su certificado raíz para interceptar las comunicaciones seguras de sus empleados con Google. La polémica con Lenovo y Superfish era similar. La diferencia es que Superfish no era una CA, sino que instalaba su certificado raíz en los almacenes de los ordenadores para que la considerasen como tal y confiasen en sus certificados falsos.

Cuando esto ocurre, cuando las CA son comprometidas, hay varias formas de mitigar el impacto. Una de ellas son los certificados fijos (_certificate pinning_). Con ella, los últimos navegadores no sólo piden un certificado SSL válido para conectarse a ciertos sitios como Google sino un certificado con una huella concreta. De esta forma, forma aunque una CA confiable firme un certificado nuevo, no lo tomarán como válido. El problema es que sólo se pueden usar certificados fijos para los sitios más conocidos: sería absurdo guardar las huellas de todos los certificados de todas las páginas web seguras de Internet.

Por otra parte, también hay métodos para revocar certificados. Periódicamente, los navegadores y sistemas se conectan a los servidores de actualización y recuperan listas de certificados que han dejado de ser válidos, y van manteniendo el almacén actualizado y sin certificados comprometidos. Además, tú puedes acceder a tu almacén de certificados del navegador/sistema y quitar CA que no te gusten (aunque es posible que algunos sitios dejen de funcionar bien).

En definitiva, los certificados son lo que te permite confiar en que tus conexiones seguras son seguras de verdad y no estás hablando con impostores. Así, ya sabréis por qué frases como las que encabezan el artículo suenan realmente mal.

Imagen | devdsp

Hace unos días os hablábamos del fallo goto fail en la librería de SSL de OS X e iOS. Y, casualidades de la vida, hoy ha aparecido otro similar en GnuTLS, una librería de SSL para Linux, con consecuencias muy similares. Un atacante con conocimiento del fallo podría crear certificados que siempre serían aceptados como válidos por la librería, y espiar así comunicaciones aparentemente seguras.

En realidad, el fallo no tiene prácticamente que ver con criptografía. En la función encargada de verificar la validez de certificados X.509 tipo ASN.1, el desarrollador se equivocó al programar y no se interpretó bien el código de salida. Así, un código de retorno negativo que indica un error se convertía en un código de retorno distinto de 0 que indica que todo ha ido bien. Este esquema de @0xabad1dea lo explica con más claridad para los que sepáis programación.

*: Podéis ver qué aplicaciones dependen de GnuTLS ejecutando apt-cache rdepends libgnutls26 en Debian y derivados. Es posible que no todas las aplicaciones utilicen siempre GnuTLS sino que sólo lo tengan como opción.

Este fallo tan estúpido habría sido introducido hace 10 años. Es muy grave. La librería GnuTLS es ampliamente usada en Linux por varios programas para establecer conexiones seguras por SSL, y todas ellas se ven afectadas por la vulnerabilidad. Por ejemplo, aplicaciones^* como Chromium, el servidor Apache en ciertas configuraciones, Filezilla u OpenOffice usarían GnuTLS para establecer sus conexiones seguras. Alguien con conocimiento del fallo podría haber interceptado las comunicaciones usando un certificado inválido pero que no haría saltar ninguna alarma. Eso sí, es improbable que alguien haya tenido acceso a ese fallo.

Por suerte, el parche ya está disponible y muchas distribuciones lo tienen ya listo para que podáis actualizar.

Software libre, seguridad y casualidades

El primer tema que se nos viene a la cabeza con este fallo es el del software libre y la seguridad. Uno podría pensar que es muy curioso el hecho de que nadie haya visto el fallo (estúpido aunque no del todo obvio) en 10 años a pesar de que el código esté disponible para que cualquier lo mire. Por otra parte, también podríamos pensar que quizás si no hubiese sido software libre, la auditoría de RedHat no habría encontrado el fallo. ¿O quizás sí?

Este fallo cuestiona el mantra muchas veces repetido de "el software libre es más seguro porque hay más ojos para detectar bugs". La criptografía es un tema muy, muy complejo y lo que se necesitan no son muchos ojos inexpertos mirando por encima, sino sólo unos pocos expertos en el tema y con la motivación para hacer una auditoría a fondo, explorando y entendiendo el código.

Por otra parte, también resulta muy casual que se descubra ahora este fallo, tan cercano en el tiempo al de Apple y además muy similar. Uno podría especular con la relación de la NSA con este fallo, aunque por otra parte tampoco parece muy probable: por ejemplo, se pueden encontrar por Internet hilos de correo discutiendo el poco cuidado de los desarrolladores de GnuTLS. Como siempre, no hay nada seguro, aunque tampoco alimentaría paranoias de este tipo.

Vía | Ars Technica

Lavabit salió a la palestra cuando se descubrió que era el proveedor de correo electrónico que utilizaba Edward Snowden. Como os comentamos, el servicio se caracterizaba por garantizar una cierta seguridad.

Pues bien, ayer se descubrió que el gobierno estadounidense obtuvo una orden secreta para obtener la clave privada con la que las autoridades podrían obtener los correos de Snowden... y de los otros cuatrocientos mil usuarios del servicio.

¿Por qué solicitaron la clave SSL? En un principio intentaron obtener las credenciales con las que el usuario inicia sesión en el servicio (28 de junio). No obstante Lavabit cifra esta información, siendo totalmente imposible facilitarla. Si esta información no hubiera estado cifrada, habría bastado emplear un pen register para obtener uno de los paquetes con esta información.

Enviaron (hablamos del 9 de julio) una orden más estricta solicitando la única clave con la que se cifra la información del servicio, y Levison se resistió, velando por la seguridad del resto de sus usuarios (si hubiera entregado la clave habría comprometido la confidencialidad de los correos de todos los usuarios del servicio).

Para ser totalmente honestos, Levison entregó la clave SSL... impresa en once páginas, con un tamaño de fuente de cuatro puntos. Totalmente ilegible. Fue multado con 5000 dólares diarios hasta que entregara copias electrónicas de las claves. Finalmente el 8 de agosto Levison decidió cerrar el servicio y destruir la información.

Más información | Ars Technica | Wired Sitio oficial | Lavabit

Más vale tarde que nunca, deben de haber pensado en Yahoo. O al menos eso es casi lo que han dicho desde la EFF (Electronic Frontier Foundation) a raíz de que Yahoo por fin ha habilitado la posibilidad de usar HTTPS en su servicio de correo. Y sí, digo posibilidad porque se trata de una opción, no de algo que hayan incorporado por defecto.

Si queremos activar la conexión SSL debemos irnos a la configuración del correo (el engranaje en la parte superior izquierda) y, en la sección “General” (la primera que se nos abre), ir abajo del todo, donde encontraremos la casilla para activarla. Una vez guardemos los cambios, se nos pedirá ingresar de nuevo nuestra contraseña y, ahora sí, toda la sesión será bajo HTTPS.

La verdad es que me parece un tanto incomprensible que hayan decidido implementar esto como opción en lugar de hacerlo por defecto, aunque yo diría que es debido a que, al menos por ahora, no está funcionando todo lo bien que debería: según se puede leer en un artículo de la ayuda, algunos clientes de Yahoo! Pequeñas empresas están reportando problemas al adjuntar archivos con SSL activado.

Supongo que cuando solucionen este tipo de problemas, se pasará a una activación por defecto. Imagino que ha sido esta la razón por la que han incorporado la opción “a la chita callando”, sin realizar ningún comunicado más allá de la actualización de la ayuda. La opción se desplegó ayer y es muy posible que ya contéis con ella en vuestra cuenta. Ni que decir tiene que es muy recomendable, por no decir imprescindible, que la activéis.

Vía | The Next Web

Todavía con la resaca del nuevo algoritmo de Google, Panda, tenemos más novedades en el buscador. La primera está relacionada con el idioma: Google empezará a ofrecer resultados de búsqueda en inglés cuando busques en tu idioma.

Hay idiomas que se usan muy poco en la red: por ejemplo, si haces una búsqueda en suajili encontrarás muy pocos resultados. Google pretende quitar la barrera del idioma, y empezará a ofrecer algunos resultados en inglés. Si Google encuentra páginas inglesas que son relevantes para tu búsqueda, entonces aparecerán algunas entre los resultados habituales. Desde ahí, puedes ir tanto a la versión original como a la traducida.

A mí me parece una idea muy buena: facilita el acceso a la información que no está en tu idioma, da resultados más relevantes y seguramente ayude a aprender inglés, que nunca viene mal. De momento, los resultado en inglés sólo aparecerán si buscas en alguno de estos 14 idiomas: africano, malayo, suajili, serbio, eslovaco, macedonio, eslovenio, noruego, indio, catalán, maltés, islandés, galés y albanés. Si leéis Genbeta, probablemente os veréis afectados (como mucho) al buscar en catalán.

La segunda novedad es la conexión SSL por defecto en las búsquedas de Google para todos los usuarios registrados. La búsqueda segura en Google apareció ya el año pasado, pero hasta ahora era opcional y sólo si entrabas directamente a https://www.google.com. Ahora, cualquier usuario que haya entrado con su cuenta de Google será redirigido a la versión HTTPS.

¿Ventajas? La búsqueda está cifrada, y, lo que es más importante, nuestra cuenta de Google está más protegida. ¿Desventajas? Los sistemas de estadísticas dependían de la URL de la que venías (el referrer) para saber con qué términos de búsqueda habías llegado a una página. Ahora, como la búsqueda está cifrada, el sistema sólo podrá saber que has venido de Google, nada más. Para estadísticas de búsqueda habrá que ir a Google Webmaster Tools, que ofrece datos más limitados y generales

En resumen: incluir la búsqueda segura es bueno para los usuarios, pero no creo que le haga mucha gracia a los administradores de webs que dependan de las estadísticas.

Vía | The Official Google Blog | Inside Search

Una importante vulnerabilidad ha sido descubierta en el protocolo SSL (Secure Sockets Layer), que protege la mayoría de los sitios Web. El agujero de seguridad permite a los atacantes descifrar los datos que se pasan entre un servidor Web y el navegador del usuario.

La vulnerabilidad reside en las versiones 1.0 y anteriores de TLS (Transport Layer Security), base de confianza en la seguridad de las conexiones en Internet. Aunque las versiones 1.1 y 1.2 de TLS, no son vulnerables, la mayoría de los navegadores y sitios Web no las soportan. Por este motivo, las transacciones cifradas en portales como PayPal, GMail y otros muchos, son vulnerables al espionaje de los hackers, que pueden controlar la conexión entre el usuario final y el sitio web que está visitando.

En la conferencia de seguridad ekoparty (Buenos Aires), los investigadores Duong y Juliano Rizzo, van a realizar una demostración con un código al que denominan BEAST, abreviatura de Browser Exploit Against SSL/TLS.

BEAST emplea Javascript y un sniffer de red para descifrar las cookies y acceder a cuentas restringidas de usuario. El exploit funciona incluso contra sitios que emplean HSTS (HTTP Strict Transport Security), que impide que las páginas se carguen si no están protegidas por SSL.

En la demostración, va a descifrarse una cookie de autenticación utilizada para acceder a una cuenta de PayPal, según ha manifestado Duong. Según confirma la fuente del artículo, dos días después del anuncio, Google ha realizado una actualización en la versión de desarrollo de Chrome, diseñada para frustrar este ataque.

Vía | The Register (Vulnerabilidad, Actualización Chrome) Imagen | DaveBleasdale