Caché y huellas de transporte

La preservación del transporte es automática solo dentro de las conexiones HTTPS con la caché activada. Sin un sufijo de caché, Litport deja CONNECT opaco y no termina la conexión TLS del cliente. Con el modo de caché, Litport intenta reproducir la forma de huella admitida en los fallos y las omisiones que van al origen; los datos de entrada no admitidos usan, en su lugar, un único perfil TLS estándar verificado. Un acierto de caché no hace ninguna conexión con el origen.

ModoCliente → hub → origenResultado visible para el origen

Sin sufijo de cachéCONNECT opaco

El TLS del cliente y el HTTP cifrado pasan sin cambiosLitport no termina el TLS. El origen sigue viendo la IP de salida seleccionada y la pila TCP.

Fallo de caché u omisiónConservar o recurrir a la alternativa

Forma compatible cuando se admiteUna entrada insegura o inconsistente permanece en un único perfil TLS estándar verificado; Litport nunca cambia de identidad a mitad de un CONNECT.

Acierto de cachéRespuesta local

Sin solicitud al origenEl destino no observa ninguna huella TLS ni HTTP porque la solicitud se detiene en el hub.

Esta función reduce las diferencias de transporte que introduce la interceptación HTTPS. No suplanta a otro cliente: curl sigue siendo curl, Chrome sigue siendo Chrome y una app móvil conserva los rasgos compatibles que Litport observó realmente en esa app.

Cuándo se ejecuta exactamente#

El sufijo de contraseña existente activa tanto el almacenamiento en caché como la preservación de la forma del transporte:

PASSWORD_cache-images,fonts
PASSWORD_cache-all_cacheduration-30

Litport intenta la preservación cuando se cumplen todas estas condiciones:

1. El cliente usa el endpoint del proxy HTTP de Litport y envía CONNECT para un destino HTTPS.
2. La contraseña contiene un sufijo de caché válido y la autenticación se completa.
3. La caché y la autoridad de certificación del hub están listas, por lo que Litport acepta la interceptación de caché.

Si la contraseña no tiene sufijo de caché, el túnel CONNECT sigue siendo opaco. Litport reenvía los registros TLS del cliente y los bytes HTTP cifrados sin leerlos ni reescribirlos. «Sin cambios» se refiere al transporte de aplicación a través de Litport: el destino sigue viendo la IP de salida del proxy seleccionado y el comportamiento TCP/IP de esa salida, no la identidad de red local del cliente.

Si la interceptación de caché no puede admitirse antes de que empiece CONNECT, Litport mantiene la ruta opaca existente. Los destinos HTTP sin cifrar, la entrada SOCKS5 y HTTP/3/QUIC no entran en esta función.

Qué ocurre en la red#

Un CONNECT con la caché activada tiene dos conexiones TLS independientes:

client ── TLS leg 1 ──> Litport hub ── TLS leg 2 ──> verified HTTPS origin
           Litport CA       cache        public Web PKI

La implementación las procesa en este orden:

1. Observar el ClientHello. Un observador acotado, solo en memoria, reensambla el primer mensaje del handshake TLS a través de los registros TLS mientras pasa la entrada exacta a la pila TLS estándar verificada. Los bytes capturados viven solo dentro de ese CONNECT y nunca se usan como material criptográfico.
2. Completar el handshake del cliente. El cliente verifica el certificado del destino emitido por la CA de caché de Litport. Litport verifica que el SNI de TLS coincida con la autoridad CONNECT autenticada.
3. Analizar HTTP de forma segura. El ALPN negociado selecciona el servidor HTTP/1.1 o HTTP/2 de entrada. Los observadores acotados conservan solo el orden y los ajustes de conexión necesarios para la reproducción.
4. Consultar la caché local. Un acierto se devuelve de inmediato. Para ese acierto no hay socket de origen, ClientHello, solicitud HTTP ni huella del lado del destino.
5. Mantener la ruta seleccionada. Un fallo o una omisión interceptada abre el origen por la misma ruta de Litport, producto, pool, geografía y ruta de contabilización que ya se seleccionaron para la solicitud. La preservación nunca usa una ruta DNS directa propia que esquive el proxy.
6. Crear un TLS nuevo hacia el origen. Litport sanea el perfil observado, crea valores criptográficos nuevos, verifica el nombre de host y la cadena de certificados del origen, y ofrece los protocolos observados que son compatibles. El resultado de ALPN del origen elige HTTP/1.1 o HTTP/2 en esa misma conexión activa.
7. Serializar la solicitud. Litport emite la forma HTTP admitida, transmite los cuerpos de la solicitud y de la respuesta, y aplica las reglas habituales de caché y de contabilización de bytes decodificados.

Ningún ClientHello sin procesar, bloque de encabezados, valor JA3/JA4 ni identificador de perfil por cliente se escribe en el almacenamiento persistente ni en los logs operativos.

