Robert Heaton

HTTPS es simplemente tu protocolo HTTP estándar untado con una generosa capa de deliciosa codificación SSL/TLS. A menos que algo vaya terriblemente mal (y puede), impide que personas como la infame Eve vean o modifiquen las peticiones que conforman tu experiencia de navegación; es lo que mantiene tus contraseñas, comunicaciones y datos de tarjetas de crédito a salvo en el cable entre tu ordenador y los servidores a los que quieres enviar estos datos. Aunque el pequeño candado verde y las letras «https» en la barra de direcciones no significan que no haya cuerda suficiente para que tanto usted como el sitio web que está viendo se cuelguen en otro sitio, al menos le ayudan a comunicarse de forma segura mientras lo hace.

¿Qué es HTTPS y qué hace?

HTTPS toma el conocido y entendido protocolo HTTP, y simplemente le pone una capa de encriptación SSL/TLS (en lo sucesivo, simplemente «SSL»). Los servidores y los clientes siguen hablando exactamente el mismo HTTP entre sí, pero a través de una conexión segura SSL que cifra y descifra sus peticiones y respuestas. La capa SSL tiene dos objetivos principales:

• Verificar que estás hablando directamente con el servidor con el que crees que estás hablando
• Asegurar que sólo el servidor puede leer lo que le envías y sólo tú puedes leer lo que te devuelve

La parte realmente, realmente inteligente es que cualquiera puede interceptar cada uno de los mensajes que intercambias con un servidor, incluyendo aquellos en los que estás acordando la clave y la estrategia de encriptación a utilizar, y aún así no ser capaz de leer ninguno de los datos reales que envías.

Cómo se establece una conexión SSL

Una conexión SSL entre un cliente y un servidor se establece mediante un handshake, cuyos objetivos son:

• Confirmar al cliente que está hablando con el servidor correcto (y opcionalmente a la inversa)
• Que las partes hayan acordado un «conjunto de cifrado» que incluye el algoritmo de cifrado que utilizarán para intercambiar datos
• Para que las partes hayan acordado las claves necesarias para este algoritmo

Una vez establecida la conexión, ambas partes pueden utilizar el algoritmo y las claves acordadas para enviarse mensajes de forma segura. Vamos a dividir el handshake en 3 fases principales – Hola, Intercambio de Certificados e Intercambio de Claves.

1. Hola – El handshake comienza con el cliente enviando un mensaje ClientHello. Éste contiene toda la información que el servidor necesita para conectarse con el cliente a través de SSL, incluidos los distintos conjuntos de cifrado y la versión máxima de SSL que admite. El servidor responde con un ServerHello, que contiene información similar requerida por el cliente, incluyendo una decisión basada en las preferencias del cliente sobre el conjunto de cifrado y la versión de SSL que se utilizará.

2. Intercambio de certificados – Ahora que se ha establecido el contacto, el servidor tiene que demostrar su identidad al cliente. Esto se consigue mediante su certificado SSL, que es algo muy parecido a su pasaporte. Un certificado SSL contiene varios datos, como el nombre del propietario, la propiedad (por ejemplo, el dominio) a la que está vinculado, la clave pública del certificado, la firma digital e información sobre las fechas de validez del certificado. El cliente comprueba que confía implícitamente en el certificado, o que está verificado y es de confianza por una de las diversas Autoridades de Certificación (CA) en las que también confía implícitamente. Más información sobre esto en breve. Tenga en cuenta que el servidor también puede requerir un certificado para probar la identidad del cliente, pero esto normalmente sólo ocurre en aplicaciones muy sensibles.

3. Intercambio de claves – El cifrado de los datos de los mensajes reales intercambiados por el cliente y el servidor se hará utilizando un algoritmo simétrico, cuya naturaleza exacta ya se acordó durante la fase de Hola. Un algoritmo simétrico utiliza una única clave tanto para el cifrado como para el descifrado, en contraste con los algoritmos asimétricos que requieren un par de claves públicas/privadas. Ambas partes deben acordar esta clave única y simétrica, un proceso que se lleva a cabo de forma segura utilizando el cifrado asimétrico y las claves públicas/privadas del servidor.

