Universidad Politécnica Salesiana. Ingeniería Electrónica, mención Telecomunicaciones.

Redes de Comunicaciones

Nombre: Sebastian Pesantez Romero

MAN IN THE MIDDLE ATTACK IN HTTP/2
INTRODUCCION
La evolución de los servicios web introduce complejidad, que tiene una repercusión en la carga
de la página web. De hecho, a fines de los años noventa, las páginas web solo se hicieron de texto,
pero hoy en día se manejan páginas web que son interactivas, muestran cientos de imágenes y
ejecutan múltiples scripts. Cada golpe de teclado, cada movimiento del mouse se detecta e influye
en la prestación de la página web. Este comportamiento tiene un costo, principalmente porque el
tráfico entre el usuario y el servidor que aloja el sitio web se pone realmente pesado. [1]
El Protocolo de Transferencia de Hipertexto (HTTP) es uno de los protocolos más versátiles
desarrollados. HTTP/1 se diseñó en 1990 para solicitar paginas HTML desde un navegador web
basado en texto. HTTP/1 presenta latencias debido a que la descarga de la página web requiere
varias solicitudes, las cuales no se pueden paralelizar, por lo que se desarrolló la actualización
HTTP/1.1, sin embargo, las respuestas a las solicitudes tienen que esperar hasta ser enviadas, lo
que se conoce como el problema de bloqueo de encabezado [2].
Para superar este problema, Google experimentó un nuevo protocolo llamado SPDY (“Speedy”).
SPDY fue desarrollado con el propósito de mejorar las latencias de las páginas web [3]. Debido
a muchas ventajas, como la reducción de la página web, latencia y seguridad web mejorada [4],
SPDY proporciono un punto de partida para el desarrollo del protocolo HTTP/2. HTTP/2 se
implementó oficialmente a mediados de 2015 con mejoras importantes sobre el protocolo
HTTP/1.1 existente. HTTP/2 se desarrolló con el objetivo de reducir la latencia de navegadores
web y mejorar la velocidad de carga de la página web implementando diversas técnicas como la
compresión de datos en el encabezado HTTP, tecnología de inserción de servidor, canalización
de solicitudes, resolviendo el problema de bloqueo de encabezado de línea HTTP/1.1 y lo más
importante, multiplexación de múltiples solicitudes sobre una sola conexión TCP. [5]
La versión de ciertos protocolos que para fijar la comunicación es necesario de establecimientos
de llaves, como HTTP, presenta problemas en términos de manejo de seguridad y privacidad, lo
que da como resultado un conjunto de amenazas. Por lo tanto, los sistemas criptográficos seguros
han implementado un intercambio de datos adicional o la transmisión de cierta información a
través de algún tipo de canal seguro, para esto se ha desarrollado protocolos de seguridad que se
basan en certificados de autenticidad como Transport Layer Security (TLS). El ataque Man in the
Middle (MITM) es una de las mayores amenazas en el pirateo informático ya que el desarrollo de
cualquier protocolo nuevo abre un área completamente nueva para que los atacantes y los
investigadores de seguridad realicen ataques maliciosos o análisis de seguridad del protocolo.
PLANTEAMIENTO DEL PROBLEMA
HTTP/2 usa autenticación de certificado TLS para cifrar el mensaje entre la comunicación
terminales. Por lo tanto, si el atacante logra la falsificación de certificados TLS, conseguirá que
todos los paquetes sean encriptados usando la llave pública del atacante y podrá descifrados
usando su llave privada que será proporcionada por el falso certificado TLS, de tal forma que el
atacante puede leer o alterar todo el tráfico de datos entre el cliente y el servidor.
JUSTIFICACION DEL PROBLEMA
TLS es un elemento esencial para asegurar prácticamente todos los protocolos de capa de
aplicación, un aspecto crítico para la seguridad de cualquier diálogo. TLS es la autenticación y el
intercambio de llaves con el objetivo de verificar que se está comunicando con el cliente y servidor
correcto, generalmente se realiza por medio de Certificate Authorities (CA) [6]. Un intercambio
 Universidad Politécnica Salesiana. Ingeniería Electrónica, mención Telecomunicaciones.
Redes de Comunicaciones

