Terminación TLS y reenvío de la identidad del cliente

Hay tres formas de manejar TLS en un proxy inverso. Terminar: el proxy descifra y lo que sigue hacia el destino va como el equipo decida. Terminar y volver a cifrar: el proxy descifra, inspecciona o enruta y abre un TLS nuevo hacia el destino. Dejar pasar: el proxy reenvía los bytes cifrados sin leerlos, y por eso no puede enrutar por ruta ni aplicar controles de aplicación.

El candado del navegador solo habla del tramo entre el cliente y el proxy. Qué pasa después depende del segundo tramo, y ese es el que se revisa en la configuración.

No todo tramo sin cifrar es un problema igual. Entre procesos del mismo equipo, por la dirección local, el riesgo es menor; por un segmento compartido con otras áreas, cualquiera que esté en él puede observar o alterar lo que viaja. Hay que mirar el esquema, el tramo y el segmento a la vez.

Consulta la tabla destinos: las columnas esquema y segmento dicen cómo habla el proxy y por dónde.

Cuando el proxy vuelve a cifrar hacia el destino, falta la mitad si no comprueba con quién habla: que el certificado del destino sea válido, de un emisor de confianza y para el nombre correcto. Un TLS sin esa verificación cifra, pero a cualquiera que se haga pasar por el destino le abre la puerta igual.

En destinos, la columna verifica_certificado_del_destino toma valores si, no o no aplica (cuando el tramo no usa TLS).

Detrás del proxy, la aplicación ve la conexión del proxy, no la del cliente. Para saber quién llamó, el proxy añade una cabecera con la dirección original: la más extendida es X-Forwarded-For, y el estándar la recoge como Forwarded (RFC 7239). Cuando hay varios saltos, la cabecera es una lista y cada salto añade la dirección que ve al final.

Eso significa que lo que vino del cliente puede mentir: si el cliente ya manda su propia cabecera, el proxy puede conservarla. En la tabla muestra_de_cabeceras compara lo que se recibió, lo que se envió al destino y lo que la aplicación tomó como origen. La tabla comportamiento dice qué dirección de la lista usa la aplicación.

Una dirección de origen sirve para filtros, límites y registros, y por eso no puede depender de algo que el cliente controla. Las dos piezas del arreglo son simples: la aplicación solo debe creer la cabecera si la conexión viene del proxy, y de la lista debe tomar la dirección que añadió un salto de confianza, no la que escribió quien llamó. Otra opción equivalente es que el proxy descarte la cabecera del cliente y escriba la suya.