Ir al contenido principal

Será el fin de TCP con la llegada de HTTP/3

La IETF (Internet Engineering Task Force) ha publicado información sobre lo que será el nuevo protocolo de transferencia de hypertexto que tanto usamos a diario, cuando accedemos a sitios web. HTTP/3 ya no usará TCP nunca más. En su lugar se ejecutará sobre el protocolo QUIC.


El protocolo QUIC fue elaborado conceptualmente por Google en 2012 y tiene como objetivo mejorar tanto la seguridad como el rendimiento ofrecido por TCP - Transmission Control Protocol, sobre todo lo segundo.


¿Qué es Quic y sus diferencias con TCP?

 

Quick UDP Internet Connections, es un protocolo de capa de transporte que se basa en el multiplexado de conexiones UDP. De hecho, QUIC utiliza esta combinación:


TCP + TLS + SDPY sobre UDP

Esto lo hace con varias mejoras respecto a la actual implementación de TCP.

La IETF ha estado desde 2016 trabajando a fondo con una versión global del protocolo alumbra
do por Google, y finalmente ha sido este año cuando ha decidido incluirlo en la nueva versión HTTP/3.

 

Sin embargo, la versión QUIC de la IETF ya es diferente de lo que se pensó en el diseño del protocolo original.

El cometido del protocolo QUIC es buscar simplicidad y velocidad mientras se intenta mantener un nivel de seguridad apropiado, gracias al cifrado ofrecido por TLS 1.3.

Lo que se ha hecho es bucar un medio más eficiente en cuanto a establecimiento de conexión y transferencia de datos. Según Google, los handshakes (saludos) de QUIC requieren 0 roundtrips para enviar la carga del mensaje, comparado con el estandar de 1 a 3 roundtrips requeridos con la combinación TLS + TCP.

 

Un roundtrip es, en oposición a lo que tarda en enviarse o recibirse un mensaje entre un origen y un destino, el tiempo o saltos que requieren el circuito completo. Esto es, el mensaje inicial con su consiguiente respuesta.


Ya sabemos que TCP es un protocolo muy antiguo y nunca ha sobresalido por su eficiencia o baja latencia de envío. Dado que cada vez utilizamos anchos de banda mayores, era cuestión de tiempo buscarle un sustituto. No se trata re reinventar la rueda, sino de hacer el protocolo más eficiente.


Solamente el 1,2% de las webs soporta QUIC por el momento, normalmente se trata de sitios web con mucho tráfico. Por supuesto es el caso para casi todos los servicios que ofrece Google.


¿Es seguro QUIC?

 

El primer desarrollo de QUIC contenía su propio cifrado, pero era algo temporal hasta que el protocolo TLS 1.3 estuviera listo para reemplazarlo, algo que se acordó con la IETF. En palabras de sus desarrolladores: "QUIC se basa en un saludo combinado de criptografía y transporte para minimizar la latencia al establecer la conexión".

Por definición, con este protocolo todo estará cifrado de serie. Sin embargo, no está exento de sus propios riesgos teóricos.

 

 

 Integración entre QUIC y TLS

 

Un trabajo de Robert Lychev en 2015 dejó entrever algunas debilidades en el protocolo. Por ejemplo, se puede mermar su rendimiento con ataques como el de Server Config Replay.

Esto afectaría al rendimiento, aunque por fortuna de momento no tenemos constancia de afectaciones a la integridad o la confidencialidad, según los propios test realizados por Google y la IETF.


Fuente: The Internet changes: HTTP/3 will not use TCP anymore

 

Comentarios

Entradas populares de este blog

Vulnerabilidad en Bluetooth -- BIAS

Asegurando Tomcat - Banner Grabbing para psi-probe

Dentro de los puntos que recomienda OWASP en  Asegurando Tomcat , hace relación a la necesidad de no mostrar la versión de Tomcat que se utiliza, para poner un poco más difícil la preparación de un vector de ataque para el ciberdelincuente; este artículo mostrará como configurar las propiedades del Tomcat para que no muestre la versión, pero tiene un componente especial y es el uso de psi-probe , el cual es un fork que usan los sysadmin para la administración y el monitoreo de un servidor tomcat  y que genera problemas en el momento de querer hardenizar un servidor tomcat. Para realizar esto fue necesario configurar un servidor Tomcat  y cuya configuración esta por fuera del alcance de este artículo. Luego fue necesario configurar tomcat para que funcionara con psi-probe (hay diferentes versiones) y que puede seguir las instrucciones en este enlace. Después  de tener configurado el Tomcat y  probe funcionando podemos ver una pantalla como esta:...

Problemas de ASP error 0115

Cuando saca este error  Páginas Active Server error 'ASP 0115' Error inesperado /iscampus/admon/upload/upload_dest.asp Error capturable (C0000005) en un objeto externo. La secuencia de comandos no puede continuar Fue solucionado de la siguiente manera: W2K3 tiene  tiene limitada a 200 K el tamaño de los ficheros que pueden subirse con ASP, y se debe modificar el archivo C:\WINDOWS\system32\inetsrv\metabase.xml elvalor asignado a la entrada spMaxRequestEntityAllowed por el necesario.  Puede ser 10 MB. Para poder modificar el archivo es necesario parar el servicio IIS y configurar en la administracion de IIS en equipo Local click derecho, propiedades  activamos el checkbox que dice "Habilitar la modificación directa de archivos Metabase". Tambien puede ser necesario hacer lo siguiente: What does this error mean: 'error "ASP 0115" Unexpected error - A trappable error occurred in an external object.' It typically means that you are not running the ...