de certificados inseguro puede conducir a un tercero activo (atacante) que puede no solo escuchar
a escondidas, sino también interceptar e insertar tráfico en la comunicación para alterar el proceso
de configuración para el canal seguro, insertándose efectivamente en el medio de la
comunicación, lo que obstaculiza la confidencialidad y la integridad, por lo que, idealmente, el
intercambio de llaves solo debería ocurrir cuando hay certeza sobre la autenticidad de certificados
involucrados. La confianza en los certificados se logra generalmente utilizando Public Key
Infraestructure (PKI), que dependen de los CA para establecer cadenas de validación de
certificados [7], que se denominan rutas de certificación.
En los últimos años, han surgido una serie de preocupaciones de seguridad con respecto al uso de
PKI. El modelo de CA pública permite que cualquier CA confiable emita un certificado para
cualquier nombre de dominio, esto significa que los ataques exitosos a las CA tienen el potencial
de generar certificaciones válidas que permiten ataques informáticos como MITM. Las
posibilidades del uso malintencionado de CA intermedias para realizar ataques dirigidos a través
de certificaciones no pueden ser descuidados y son extremadamente difíciles de detectar. La
infraestructura PKI actual para TLS es propensa a ataques MITM y nuevos mecanismos para
detección y evitación de esos ataques son necesarios. [8]
El MITM es uno de los ataques más populares en piratería informática. Esto es un ataque donde
el atacante intercepta secretamente la conexión entre dos partes que se comunican y por lo tanto
secretamente retransmite o incluso puede alterar los datos que se transfieren entre las dos partes.
Este ataque es más apropiado en un entorno de Local Area Network (LAN). El ataque MITM solo
se puede lograr efectivamente cuando el atacante puede hacerse pasar por un partido legítimo al
final de puntos de la conexión, infiltrándose entre el cliente y el servidor, por lo que, el cliente
piensa en el atacante como el servidor, y el servidor piensa en el atacante como el cliente, esto
lleva a un MITM exitoso. [5]
CONCLUSION
Por lo tanto, HTTP, aun con su última actualización continua vulnerable contra ataques MITM,
ya que este tipo de ataque puede ser implementado de muchas maneras diferentes, combinando
diferentes técnicas, por lo que, es necesario el desarrollo de una nueva actualización que involucre
medidas de protección que puedan prevenir ataques de esta naturaleza. Principalmente debería
centralizarse en la autenticidad de certificados, de tal manera, que se pueda verificar que se está
comunicando entre el cliente y servidor correcto.
BIBLIOGRAFIA
[1] H. Saxce, I. Oprescu, Y. Chen. Is HTTP/2 Really Faster Than HTTP/1.1?. 18th IEEE Global
Internet Symposium.
[2] R. Corbel, E. Stephan and N. Omnes. HTTP/1.1 pipelining vs HTTP2 in-the-clear:
performance comparison. 2016, 13th International Conference on New Technologies for
Distributed Systems.
[3] M. Belshe and R. Peon. SPDY Protocol, draft-mbleshe-httpbis-spdy-00. Feb 2012.
[4] L. Chinnaga, A. Rodge, C. Pramanik, A. Bhide, J. Bose and S. Kumar. Enchacing the
Scalability of SPDY Clients for Testing with Limited Network Resources. 2015, IEEE INDICON.
[5] P. Patni, K. Iyer, R. Sarode, A. Mali and A. Nimkar. Man in the Middle Attack in HTTP.
2017, Internacional Conference on Intelligent Computing and Control (I2C2).
[6] T. Dierks and E. Rescorla. The transport layer security (TLS) protocol version 1.2. (5246),
2008. Available: http://www.ietf.org/rfc/rfc5246.txt,.
 Universidad Politécnica Salesiana. Ingeniería Electrónica, mención Telecomunicaciones.
Redes de Comunicaciones

[7] D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley and W. Polk. Internet X.509 public
key infrastructure certificate and certificate revocation list (CRL) profile. (5280), 2008. Available:
http://www.ietf.org./rfc/rfc5280.txt,.
[8] E. Hoz, G. Cochrane, J. Moreira, R. Paez, I. Marsa and B. Alarcos. Detecting and Defeating
Advanced Man-In-The-Middle Attacks against TLS. 2014, 6th International Conference on Cyber
Conflict.