El cliente genera una clave aleatoria que se utilizará para el algoritmo principal y simétrico. La encripta utilizando un algoritmo también acordado durante la fase Hello, y la clave pública del servidor (que se encuentra en su certificado SSL). Envía esta clave encriptada al servidor, donde se descifra utilizando la clave privada del servidor, y las partes interesantes del apretón de manos están completas. Las partes están suficientemente satisfechas de que están hablando con la persona correcta, y han acordado secretamente una clave para cifrar simétricamente los datos que van a enviarse mutuamente. Las peticiones y respuestas HTTP pueden enviarse ahora formando un mensaje en texto plano y luego encriptándolo y enviándolo. La otra parte es la única que sabe cómo descifrar este mensaje, por lo que los atacantes de tipo Man In The Middle no pueden leer o modificar las peticiones que puedan interceptar.

Certificados

En su nivel más básico, un certificado SSL es simplemente un archivo de texto, y cualquiera con un editor de texto puede crear uno. De hecho, se puede crear trivialmente un certificado en el que se afirme que se es Google Inc. y que se controla el dominio gmail.com. Si esto fuera todo, el SSL sería una broma; la verificación de la identidad consistiría esencialmente en que el cliente preguntara al servidor «¿eres Google?», el servidor respondiera «er, sí, totalmente, aquí hay un trozo de papel con «soy Google» escrito en él» y el cliente dijera «vale, genial, aquí están todos mis datos». La magia que evita esta farsa está en la firma digital, que permite a una parte verificar que el trozo de papel de otra parte es realmente legítimo.

Hay 2 razones sensatas por las que podrías confiar en un certificado:

• Si está en una lista de certificados en los que confías implícitamente
• Si es capaz de demostrar que es de confianza del controlador de uno de los certificados de la lista anterior

El primer criterio es fácil de comprobar. Tu navegador tiene una lista preinstalada de certificados SSL de confianza de las autoridades de certificación (CA) que puedes ver, añadir y eliminar. Estos certificados están controlados por un grupo centralizado de organizaciones (en teoría, y generalmente en la práctica) extremadamente seguras, fiables y de confianza como Symantec, Comodo y GoDaddy. Si un servidor presenta un certificado de esa lista, sabes que puedes confiar en él.

El segundo criterio es mucho más difícil. Es fácil para un servidor decir «er sí, mi nombre es er, Microsoft, usted confía en Symantec y er, ellos confían totalmente en mí, así que todo está bien». Un cliente algo inteligente podría entonces ir y preguntarle a Symantec «Tengo un Microsoft aquí que dice que confías en ellos, ¿es esto cierto?» Pero incluso si Symantec dice «sí, los conocemos, Microsoft son de fiar», sigues sin saber si el servidor que dice ser Microsoft es realmente Microsoft o algo mucho peor. Aquí es donde entran en juego las firmas digitales.

3.2 Firmas digitales

Como ya se ha señalado, los certificados SSL tienen un par de claves públicas/privadas asociadas. La clave pública se distribuye como parte del certificado, y la clave privada se guarda de forma increíblemente segura. Este par de claves asimétricas se utiliza en el handshake de SSL para intercambiar otra clave para que ambas partes puedan cifrar y descifrar simétricamente los datos. El cliente utiliza la clave pública del servidor para cifrar la clave simétrica y enviarla de forma segura al servidor, y éste utiliza su clave privada para descifrarla. Cualquiera puede cifrar utilizando la clave pública, pero sólo el servidor puede descifrar utilizando la clave privada.

Lo contrario ocurre con la firma digital. Un certificado puede ser «firmado» por otra autoridad, por lo que la autoridad efectivamente va a decir «hemos verificado que el controlador de este certificado también controla la propiedad (dominio) que aparece en el certificado». En este caso, la autoridad utiliza su clave privada para cifrar (a grandes rasgos) el contenido del certificado, y este texto cifrado se adjunta al certificado como firma digital. Cualquiera puede descifrar esta firma utilizando la clave pública de la autoridad, y verificar que el resultado es el valor descifrado esperado. Pero sólo la autoridad puede cifrar el contenido utilizando la clave privada, por lo que sólo la autoridad puede crear una firma válida en primer lugar.

