En el escenario predeterminado, cuando una solicitud HTTP debe ser reenviada por un proxy inverso a un servidor remoto, no juega ningún papel importante si la solicitud original se realizó mediante el protocolo http:// o https://.
En el ejemplo, supongamos que el servidor de puerta de enlace se configuró para reenviar solicitudes http(s)://my-custom-gateway.com/~~remoteserver1 al servidor interno 192.168.55.77.
Por lo general, el protocolo SSL seguro https:// se descifraría primero en el lado de la puerta de enlace, luego se crearía una segunda conexión TCP y el tráfico se reenviaría "tal como está", también en formato de solicitud http sin procesar descifrada. Esto es bastante efectivo en términos de CPU, ya que no se realiza más reencriptación, pero en otro lado es menos seguro, ya que permite que los filtros de red o cualquier otro programa de terceros detecten el tráfico sin procesar reenviado al subservidor especificado. Para evitar este posible escenario de ataque de intermediario, puede seguir los siguientes pasos.
Las configuraciones que controlan el comportamiento del proxy inverso se encuentran dentro del archivo *\Clients\webserver\balance.bin
Como en el ejemplo anterior
/~~remoteserver1=192.168.55.77:443;
/~~remoteserver1=192.168.55.77:3389 RDPPORT;
La primera línea indica que se debe reenviar el tráfico http(s) al servidor remoto de destino en el puerto especificado, y la segunda línea indica que, cuando se detecte un protocolo RDP con una cookie RDP utilizada /~~remoteserver1, se lo reenvíe al servidor especificado con el puerto RDP especificado, en el ejemplo el valor predeterminado es 3389. Si no se proporcionó esta línea, las solicitudes RDP se reenviarían a la misma dirección que se especificó para el protocolo http(s).
Adaptar la línea como en el ejemplo con la etiqueta "SSL" inicial forzaría el uso del nuevo cifrado SSL.
SSL /~~remoteserver1=192.168.55.77:443;
/~~remoteserver1=192.168.55.77:3389 RDPPORT;
Recuerde que la etiqueta SSL no tiene sentido con "* RDPPORT;" ya que el servidor RDP generalmente rechazaría el túnel SSL inicial.
A excepción de la etiqueta "SSL", hay más configuraciones como SSL_STRICT, SSL_JVM_TM y SSL_JVM_TM_STRICT
SSL /~~remoteserver1=192.168.55.77:443;
Por defecto, permite cualquier certificado, diferente al que se encuentra inicialmente en el servidor de puerta de enlace, o autofirmado, desactualizado, etc. Este escenario, de hecho, no aumenta la seguridad ya que el intermediario podría simular cualquier certificado de destino, pero de todos modos agrega un mayor grado de seguridad.
SSL_STRICT /~~remoteserver1=192.168.55.77:443;
Igual que SSL, pero las claves públicas deben coincidir. Para que funcione la conexión, será necesario copiar el archivo cert.jks desde la puerta de enlace al subservidor de destino (por ejemplo, 192.168.55.77). Esta es la configuración más preferible, ya que ofrece una seguridad elevada en cualquier situación; sin embargo, requiere el mismo archivo cert.jks en el subservidor que en la puerta de enlace. Si se renueva el archivo cert.jks, el servidor dejará de poder crear un túnel SSL seguro.
SSL_JVM_TM /~~remoteserver1=192.168.55.77:443;
Igual que SSL, pero la clave pública/privada debe estar firmada por una autoridad y el dominio del certificado debe coincidir con la solicitud. No se permiten certificados autofirmados, pero el certificado no necesita coincidir con la solicitud original en la puerta de enlace.
SSL_JVM_TM_STRICT /~~remoteserver1=192.168.55.77:443;
Máxima seguridad, la clave pública firmada y el dominio deben coincidir y ser válidos.
