Por: Nodiel Clavijo Llera
¿Cuántas veces te ha pasado que el navegador de tu teléfono, laptop o cualquier otro dispositivo inteligente, ha mostrado una advertencia –nada agradable y bien molesta de evadir– cuando intentas iniciar sesión en tu cuenta de WIFI Nauta? ¡Casi siempre! A no ser que hayas encontrado una solución: cambiaste de navegador a otro menos “trágico”; buscaste ayuda de tu “especialista personal en computadoras” (yo nunca me he conectado a una WIFI Nauta, y aquí estoy hablando como uno más) e invocó algo de sus artes oscuras en tu dispositivo; o, la más común quizás: te aprendiste de memoria el laberinto a recorrer para ignorar al “dramático” de tu navegador.
Cualquier navegador que valga la pena (Google Chrome, Mozilla Firefox, Safari, Opera, Internet Explorer), debe dejar bien claro que lo que estás a punto de hacer es riesgoso; la privacidad de tus datos, los que transmites y recibes del sitio al que intentas acceder (tus credenciales de Nauta en este caso), pueden verse comprometidos. Sí, no estoy haciendo más que repetir lo que ya te había informado ese señor navegador, pero por mucho que se diga no hay forma de dejar esto todo lo claro posible sin saber qué está sucediendo detrás del telón.
Con un miedo terrible a sobre simplificar, intentaré aclarar un poco las cosas en este asunto. Así, la próxima vez que estés a punto de maldecir al bueno de tu navegador, tal vez lo veas como el hermano mayor que cuida de ti y tus decisiones.
Aviso de intento de acceso a una conexión no privada. Foto: Cachivache Media.
Comencemos por lo básico. La internet que te llega en forma de páginas web está regida mayormente por el protocolo HTTP o Hyper Text Transfer Protocol (protocolo de transferencia de hipertexto, en español) algo así como la lengua en la que hablan tu navegador y esa computadora lejana detrás de www.google.com, por ejemplo (de forma genérica llamémosle servidor web o servidor). Este protocolo es bastante simple de leer, es decir, tu información viaja en texto plano hacia el servidor.
Existen montones de herramientas y técnicas para “engañar” a tu computadora y hacer pasar esa información a través de un intermediario malintencionado en tu misma red local (la red de tu oficina, la de los puntos WIFI Nauta, etc…), y no se requieren conocimientos avanzados para aplicarlas en una red desprotegida.
Es muy probable que te estés preguntando:
¿Cómo es que las personas pueden poner su información bancaria en una paginita ahí conectados desde cibercafés y otros lugares “inseguros”, sin que se filtren sus tan preciadas credenciales?
Sucede que HTTP tiene un amigo mucho más discreto e inteligente, HTTPS o Hyper Text Transfer Protocol Secure (protocolo seguro de transferencia de hipertexto, en español) que habla la misma lengua que su variante insegura HTTP, con una diferencia: los datos viajan envueltos en un canal de comunicación seguro. Este canal se materializa gracias a los protocolos de SSL/TLS, que se encargan de garantizar privacidad y autenticación. En otras palabras: certifica que “estás hablando con quien dice ser, y que solo ambas partes pueden entender esa conversación”.
Tratemos de enumerar y explicar (sin perdernos demasiado en los detalles) los pasos que suceden de forma transparente al usuario cuando accede a un sitio a través de HTTPS.
Digamos que iniciaste una conexión a https://www.google.com desde tu navegador. Lo primero que nos presenta el servidor es su “certificado digital”. Este certificado es un documento que contiene información sobre su dueño –en este caso Google– y una firma digital para validar que fue emitido a este por una Autoridad de Certificación (o CA por sus siglas en inglés).
Para ponerlo en clave lega: supongamos que eres una persona en extremo desconfiada y solo aceptas conversar con tus amigos y los amigos de tus amigos. Si alguien intenta entablar un diálogo contigo, primero verificas si forma parte de tu lista de amigos; sabes cómo lucen y no te sería difícil identificarlos. ¿Cómo reconocerías a las amistades de tus amigos entonces? Muy fácil; estos reparten entre sus conocidos cercanos un papel con su firma, la cual conoces. Entonces, si esta persona extraña te enseña un papel con la firma de alguien en tu círculo amistoso permites la conversación; en caso contrario, lo ignoras y sigues tu camino.
Casi de la misma manera funcionan los “certificados digitales”. Los sitios web que deseen permitir conexiones seguras o HTTPS, deben primero obtener un certificado firmado digitalmente por una CA. Estas Autoridades de Certificación son entidades de confianza responsables de asociar mediante un documento digital o certificado, la verdadera identidad del poseedor. No solo basta con que el servidor de google.com nos diga: “este que… si… ¡soy google!”, sino que debe decir: “soy google, ten este papel firmado por esta CA (Symantec, GeoTrust, DigiCert, etc…)”. Generalmente los navegadores traen consigo una lista predefinida de autoridades en las que confía, y también lo hará de los certificados firmados por alguien en esta lista.
Para este caso, una firma digital es una secuencia de caracteres que se genera a partir de la información de a quien se emite y de una clave súper secreta que solo posee la Autoridad de Certificación, usando un algoritmo que hace prácticamente imposible adivinar la clave secreta a partir de la firma y la información del poseedor. Es de esperar que estas entidades certificadoras sean sometidas a auditorías de seguridad muy estrictas, aunque esto no ha evitado que por falta de verificación, se hayan emitido certificados identificando grandes empresas, por ejemplo Microsoft, a personas totalmente ajenas.
Muchas personas se conectan a través de dispositivos móviles a las conexiones wifi NAUTA. Foto: Fernando Medina Fernández / Cachivache Media.
Verificada la credibilidad del servidor que responde al nombre de www.google.com, el navegador sabe que iniciará una comunicación cifrada con el servicio legítimo que hará buen uso de nuestros datos, pero primero veamos lo que son los algoritmos criptográficos de llave simétrica y asimétrica, y luego, cómo se usan en esta conexión cifrada.
En el terreno de la criptografía existen varias clases de métodos para ocultar información. En especial, para este caso, hay dos de los que nos gustaría saber, uno llamado llave pública o llave asimétrica, y otro llave simétrica. Los algoritmos de llave asimétrica se basan en que cada parte posee un par único de claves o llaves, una pública y otra privada, la pública se le distribuye a quien quiera comunicarse contigo y se usa para cifrar el mensaje, mensaje que sólo podrá ser descifrado por tu llave privada. Por lo general, estos algoritmos usan problemas “difíciles” de los que hasta ahora no se conoce solución “rápida”, por ejemplo, RSA, que se aprovecha del desconocimiento, por el momento, de un algoritmo eficiente para la factorización en números primos de enteros.
Los de llave simétrica son en los que existe una sola clave con la que se cifran y descifran los mensajes, debido a esto ambas partes deben acordar esta clave de antemano de una manera secreta. De seguro alguna vez usaste alguna forma de criptografía simétrica para ocultar el texto de un mensaje, quizás en tu aula de clases o en tu diario. Creabas una tabla de sustitución de letras, por ejemplo: a la “A” le hacías corresponder la “X”, a la “C” la “B” y a la “S” la “R”, entonces “CASA” se volvía “BXRX”; solo bastaba aplicar la sustitución a la inversa y obtenías el texto inicial.
Después de este “pequeño” paréntesis podemos revelar un ingrediente vital del certificado para su uso, la llave pública, en este caso de Google.
Llegados aquí nuestro navegador ya posee la llave pública de google.com, incluida en el certificado, y la puede usar para cifrar el mensaje en el que acuerdan qué algoritmo de llave simétrica y clave usar en la comunicación que sigue a continuación, que solo podrá ser descifrado por el servidor en posesión de la llave privada o secreta. ¿Y por qué el navegador no genera un par de llaves pública/privada y se comunican así? La principal razón es porque los algoritmos de llave simétrica son más eficientes y rápidos, y pueden lograr la misma seguridad con claves mucho más pequeñas que los de llave pública. Cabe aclarar que toda la información que pasa cifrada de esta manera podría ser interceptada por cualquier servidor intermedio pero sería prácticamente imposible de descifrar.
Ahora, ¿qué tiene todo esto que ver con el error de la WIFI Nauta? Pues resulta que el servidor en el que introduces tu nombre de usuario y contraseña, está habilitado para una conexión HTTPS, pero nos presenta un certificado inválido, esto puede ser debido a que no está firmado por ninguna Autoridad de Certificación que tu navegador confíe, la gran mayoría de estas autoridades son norteamericanas y el bloqueo impide que sean emitidos a dominios .cu. Aun así, existe un puñado de ellas, confiables, que no radican en Estados Unidos, aunque pudieran ser revendedoras de las principales y por tanto sujetas a las mismas leyes.
Una descripción gráfica de un ataque informático MITM. Ilustración: Progreso Semanal.
Si no está firmado por ninguna autoridad, entonces es auto-firmado, que es como se hacen las Autoridades de Certificación de sus propios certificados. En el caso que nos ocupa puede estar auto-firmado por Etecsa (que no se encuentra en tu lista de entidades confiables), y de ser así ignorar el error no trae problemas, pues tu información será cifrada correctamente como si nada hubiera pasado. Pero pudiera suceder es que estés siendo víctima de un ataque informático MITM (Man In The Middle u Hombre en el medio, en español) por alguien en tu red local en donde el atacante “engaña” a tu dispositivo y hace pasar toda la información que envías y recibes a través de él, pero si usaras el certificado original del servidor le sería imposible descifrar tu comunicación, por lo que te presenta otro generado por él, auto-firmado por “Pepito Perez”, y como es usual ignoras esta advertencia, aceptas este certificado desconocido y tu dispositivo cifrará con la llave pública del hombre en el medio, el que también posee la llave privada para descifrar todo lo que envíes, y desgraciadamente tu antivirus o firewall ni se entera.
Quizás el atacante simplemente puede presentarte una conexión HTTP en la que el navegador ni protesta. No me extraña oír tantos casos de cuentas robadas. No me atrevo a dar total seguridad que esta sea la vía, pero es más que factible.
Resumiendo, mis recomendaciones
Primero: no uses más ese navegador “machote” que no se queja, que su valentía no es más que un sinónimo de “inseguro”.
Segundo: intenta descargar el certificado de Etecsa e instálalo en tu dispositivo (la vía varía mucho de dispositivo en dispositivo), esto hará que el error solo aparezca en caso que estés siendo engañado por otra persona y no deberías continuar. Si no sabes cómo hacerlo, llévale este párrafo a tu “especialista personal”, él sabrá lo que hacer.
Los protocolos descritos anteriormente se especifican detalladamente en grandes documentos, explicando cómo deberían funcionar. Estos protocolos son materializados (implementados) por simples mortales que también tienen días malos y se equivocan, por lo que tales implementaciones no están exentas de fallas que las hacen vulnerables. Como ejemplo, el sonadísimo error o bug Heartbleed, en el que, al enviar un mensaje malformado al servidor vulnerable, permitía revelar fragmentos de hasta 64kb de su memoria privada en los que se podían encontrar contraseñas, información personal e incluso hasta la clave privada asociada a su certificado. Este pequeño error puso a temblar todo servicio en internet (una gran parte) que usara la implementación más popular de SSL/TLS: OpenSSL.
P.D. Si sabes del tema y detectas algún error, agradeceríamos que nos dejaras tu “pull request” en los comentarios.
(Tomado de Cachivache Media)
Sigue a Canal USB en Facebook y Twitter
Cachivache Media es una revista digital para los millennials cubanos que disfruten del triángulo amoroso cultura-tecnología-sociedad. Como se anunció en la presentación de Canal USB, trabajos o coproducciones con Cachivache aparecerán en estas páginas.