SSL Encryption

Chrome advirtió el día 17 de que se actualizaba para revocar una serie de certificados digitales. Mozilla advirtió el día 22 de marzo de que actualizaba su navegador porque había incluido en él certificados fraudulentos. El día 23 es Microsoft la que confirma que debe actualizar su lista de certificados porque incluye varios inválidos. ¿Qué significa todo esto? ¿Qué pasa con los certificados?

¿Para qué sirven los certificados?

SSL debería cumplir dos funciones. Establecer una conexión cifrada sobre un canal público y también autentica al servidor. Nos ayuda a estar seguros de que el servidor es quien dice ser y también que pertenece a la empresa a la que debería pertenecer. Para la parte de autenticación, los servidores con SSL activo ofrecen al navegador un certificado para que lo compruebe, que es como una especie de DNI. En él, una autoridad (Verisign, Comodo…) certifica con su firma que la clave pública realmente pertenece al sitio.

El sistema de confianza en certificados tiene una estructura de árbol invertido y las raíces son estos certificados. El sistema confiará en todo lo que emitan. Si esto no ocurriese de esta forma y los navegadores o sistemas operativos no contasen con una serie de certificados raíz por defecto, no podríamos confiar en la identidad de las páginas, puesto que nadie lo acreditaría. Por el contrario (y como ocurre en realidad) se introducen demasiadas autoridades certificadoras en las que se confía (demasiados “Estados” que emitan el DNI), estas se vuelven el punto débil de la cadena, puesto que se confía en ellas y a su vez, en todo lo que ellas confíen. Un árbol con demasiadas “raíces” es más difícil de controlar. Además, las autoridades certificadoras confían en autoridades intermedias que le alivian el trabajo.

Qué ha pasado

Tanto Chrome como Mozilla como Internet Explorer (a través de la Trusted Root Certification Authorities Store) incluyen de serie una serie de certificados raíz en los que se confía, emitidos por autoridades certificadoras. Varios de estos certificados pertenecientes a Comodo han sido revocados porque se ha comprobado que han sido emitidos de forma fraudulenta sin su consentimiento.

Según ha anunciado Comodo (en una nota de prensa tardía, una vez que ya se había descubierto el asunto), un atacante con IP de Irán se hizo con usuario y contraseña de una autoridad secundaria de Comodo en el sur de Europa. El atacante utilizó estos datos para hacerse pasar por esa autoridad secundaria y emitir certificados fraudulentos de páginas como login.live.com, mail.google.com, www.google.com, login.yahoo.com, login.skype.com, addons.mozilla.org… Traducido: un atacante quería obtener certificados de esos dominios para hacerse pasar por ellos. Pero… ¿cómo puede ser, si ya existen? ¿Para qué emitir certificados válidos de dominios a los que no puedes suplantar? Esta es la segunda parte del problema: para que esto le sea útil al atacante, necesita:

* Emitir certificados válidos. Lo consiguió comprometiendo a esta entidad de Comodo.

* Que se le muestren como válidos a la víctima en su navegador. Esto es lo que hacen ya de por sí los navegadores con sus certificados raíz. Ahora que la mayoría los han revocado, esto no sería tan sencillo.

* Interponerse en el sistema DNS de la víctima. Bien por pharming, por “hombre en el medio”, troyanos o por cualquier otro método que redirija la resolución de dominios de la víctima.

Así, el atacante redirige a “otro” dominio a la víctima, e instala ahí el certificado que ha robado. A partir de ahí, podría o bien suplantar a la otra página o bien redirigir a la víctima a la original. El asunto es que, en cualquier caso, tendría acceso a toda la información, cifrada, que se transmita entre la víctima y el dominio al que quiere acceder. Aunque estuviese cifrada, aunque aparezca el candado en el navegador al visitar esta página, o la barra de navegación en verde, e incluso se compruebe la cadena de certificación… no solo el navegador dará por legítima la página, sino que el atacante podrá leer toda la información cifrada que se transmite.

Si unimos que el ataque a Comodo no habrá sido “sencillo” (se trata de uno muy sofisticado y dirigido), que la IP proviene de Irán, que el atacante emitió certificados para páginas muy conocidas, y que necesita además, para que esto sea efectivo, tener acceso a un cambio en los DNS… todo apunta a un ataque que, cuando menos, inquieta.

SSL (Secure Sockets Layer, capa de conexión segura) y TLS (Transport Layer Security, capa de seguridad del transporte) son dos métodos utilizados para ofrecer cifrado y integridad de datos en las comunicaciones entre dos entes a través de una red informática.

Desde ahora, un usuario de Twitter podrá configurar su cuenta para que utilice este cifrado por defecto. Se debe acceder a la configuración de la cuenta y marcar “Usar siempre HTTPS”. Esto lo protegerá de robo de tráfico en redes internas, por ejemplo. Además de que permitirá garantizar en todo momento que el usuario se comunica con el servidor legítimo.

Las aplicaciones de terceros basadas en Twitter pueden desde este momento implementar esta nueva medida de seguridad para sus clientes.

La empresa Mouse in the House han hecho un trabajo interesante al estudiar la velocidad de conexión o de redirección de los acortadores de URL’s. El más rápido, el de Google; el más lento, el de Facebook.

La mayoría se tarda alrededor de un segundo como bit.ly, mientras que binged.it, tinyurl.com y el twt.tl demoran alrededor de medio segundo. Los mas sobresalientes son los servicios de Google, youtu.be y goo.gl, que se demoran alrededor de 0.3 segundos solamente. Por otro lado, fb.me nos muestra el sitio más de dos segundos después, convirtiéndolo en el mas lento de todos.

Fuente: Bitelia.

Facebook Only Pidgin

Facebook only pidgin

2. * En la pestaña “Básica”, introduce estos datos:
* Protocolo: XMPP

Nombre de usuario: [tu nombre de usuario o correo]
* Dominio: chat.facebook.com
* Recurso: Pidgin
* Contraseña:
* Alias: [Tu Alias]
3.
* Haz clic en la pestaña “Avanzada” y dale los siguientes datos:
* Puerto de conexión: 5222
* Servidor de conexión: chat.facebook.com
* (Desmarca la casilla “Requerir SSL/TLS”)

Via: Linuxeando.CL – Chat de Facebook en Pidgin con protocolo XMPP.

Internet Corporation for Assigned Names and Numbers (ICANN) es la organización que regula los nombres de dominio, direcciones IP y protocolos de Internet en el mundo.

ICANN anunció ayer Viernes 30 que a partir del 16 de Noviembre de 2009, en los navegadores web podremos escribir direcciones web con caracteres no latinos, es decir, árabe, hebreo, cirílico, coreano, chino entre otros.

Peter Dengate Thrush, directivo de ICANN afirma: “La inclusión de caracteres no latinos en las URL es el mayor cambio técnico en Internet desde que fue creado hace cuarenta años“.

Rod Beckstrom, presidente de la misma organización: “Los primeros países que participarán en esta iniciativa ayudarán a atraer a internet a miles de millones de personas que no usan el alfabeto latino en su vida diaria“.

Aunque en un principio, los países sólo odrán incluir caracteres especiales en sus propios dominios, es decir, Rusia por ejemplo agregará caracteres cirílicos en direcciones web terminadas en .ur

Fuente: ABC en español