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