Por lo tanto, si aparece un servidor que afirma tener un certificado para Microsoft.com que está firmado por Symantec (o alguna otra CA), su navegador no tiene que creer en su palabra. Si es legítimo, Symantec habrá utilizado su clave privada (ultrasecreta) para generar la firma digital del certificado SSL del servidor, por lo que su navegador puede utilizar su clave pública (ultrapública) para comprobar que esta firma es válida. Symantec habrá tomado medidas para asegurarse de que la organización para la que están firmando es realmente propietaria de Microsoft.com, por lo que, dado que su cliente confía en Symantec, puede estar seguro de que realmente está hablando con Microsoft Inc.

3.3 Autofirma

Note que todos los certificados de CA raíz son «autofirmados», lo que significa que la firma digital se genera utilizando la propia clave privada del certificado. No hay nada intrínsecamente especial en el certificado de una CA raíz: puedes generar tu propio certificado autofirmado y usarlo para firmar otros certificados si quieres. Pero como su certificado aleatorio no está precargado como CA en ningún navegador, ninguno de ellos confiará en usted para firmar sus propios certificados o los de otros. En realidad estás diciendo «sí, soy totalmente Microsoft, aquí hay un certificado oficial de identidad emitido y firmado por mí», y todos los navegadores que funcionen correctamente lanzarán un mensaje de error muy aterrador en respuesta a tus dudosas credenciales.

Esto pone una enorme carga en todos los editores de navegadores y sistemas operativos para que confíen sólo en las CA raíz limpias, ya que éstas son las organizaciones en las que sus usuarios acaban confiando para examinar los sitios web y mantener los certificados seguros. No es una tarea fácil.

3.4 ¿En qué confías?

Es interesante notar que tu cliente técnicamente no está tratando de verificar si debe o no confiar en la parte que le envió un certificado, sino si debe confiar en la clave pública contenida en el certificado. Los certificados SSL son completamente abiertos y públicos, por lo que cualquier atacante podría hacerse con el certificado de Microsoft, interceptar la petición de un cliente a Microsoft.com y presentarle el certificado legítimo. El cliente lo aceptaría y comenzaría felizmente el apretón de manos. Sin embargo, cuando el cliente cifre la clave que se utilizará para el cifrado de datos real, lo hará utilizando la clave pública real de Microsoft de este certificado real. Como el atacante no tiene la clave privada de Microsoft para descifrarla, está atrapado. Incluso si el handshake se completa, seguirán sin poder descifrar la clave, y por tanto no podrán descifrar ninguno de los datos que el cliente les envíe. El orden se mantiene mientras el atacante no controle la clave privada de un certificado de confianza. Si el cliente es engañado de alguna manera para que confíe en un certificado y una clave pública cuya clave privada está controlada por un atacante, empiezan los problemas.

4.1 ¿Puede una cafetería monitorizar mi tráfico HTTPS a través de su red?

No. La magia de la criptografía de clave pública significa que un atacante puede observar cada uno de los bytes de datos intercambiados entre su cliente y el servidor y aún así no tener idea de lo que se están diciendo el uno al otro más allá de la cantidad aproximada de datos que están intercambiando. Sin embargo, su tráfico HTTP normal sigue siendo muy vulnerable en una red wi-fi insegura, y un sitio web endeble puede ser víctima de cualquier número de soluciones que de alguna manera lo engañen para enviar el tráfico HTTPS sobre HTTP plano o simplemente al lugar equivocado por completo. Por ejemplo, aunque un formulario de inicio de sesión envíe una combinación de nombre de usuario y contraseña a través de HTTPS, si el propio formulario se carga de forma insegura a través de HTTP, un atacante podría interceptar el HTML del formulario en su camino hacia su máquina y modificarlo para enviar los detalles de inicio de sesión a su propio punto final.