Qué se conserva y qué debe ser nuevo#

Capa observadaComportamiento del tramo al origenLímite

TLS ClientHelloForma de cifrados, extensiones, grupos, firmas y ALPNCuando se admite

HTTP/1.1Orden de encabezados, mayúsculas/minúsculas y campos repetidos que se conservanCuando se admite

HTTP/2SETTINGS, ventana, prioridad y orden de pseudoencabezados y camposCuando se admite

Secretos TLSLos valores aleatorios, el ID de sesión y los key shares son nuevos; PSK y binders se eliminan y la oferta de tickets queda vacíaNuevo / omitido

Identidad de la conexiónTCP/IP, tiempos, reutilización, registros exactos e historial de compresiónNo se puede igualar

Forma del ClientHello de TLS#

Para un ClientHello admitido, Litport conserva la estructura observable compatible, como:

• el orden de las versiones de protocolo y de los conjuntos de cifrado;
• el orden de las extensiones y el contenido compatible y seguro de las extensiones;
• el orden de los grupos admitidos, los algoritmos de firma, los formatos de punto y ALPN;
• el orden de los grupos de key share, las opciones de compresión de certificados, las posiciones de GREASE y el relleno compatible.

Cada conexión con el origen recibe un client random, un ID de sesión y un key share nuevos. Litport elimina las identidades y los binders de PSK, conserva solo una oferta vacía de session ticket cuando esa extensión estaba presente, y no reproduce early data, cookies de TLS ni otro material ligado a la conexión. Un marcador de posición ECH de GREASE se regenera de forma segura en la misma posición; un payload ECH real no se reproduce. Las extensiones opacas se rechazan de forma predeterminada; la excepción revisada es el par de extensiones de OpenSSL vacías y sin estado que usan las compilaciones habituales de curl.

Forma de HTTP/1.1#

Litport conserva el orden y las mayúsculas y minúsculas originales de los campos que quedan después del saneamiento del proxy, incluidas las posiciones de los campos repetidos. Las credenciales exclusivas del proxy siempre se eliminan. El enmarcado del mensaje se reconstruye a partir del cuerpo analizado, de modo que Content-Length o Transfer-Encoding sigue siendo válido aun cuando se puedan conservar su posición y sus mayúsculas y minúsculas observadas. Los campos que agrega solo el analizador de HTTP no se confunden con datos del cliente ni se reenvían como parte de la forma, y Litport no agrega un User-Agent predeterminado cuando el cliente no envió ninguno.

Los upgrades, Expect: 100-continue, un enmarcado mal formado o una discrepancia entre el observador y el analizador usan una serialización HTTP estándar determinista. No hacen que Litport cambie el perfil TLS a mitad de un CONNECT.

Forma de HTTP/2#

Litport conserva el orden y los valores iniciales admitidos de SETTINGS, el comportamiento de WINDOW_UPDATE de la conexión, los frames PRIORITY previos a la solicitud, la prioridad de HEADERS por solicitud, el orden de los pseudoencabezados y el orden normal de los campos. Un único campo Cookie sigue siendo un solo campo en lugar de dividirse en los punto y coma, y un User-Agent ausente sigue ausente. Una solicitud sin cuerpo termina en su frame HEADERS inicial en lugar de recibir un frame DATA vacío sintético. Los metadatos de la solicitud se aíslan por stream, de modo que las solicitudes simultáneas no pueden tomar prestada la forma de otro stream.

Los bytes exactos de HPACK y el historial de la tabla dinámica no son una promesa de compatibilidad. Las respuestas, los aciertos de caché, la concurrencia y la reutilización de conexiones pueden hacer que los dos historiales de compresión diverjan aun cuando los mismos campos aparezcan en el mismo orden.

Límites de la implementación#

El estado de preservación pertenece a un único CONNECT autenticado. Nunca se comparte entre clientes, tokens, autoridades de destino ni conexiones posteriores del cliente.

En HTTP/1.1, el observador sigue los cuerpos de longitud fija y los chunked (incluidos los trailers), para que los bytes dentro de un cuerpo no se confundan con la siguiente solicitud en pipeline. Antes de aplicar una secuencia de campos observada, Litport compara el método, el destino de la solicitud y los recuentos canónicos de campos y valores con la solicitud analizada. Los campos de autenticación del proxy se eliminan sin importar su posición observada.

En HTTP/2, Litport combina dos vistas. Un observador a nivel de frame captura los frames iniciales SETTINGS, WINDOW_UPDATE de la conexión y PRIORITY previos a la solicitud. El decodificador de HTTP/2 asocia al contexto en memoria de esa solicitud solo el orden de los pseudoencabezados, el orden de los campos normales y la prioridad de HEADERS del stream actual. El transporte hacia el origen usa entonces esos valores en el stream correspondiente, lo que evita que las solicitudes simultáneas tomen prestados el orden o la prioridad de las demás.

