¿Alguna vez a pensado en lo ingenuo que es utilizar una conexión Wi-Fi gratuita en cafés o lugares públicos similares? Confía en que el propietario de la tienda no haga nada dudoso y confía en que todas las demás personas que actualmente usan el punto de acceso Wi-Fi son buenas personas.

Estas personas no solo pueden escuchar su tráfico, ya que al transmitir los datos a través de ondas de radio usted esta expuesto a que alteren los datos que usted esta recibiendo. Esto es un cambio inofensivo. ¿Pero que pasaría si quisiera comprobar su cuenta bancaria en una conexión Wi-Fi pública? Piense en que cualquier otra persona puede leer o cambiar sus datos. Definitivamente no queremos eso.

HTTPS es una forma de protegerlo a usted y a sus usuarios de propietarios y visitantes de cafés maliciosos. Como desarrollador web, HTTPS es aún más importante ya que las API de todos los navegadores modernos solo están disponibles si su sitio web está protegido con HTTPS.

Para aprovechar todo el potencial de la web, debe comenzar a utilizar HTTPS, y no solo para su página de inicio de sesión, sino para cada una de las páginas. Saber que una página web utiliza HTTPS le dará tranquilidad a sus usuarios en este tipo de lugares públicos.

Índice

1. Asegurando HTTP
2. TLS
3. TLS: Una introducción a la criptografía
4. TLS: Hashing
5. Firmas de las autoridades de certificación
6. El intercambio TLS
7. Contenidos Mixtos

Asegurando HTTP

En este punto, somos dolorosamente conscientes de que HTTP es muy fácil de leer incluso para los humanos. Por tanto, si alguien se las arregla para escuchar de alguna manera una conexión HTTP abierta, el servidor puede leer todas las solicitudes y respuestas. Con este escenario cualquier persona podría extraer todos los datos que necesita de la transmisión.

¿Pero qué tan fácil es escuchar a escondidas una conexión? Wi-FI hace mucho más fácil la intercepción ya que literalmente esta transmitiendo su conexión a través de ondas de radio. Así que todo lo que alguien tiene que hacer es escuchar la transmisión. Para lograr este cometido, se utiliza un software especializado de escucha como Firesheep.

Cifrar la conexión Wi-Fi lo ayudará a evitar este problema, pero generalmente usted no tiene control sobre la configuración de la conexión Wi-Fi en una cafetería. Por otra parte, los cifrados antiguos se pueden romper fácilmente. Es por eso que una característica de HTTPS es el cifrado. HTTPS hará que su navegador transcriba las solicitudes de manera que solo el servidor al que esta conectado pueda entenderlas. Ni el propietario de la tienda ni el intruso malintencionado en su cafetería de preferencia podrán leer su flujo de datos.

Pero, ¿Qué pasa si crees que estas conectado al servidor correcto y realmente no lo estas? Existe un ataque llamado MITM (man-in-the-middle por sus siglas en inglés), en el que el atacante se interpone entre usted y el servidor al que intenta conectarse. Cuando esto suceda, su navegador realizará una conexión cifrada con el servidor, como si fuera el servidor al que usted desea conectarse, digamos Facebook. No obstante, la conexión se establece con un servidor configurado por el atacante.

En este caso, el atacante descifrará sus datos, leerá toda su información privada, la volverá a cifrar y la enviará al servidor de Facebook y viceversa. Ni Facebook ni usted pueden identificar si hay una persona sentado en el medio al tanto de la transmisión.

Para remediar esto, la otra característica de HTTPS es la autenticación. El servidor tendrá que identificarse de una manera que solo el servidor real podría, y así asegurarse de que se está hablando con el servidor correcto.

TLS

Cuando hablamos de HTTPS, en realidad estamos hablando de dos conceptos diferentes: HTTP y TLS, anteriormente conocido como SSL.

Ya conocemos HTTP y TLS significa Transport Layer Security. TLS no es específico de HTTP, ya que cualquier protocolo puede utilizarlo. Por ejemplo, existe FTPS que es FTP (File Transfer Protocol) con TLS y es una combinación de tecnologías para transmitir archivos de forma segura.

TLS cifra la comunicación de una manera que no puede ser leída por nadie más que los destinatarios previstos. En la práctica es “imposible” romper un cifrado TLS. Para asegurarse de que el cliente esta hablando con el servidor con el que realmente se desea comunicar, TLS utiliza la cadena de confianza

En una cadena de confianza, un servidor se identifica con un certificado que contiene metadatos sobre si mismo y una huella digital de su llave de cifrado. Estos certificados son emitidos por una de las pocas autoridades de certificación. Si ese certificado esta firmado por dicha autoridad, sabe que si la llave que se está utilizando coincide con la huella digital, entonces esta hablando con el servidor correcto.