4.2 ¿Puede mi empresa supervisar mi tráfico HTTPS a través de su red?

Si también está utilizando una máquina controlada por su empresa, entonces sí. Recuerde que en la raíz de toda cadena de confianza se encuentra una CA de confianza implícita, y que una lista de estas autoridades se almacena en su navegador. Su empresa podría utilizar su acceso a su máquina para añadir su propio certificado autofirmado a esta lista de CAs. Entonces podrían interceptar todas tus peticiones HTTPS, presentando certificados que dicen representar el sitio web apropiado, firmados por su falsa CA y, por tanto, de confianza incuestionable para tu navegador. Dado que usted cifraría todas sus solicitudes HTTPS utilizando la clave pública de su certificado falso, podrían utilizar la clave privada correspondiente para descifrar e inspeccionar (incluso modificar) su solicitud, y luego enviarla a su destino. Probablemente no lo hagan. Pero podrían.

Por cierto, así es también como se utiliza un proxy para inspeccionar y modificar las peticiones HTTPS, de otro modo inaccesibles, realizadas por una aplicación del iPhone.

4.3 Entonces, ¿qué pasó con Lavabit y el FBI?

Lavabit fue el proveedor de correo electrónico súper seguro de Edward Snowden durante la locura de las filtraciones de la NSA en 2013. Como hemos visto, ninguna cantidad de piratería estándar podría permitir al FBI ver cualquier dato en su camino entre Lavabit y sus clientes. Sin la clave privada del certificado SSL de Lavabit, la agencia estaba jodida. Sin embargo, un juez estadounidense le dijo al fundador de Lavabit, Ladar Levison, que tenía que entregar esta clave, dando al FBI rienda suelta para espiar el tráfico a su antojo. Levison hizo un valiente intento de dilación entregando la clave de 2.560 caracteres en 11 páginas impresas con letra de 4 puntos, pero se le impuso una orden que le obligaba a entregar la clave en un formato útil o a enfrentarse a una multa de 5.000 dólares al día hasta que lo hiciera.

Una vez que cumplió, GoDaddy, la CA de Lavabit, revocó el certificado, habiéndolo considerado (correctamente) comprometido. Esto añadió el certificado de Lavabit a una Lista de Revocación de Certificados (CRL), una lista de certificados desacreditados en los que los clientes ya no deben confiar para proporcionar una conexión segura. Los certificados comprometidos, autofirmados o de otro modo no fiables hacen que los navegadores muestren un gran mensaje de error en rojo y desaconsejen o prohíban directamente otras acciones al usuario. Por desgracia, los navegadores seguirán confiando en un certificado roto hasta que saquen las últimas actualizaciones de la CRL, un proceso que aparentemente es imperfecto en la práctica.

Conclusión

HTTPS no es irrompible, y el protocolo SSL tiene que evolucionar constantemente a medida que se descubren y aplastan nuevos ataques contra él. Pero sigue siendo una forma impresionantemente robusta de transmitir datos secretos sin preocuparse de quién ve sus mensajes. Hay, por supuesto, muchos detalles de implementación que no se mencionan aquí, como el formato y el orden exactos de los mensajes del apretón de manos, los apretones de manos abreviados para recoger las sesiones recientes sin tener que renegociar las claves y los conjuntos de cifrado, y las numerosas opciones de cifrado diferentes disponibles en cada etapa. La clave para recordar es que mientras HTTPS mantiene los datos seguros en el cable a su destino, de ninguna manera te protege (como un usuario o un desarrollador) contra XSS o fugas de bases de datos o cualquiera de las otras cosas-que-van-en-la-noche. Alégrate de que te cubra las espaldas, pero mantente alerta. En las inmortales palabras de Will Smith, «Camina en la sombra, muévete en silencio, protégete contra la violencia extraterrestre».

Si te ha gustado esto, probablemente disfrutarás de mi post explicando los detalles de la vulnerabilidad FREAK de 2015 en SSL.