Cuando termina el CONNECT del cliente, Litport cierra tanto el pool del protocolo como cada socket de origen sin procesar que le pertenece. Esto también termina un bucle de lectura de HTTP/2 que todavía está retirando su último stream; no puede seguir vivo ni quedar disponible para un CONNECT posterior.

El socket de origen siempre se abre por la ruta upstream que Litport ya seleccionó. La verificación del nombre de host y de la cadena pública permanece activada. El motor HTTP se elige según el resultado de ALPN del origen en ese mismo socket; Litport no vuelve a conectarse solo para obtener un protocolo preferido. Si un cliente HTTP/2 llega a un origen que solo admite HTTP/1.1, la solicitud usa HTTP/1.1 ordenado.

Por qué es imposible una huella totalmente idéntica#

La interceptación TLS no puede conservar la conexión completa byte por byte. Litport es un servidor TLS para el cliente y un cliente TLS independiente para el destino. Reutilizar los secretos de la primera conexión en la segunda no sería válido ni seguro.

Lo siguiente necesariamente difiere o puede divergir:

Por eso, la garantía honesta es la preservación compatible de la forma de la huella de transporte, no la preservación completa de la huella. Apunta a las características estables que suelen consumir JA3, JA4 y la huella de HTTP/2, y mantiene nuevo todo el material ligado a la conexión.

Reglas de respaldo y de fallo#

La seguridad tiene prioridad sobre el parecido:

• Una captura admitida usa el perfil TLS preservado y saneado para cada conexión con el origen que pertenece a ese CONNECT del cliente.
• Un ClientHello demasiado grande, mal formado o inseguro usa el perfil TLS estándar verificado durante todo ese CONNECT. Litport nunca alterna dos identidades TLS dentro de un mismo túnel del cliente.
• Los metadatos HTTP específicos de una solicitud pueden recurrir a la serialización estándar determinista sin cambiar el perfil TLS elegido para el CONNECT.
• Si un handshake de origen preservado ya envió bytes y falla, Litport devuelve un error de origen. No reintenta con un ClientHello contradictorio ni debilita la verificación de certificados.
• Cada conexión con el origen se restringe a la autoridad CONNECT autenticada y sigue usando la ruta upstream seleccionada.

Los clientes ven los aciertos, fallos y omisiones de caché, además de los bytes gratis y el ahorro, en Estadísticas de tráfico y en la API de tokens. La preservación del transporte no tiene un estado por solicitud visible para el cliente.

Comportamiento según el cliente y el protocolo#

Consulta la configuración del certificado para ver las instrucciones de confianza de cada cliente.

Verifica con un endpoint de huellas#

Para una comprobación externa opcional, haz una solicitud opaca y una solicitud interceptada con la caché activada a través del mismo hub. El endpoint de abajo devuelve observaciones de JA3, JA4, HTTP/2 y TCP:

# Opaque: Litport does not terminate TLS
curl --proxy 'http://hub-us-7.litport.net:PORT' --proxy-user 'USER:PASSWORD' \
  'https://tls.peet.ws/api/all'

# Intercepted bypass: extensionless diagnostic URL is not stored, but transport preservation runs
curl --proxy 'http://hub-us-7.litport.net:PORT' --proxy-user 'USER:PASSWORD_cache-images' \
  --cacert litport-cache-root.crt \
  'https://tls.peet.ws/api/all'

# A second independent JA3/JA4 and HTTP/2 view
curl --proxy 'http://hub-us-7.litport.net:PORT' --proxy-user 'USER:PASSWORD' \
  'https://tls.browserleaks.com/json'

curl --proxy 'http://hub-us-7.litport.net:PORT' --proxy-user 'USER:PASSWORD_cache-images' \
  --cacert litport-cache-root.crt \
  'https://tls.browserleaks.com/json'

Compara tls.ja3_hash, tls.ja4, los campos TLS ordenados y la huella de HTTP/2. No compares client_random, session_id, la IP de origen, la huella TCP ni los tiempos; se espera que cambien. En la respuesta de BrowserLeaks, los campos equivalentes son ja3_hash, ja4 y akamai_hash. Es un servicio de diagnóstico de terceros, por lo que observará la IP de salida del proxy y los metadatos de la solicitud. Úsalo solo cuando esa divulgación sea aceptable.

Más información#

La entrada del blog de Litport Huellas TLS a través de un proxy: JA3 y JA4 explica cómo afectan a las huellas JA3, JA4 y HTTP/2 los túneles opacos, los proxies de interceptación y el modo de caché, con resultados medidos para clientes habituales.

Vuelve a la descripción general de la caché o revisa la elegibilidad y la solución de problemas.