La lista de autoridades de certificación se puede encontrar en el navegador. Por ejemplo en Chrome, se puede encontrar a través de la siguiente dirección:

chrome://settings/search#Certificates

A estas compañias se les puede comprar los certificados. Los certificados cuestan dinero ya que dichas entidades no solo validan su servidor, sino que también validan su identidad como el propietario de ese servidor.

Dado que no todos los desarrolladores pueden o quieren pagar dinero por un certificado para ofrecer seguridad básica a los usuarios, “Let’s Encrypt” ofrece certificados de forma gratuita. Veamos más de cerca como funcionan los certificados y la seguridad que brindan.

TLS: Una introducción a la criptografía

TLS tiene dos bloques de construcción criptográficos importantes: cifrado y hashing.

Cuando las personas piensan en mensajes cifrados, lo primero que llega a sus cabezas es el cifrado simétrico. En este método el remitente cifra algunos datos y entrega los datos cifrados al receptor. El destinatario necesita la misma clave para descifrar los datos que obtuvo. De lo contrario este mensaje será inaccesible para él.

Existe otra aproximación llamada cifrado asimétrico. Con algunos trucos matemáticos, el navegador puede utilizar algoritmos de cifrado que usan una llave para el cifrado y otra para el descifrado. La mayoría de las llaves de cifrado de mensajes se hacen públicas para que cualquier persona que quiera enviar un mensaje utilice una de estas llaves para cifrar el mensaje.

Para descifrar el mensaje se debe usar una llave privada. De esta forma, solo el destinatario que posee la llave privada podrá leer el mensaje. Nuevamente se hace énfasis en son las matemáticas las que hacen posible este método de cifrado.

Lo que una llave cifra, solo puede ser descifrado por la otra. Es por eso que tiene más sentido hablar de una llave pública que esta disponible para cualquiera y una llave privada que solo está disponible para el propietario y debe almacenarse de forma segura. Es por este contexto que el cifrado asimétrico también se conoce como cifrado de llave pública.

TLS: Hashing

Ya revisamos el tema de cifrado en TLS y ahora es momento de hablar de hashing.

Hashing es el proceso de transformación de datos en una representación corta de los datos originales. El cambio más pequeño en los datos originales tendrá enormes cambios en el hash. Si dos documentos producen el mismo valor hash, es muy probable que sean los mismos documentos.

Hay un par de características que nos interesan con las funciones de hash:

1. Debería ser imposible revertir el proceso de conversión. Es decir, una vez que los datos se han convertido en un hash, no se pueden volver a convertir en los datos originales.
2. Debería ser imposible que dos documentos diferentes porduzcan un valor hash idéntico

Una de las funciones de hashing más comunes es SHA (Secure Hash Algorithm). SHA existe en varios tipos, como SHA-256 o SHA-512. El número indica que tan grande es la salida del hash en bits. No importa qué tan grande sea el documento que se pase, siempre se obtendrá un peso de 256 bits como salida cuando se este usando SHA-256.

Firmas de las autoridades de certificación

Ahora que tenemos un buen conocimiento de TLS hablemos de firmas.

Anteriormente se mencionaron las autoridades de certificación y se señalo que su trabajo es firmar certificados. Pero ¿Qué significa eso y por qué alguien querría un certificado firmado? Cuando decimos que alguien ha firmado un documento se asume que la autoridad de certificación ha revisado y verificado el contenido de ese documento.

El propósito es tener algún tipo de prueba que certifique que el documento fue visto o incluso creado por esa entidad. Al igual que firmar su nombre en un documento es una prueba legal de que vio el documento, un servidor puede hacer lo mismo con una firma digital.

Cuando un servidor firma un documento y lo cifra con una llave privada, lo devuelve como un documento firmado. Dado que solo el titular de la clave puede cifrar documentos, usted sabe que el documento que recibió es exactamente el mismo que envió el servidor.

No obstante, los documentos pueden llegar a ser bastante grandes (e.g imágenes de DVD) y el proceso de cifrado asimétrico llevaría mucho tiempo. Por eso, en lugar de cifrar todo el documento en sí, solo se cifra el hash del documento.

Si desea verificar si la firma es válida, descifre la firma y haga un hash del documento para ver si esos dos valores coinciden. De esta manera, sabemos que el documento que recibimos es exactamente el mismo que envío el servidor. Si se modificó el documento en plena transmisión, el hash no coincidirá con el proporcionado por el servidor. En consecuencia, tendríamos una firma no válida.

El intercambio TLS

