Análisis de la redirección HTTP a HTTPS

Fecha: 23 y 27 de julio del 2020

Escenario

Este escenario es muy simple y analiza algo que es casi natural para todos a la hora de acceder a una página web,

como lo es escribir una URL y que esta se pase en forma automática (si no hay errores de certificado) del protocolo

HTTP a HTTPS. Es solo capa 4 ? puerto 80 por 443 ? deberemos investigar.

1.- Accedemos a una página de pruebas:

2.- Analizamos el handshacking TCP:

Podemos definir dos etapas, la HTTP (paquetes 1 a 7) y la HTTPS (8 en adelante).

El pase de HTTP a HTTPS se define en el paquete 6 con el anuncio del código de estado HTTP 301

(todos los códigos 3xx son de redirección, ver detalle )

3.- Detalle del paquete con el reenvío a HTTPS:

Luego de este aviso, se da el acuse de recibo y se inicia un nuevo saludo de tres vías, ahora con el puerto TCP 443 (HTTPS):

Luego se inicia el intercambio TLS:

4.- Detalle de la conexión HTTP inicial:

C:\>netstat -na

Conexiones activas

Proto Dirección local Dirección remota Estado

TCP 172.16.16.71:30375 200.58.107.27:443 ESTABLISHED

TCP 172.16.16.71:30372 200.58.107.27:80 ESTABLISHED

---omitido---

5.- Cierre de la sesión TCP port 80:

C:\>netstat -na

Conexiones activas

Proto Dirección local Dirección remota Estado

---omitido---

TCP 172.16.16.71:30375 200.58.107.27:443 ESTABLISHED

TCP 172.16.16.71:30372 200.58.107.27:80 TIME_WAIT

---omitido---

Podemos ver en una nueva captura para descartar el entorno original del lab (otro equipo, otro firewall) que

la sesión queda a la espera (TIME_WAIT) antes de cerrarse, ver el tiempo transcurrido para el cierre.

6.- Detalle del cierre de sesión con TCP RST en lugar de intercambios FIN:

Si bien el siguiente dato es de una publicación vieja, tiene similitudes con el tráfico capturado (de un IIS 7.5).

The results in Table 3 illustrate two main points. First, among the four different Web servers tested, three used

the proper FIN handshake to terminate an idle persistent connection, while one (Microsoft IIS) used a TCP RST.

This type of server behaviour is likely responsible for many of the responder RSTs (RSTR) observed in the

campus TCP traffic. This feature of IIS is used to reduce the number of connections that enter the TIME WAIT

state on the server.

Fuente: http://pages.cpsc.ucalgary.ca/~carey/papers/2005/TCP-Resets.pdf

7.- Corolario:

Este es un mecanismo de la capa de aplicación, es el web server es el que le indica al browser que debe iniciar

una conexión TCP al 443 y negociar HTTPS para que pueda establecerse la transferencia de la página de forma

segura y transparente al usuario.

(2020) The essential is invisible to the eyes

Rosario, Argentina