Es momento de revisar el proceso que ejecuta el navegador para configurar una conexión cifrada TLS. En esta descripción se van a obviar algunos detalles por simplicidad, pero llegaremos a una versión integral del concepto.

1. El primer paso es hacer que el servidor envíe un certificado. El certificado contiene la llave pública del servidor y cierta información adicional como el dominio para el que se encuentra certificado y la firma de una autoridad de certificación.
2. El cliente verifica si el dominio es correcto y también verifica si la firma de autoridad es válida. Como se menciono anteriormente, todos los navegadores tienen una colección de autoridades de certificación que incluyen sus llaves públicas guardadas localmente. Por tanto, sería trivial verificar si la firma es válida.
3. Ahora el cliente genera una llave aleatoria para utilizar el cifrado simétrico de aquí en adelante. El navegador cifra la llave aleatoria con la llave pública del servidor y la envía. Se utiliza el cifrado simétrico ya que tiene las siguiente ventajas sobre el cifrado asimétrico:

• Es más rapido
• Es más eficiente
• Se adapta mejor a una gran cantidad de datos

4. Por último, y lo más importante el servidor solo podrá continuar comunicándose si esta realmente en posesión de la llave privada y puede descifrar la nueva clave aleatoria. Esto efectivamente válida la identidad de los servidores.

Si todo esto se cumple, se ha establecido con éxito una conexión TLS y el protocolo HTTP puede asumir el control. En este punto, la barra de direcciones URL del navegador mostrará un candado verde que significa que hay un conexión TLS establecida.

Hasta hora solo hemos expuesto dos causas para que una conexión TLS no pueda ser establecida:

1. Que la firma de la autoridad de certificación en el certificado sea inválida
2. Que el servidor no sea capaz de comunicarse después del cifrado simétrico.

En la realidad, existen muchas más posibilidades que impiden que se establezca una conexión TLS. Dichas causas se muestran a continuación:

• Los certificados tienen fecha de expiración. Por tanto, si esta fecha se cumple, no se podrá instaurar la conexión TLS
• Los certificados tienen un campo en donde registra el valor hash del cifrado. De no coincidir, no se podrá seguir con el proceso.
• Los certificados vienen con un conjunto de las funciones de cifrado simétrico que admiten (algunas son muy débiles). En caso de que la función de cifrado no se encuentre en este conjunto, tampoco se lograra construir la conexión.
• A veces el certificado es válido, pero la configuración del servidor no lo es.

Un gran sitio para ver como el navegador se comporta cuando la conexión TLS tiene inconvenientes es https://badssl.com/.

Bad SSL tiene su propio certificado válido. Por otro lado, Bad SSL intencionalmente tiene certificados inválidos y configuraciones inválidas. Así podemos ver los comportamientos del navegador en las diferentes situaciones de fallo.

Contenidos Mixtos

Si nuestro index.html se sirve a través de HTTPS, ¡genial!. Pero ¿Qué pasa con los recursos del sitio?¿También se navegan a través de HTTPS?

Una forma rápida de romper ese hermoso candado verde es hacer que los contenidos de la página se naveguen a través de HTTP normal. Cuando esto sucede, el sitio termina en un estado llamado Contenido Mixto.

El contenido mixto se produce cuando abre un sitio web que se supone se entregará a través HTTPS, pero incluye recursos como imágenes, hojas de estilo o scripts de orígenes no protegidos por TLS.

Un error popular es extraer jQuery de un CDN no habilitado para TLS. Dependiendo del tipo de recursos que se incluyen en un canal no seguro, las consecuencias pueden diferir. Este error le puede costar el candado verde, aunque la página web seguiría funcionando. Dependiendo del recurso la conexión se podría bloquear o incluso merecer el horrible candado rojo de la vergüenza.

El comportamiento para manejar contenidos mixtos cambia entre los diferentes navegadores, por lo que definitivamente debería evitar y revisar si un sitio web busca contenidos mixtos.

De hecho, Google recomienda que navegue por todos sus elementos a través de HTTPS. De esta manera, evitará las marañas de contenido mixto y tanto sus recursos como su página web se transferirán de forma segura.

Recapitulación

La seguridad es un aspecto importante pero algunas veces intimidante del desarrollo web. Si no sabía que era HTTPS antes de esta publicación, debería sentirse mucho más cómodo ahora.

Hoy en día la mayoría de los servicios de alojamiento y CDN tienen soporte para TLS. Del mismo modo, cada vez más y más APIs para navegador están siendo habilitadas solo para sitios web HTTPS. Por tanto siempre se debe usar HTTPS para sus usuarios y su propio bien.

La siguiente publicación de esta serie analizara el nuevo estándar HTTP/2 y lo que eso significa para el futuro del desarrollo web.