El conjunto de documentos para este producto aspira al uso de un lenguaje no discriminatorio. A los fines de esta documentación, "no discriminatorio" se refiere al lenguaje que no implica discriminación por motivos de edad, discapacidad, género, identidad de raza, identidad étnica, orientación sexual, nivel socioeconómico e interseccionalidad. Puede haber excepciones en la documentación debido al lenguaje que se encuentra ya en las interfaces de usuario del software del producto, el lenguaje utilizado en función de la documentación de la RFP o el lenguaje utilizado por un producto de terceros al que se hace referencia. Obtenga más información sobre cómo Cisco utiliza el lenguaje inclusivo.
Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).
Este documento describe el flujo de red en la red configurada con proxy, centrada específicamente en Secure Web Appliance (SWA).
Cisco recomienda que tenga conocimiento sobre estos temas:
Las abreviaturas utilizadas en este artículo son:
TCP: protocolo de control de transmisión
UDP: protocolo de datagramas de usuario
IP: protocolo de Internet
GRE: encapsulación de routing genérico
HTTP: protocolo de transferencia de hipertexto.
HTTPS: protocolo de transferencia de hipertexto seguro.
URL: Localizador uniforme de recursos
TLS: Seguridad de la capa de transporte
Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.
La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.
Un intercambio de señales TLS en HTTPS se produce cuando un cliente y un servidor se comunican a través de Internet, proporcionando una conexión segura. El proceso mantiene la privacidad y la integridad de los datos entre dos aplicaciones que se comunican. Funciona mediante una serie de pasos en los que el cliente y el servidor acuerdan los estándares y códigos de encriptación para todas las transmisiones posteriores. El protocolo de enlace tiene por objeto impedir el acceso no autorizado o la manipulación por parte de terceros. También autentica las identidades de las partes que se comunican para eliminar la suplantación. Este proceso es crucial en HTTPS, ya que garantiza que los datos permanezcan seguros durante el tránsito.
Estos son los pasos de un intercambio de señales TLS:
Saludo del cliente: el cliente inicia el proceso de intercambio de señales con un mensaje de saludo. Este mensaje contiene la versión de TLS del cliente, los conjuntos de cifrado admitidos y una cadena de bytes aleatoria conocida como "cliente aleatorio".
Saludo del servidor: el servidor responde con un mensaje de saludo. Este mensaje incluye la versión de TLS elegida por el servidor, el conjunto de cifrado seleccionado, una cadena de bytes aleatoria conocida como "servidor aleatorio" y el certificado digital del servidor. Si es necesario, el servidor también solicita el certificado digital del cliente para la autenticación mutua.
El cliente comprueba el certificado de servidor: el cliente comprueba el certificado digital de servidor con la autoridad de certificados que lo emitió. Esto garantiza al cliente que se está comunicando con el servidor legítimo.
Pre-master Secret: El cliente envía una cadena de bytes aleatoria, conocida como "pre-master secret", que contribuye a la creación de las claves de sesión. El cliente cifra este secreto anterior al maestro con la clave pública del servidor, de modo que sólo el servidor puede descifrarlo con su clave privada.
Secreto principal: tanto el cliente como el servidor utilizan el secreto anterior al maestro y las cadenas de bytes aleatorias de los mensajes hello para calcular independientemente el mismo "secreto principal". Este secreto compartido es la base para generar las claves de sesión.
Cliente finalizado: el cliente envía un mensaje "Finalizado", cifrado con la clave de sesión, para indicar que el cliente ha completado la parte del protocolo de enlace.
Servidor finalizado: el servidor envía un mensaje de "Finalizado", también cifrado con la clave de sesión, para indicar que el servidor ha completado la parte del protocolo de enlace.
Code | Detalles |
100 Continuar |
Normalmente se observa en relación con el protocolo ICAP. Se trata de una respuesta informativa que permite al cliente saber que puede continuar enviando datos. En lo que respecta a los servicios ICAP (como el análisis de virus), el servidor sólo puede desear ver la primera x cantidad de bytes. Cuando se termina de escanear el primer conjunto de bytes y no se detectó un virus, envía un 100 Continue para que el cliente sepa que debe enviar el resto del objeto. |
Code | Detalles |
200 OK |
El código de respuesta más común. Esto significa que la solicitud es exitosa sin ningún problema. |
Code | Detalles |
301 Redirección permanente |
Esta es una redirección permanente, puede ver este código cuando redirige al subdominio www. |
302 Redirección temporal |
Esta es una redirección temporal. Se indica al cliente que realice una nueva solicitud para el objeto especificado en el encabezado Location:. |
304 No modificado |
Esto es en respuesta a un GIMS (GET If-modified-since). Esto es literalmente un HTTP GET estándar que incluye el encabezado If-modified-since: <date>. Este encabezado indica al servidor que el cliente tiene una copia del objeto solicitado en su caché local y que se incluye la fecha en la que se obtuvo el objeto. Si el objeto se ha modificado desde esa fecha, el servidor responde con una copia 200 OK y una copia nueva del objeto. Si el objeto no ha cambiado desde la fecha de obtención, el servidor devuelve una respuesta 304 No modificado. |
Redirección de autenticación 307 |
Esto se observa principalmente en la implementación de proxy transparente, cuando el servidor proxy está configurado para autenticar la solicitud y redirige la solicitud a otra URL para autenticar al usuario, |
Code | Detalles |
400 Solicitud incorrecta |
Esto sugiere un problema con la solicitud HTTP, ya que no cumple con la sintaxis correcta. Entre los posibles motivos se incluyen varios encabezados en una sola línea, espacios dentro de un encabezado o la falta de HTTP/1.1 en el URI, entre otros. Para obtener la sintaxis correcta, consulte RFC 2616. |
401 No autorizado Se requiere autenticación de servidor web |
El acceso al objeto solicitado requiere autenticación. El código 401 se utiliza para la autenticación con un servidor web de destino. Cuando el SWA funciona en modo transparente y la autenticación está habilitada en el proxy, devuelve un 401 al cliente, ya que el dispositivo se presenta como si fuera el OCS (servidor de contenido de origen). Los métodos de autenticación que se pueden utilizar se detallan en un encabezado de respuesta HTTP 'www-authenticate:'. Esto informa al cliente si el servidor está solicitando NTLM, basic u otras formas de autenticación. |
403 denegado |
El cliente no puede acceder al objeto solicitado. Una serie de razones podrían llevar a un servidor a denegar el acceso a objetos. El servidor normalmente proporciona una descripción de la causa dentro de los datos HTTP o la respuesta HTML. |
404 No encontrado |
El objeto solicitado no existe en el servidor. |
407 Autenticación de proxy necesaria |
Esto es lo mismo que un 401, excepto que es específicamente para la autenticación a un proxy y no al OCS. Esto se envía sólo si la solicitud se envió explícitamente al proxy. No se puede enviar un 407 a un cliente mientras SWA esté configurado como proxy transparente, ya que el cliente no sabe que el proxy existe. Si este es el caso, el cliente probablemente FIN o RST usará el socket TCP. |
Code | Detalles |
501 Error interno del servidor |
Error del servidor Web genérico. |
502 Puerta de enlace incorrecta |
Se produce cuando un servidor que actúa como puerta de enlace o proxy recibe una respuesta no válida de un servidor entrante. Indica que la puerta de enlace ha recibido una respuesta inadecuada del servidor de origen o ascendente. |
503 Servicio no disponible |
Indica que el servidor no puede procesar la solicitud debido a una sobrecarga temporal o a un mantenimiento programado. Esto implica que el servidor está temporalmente fuera de servicio, pero puede estar disponible de nuevo después de un tiempo. |
504 Tiempo de espera del gateway |
Indica que un cliente o proxy no recibió una respuesta oportuna del servidor Web al que intentó acceder para cargar la página Web o atender otra solicitud del explorador. Esto a menudo implica que el servidor ascendente está inactivo. |
Aquí ....
El tráfico de red transpira entre la dirección IP del cliente y la dirección IP de la interfaz de proxy SWA (normalmente es la interfaz P1, pero puede ser la interfaz P2 o la interfaz de administración, según la configuración del proxy).
El tráfico del cliente está destinado al puerto TCP 80 o 3128 al SWA (los puertos proxy SWA predeterminados son TCP 80 y 3128; en este ejemplo, utilizamos el puerto 3128)
El tráfico de red se produce entre la dirección IP del proxy y la dirección IP del servidor Web.
El tráfico de SWA se dirige al puerto TCP 80 y se origina con un puerto aleatorio (no el puerto de proxy)
Este es un ejemplo de HTTP Get from Client
Esto representa el flujo completo de tráfico desde el cliente al SWA, luego al servidor web y, finalmente, de vuelta al cliente.
Nota: Cada flujo de tráfico se distingue por un color diferente; el flujo del cliente al SWA es de un color y el flujo del SWA al servidor web es de otro.
A continuación se muestra un ejemplo de Registros de accesorios:
1706172876.686 224 10.61.70.23 TCP_MISS/200 1721 GET http://www.example.com/ - DIRECT/www.example.com text/html DEFAULT_CASE_12-DefaultGroup-DefaultGroup-NONE-NONE-NONE-DefaultGroup-NONE <"IW_ref",3.7,1,"-",0,0,0,1,"-",-,-,-,"-",1,-,"-","-",-,-,"IW_ref",-,"Unknown","Reference","-","Unknown","Unknown","-","-",61.46,0,-,"Unknown","-",1,"-",-,-,"-","-",-,-,"-",-,-> - - [ Request Details: ID = 10, User Agent = "curl/8.4.0", AD Group Memberships = ( NONE ) - ] [ Tx Wait Times (in ms): 1st byte to server = 108, Request Header = 0, Request to Server = 0, 1st byte to client = 3, Response Header = 0, Client Body = 0 ] [ Rx Wait Times (in ms): 1st request byte = 0, Request Header = 0, Client Body = 0, 1st response byte = 106, Response header = 0, Server response = 1, Disk Cache = 0; Auth response = 0, Auth total = 0; DNS response = 0, DNS total = 2, WBRS response = 0, WBRS total = 0, AVC response = 0, AVC total = 0, DCA response = 0, DCA total = 0, McAfee response = 0, McAfee total = 0, Sophos response = 0, Sophos total = 0, Webroot response = 0, Webroot total = 0, Anti-Spyware response = 0, Anti-Spyware total = 1, AMP response = 0, AMP total = 0; Latency = 4; "25/Jan/2024:09:54:36 +0100" ][Client Port = 65238, Server IP = 10.184.216.34, Server Port = 80]
Esto representa el flujo completo de tráfico del cliente al SWA, cuando los datos están en la caché SWA.
Nota: Como puede ver, el servidor Web devuelve la respuesta HTTP 304: Cache not Modified (Caché no modificada). (en este ejemplo, Paquete número 1947)
A continuación se muestra un ejemplo de la respuesta HTTP 304
A continuación se muestra un ejemplo de Registros de accesorios:
1706173001.489 235 10.61.70.23 TCP_REFRESH_HIT/200 1721 GET http://www.example.com/ - DIRECT/www.example.com text/html DEFAULT_CASE_12-DefaultGroup-DefaultGroup-NONE-NONE-NONE-DefaultGroup-NONE <"IW_ref",3.7,1,"-",0,0,0,1,"-",-,-,-,"-",1,-,"-","-",-,-,"IW_ref",-,"Unknown","Reference","-","Unknown","Unknown","-","-",58.59,0,-,"Unknown","-",1,"-",-,-,"-","-",-,-,"-",-,-> - - [ Request Details: ID = 150, User Agent = "curl/8.4.0", AD Group Memberships = ( NONE ) - ] [ Tx Wait Times (in ms): 1st byte to server = 110, Request Header = 0, Request to Server = 0, 1st byte to client = 2, Response Header = 0, Client Body = 0 ] [ Rx Wait Times (in ms): 1st request byte = 0, Request Header = 0, Client Body = 0, 1st response byte = 119, Response header = 0, Server response = 0, Disk Cache = 0; Auth response = 0, Auth total = 0; DNS response = 0, DNS total = 0, WBRS response = 0, WBRS total = 0, AVC response = 0, AVC total = 0, DCA response = 0, DCA total = 0, McAfee response = 0, McAfee total = 0, Sophos response = 0, Sophos total = 0, Webroot response = 0, Webroot total = 0, Anti-Spyware response = 0, Anti-Spyware total = 1, AMP response = 0, AMP total = 0; Latency = 1; "25/Jan/2024:09:56:41 +0100" ][Client Port = 55709, Server IP = 10.184.216.34, Server Port = 80]
El tráfico de red transpira entre la dirección IP del cliente y la dirección IP de la interfaz de proxy SWA (normalmente es la interfaz P1, pero puede ser la interfaz P2 o la interfaz de administración, según la configuración del proxy).
El tráfico del cliente está destinado al puerto TCP 80 o 3128 al SWA (los puertos proxy SWA predeterminados son TCP 80 y 3128; en este ejemplo, utilizamos el puerto 3128)
A continuación se detallan los saludos del cliente desde el cliente al SWA, como puede ver en la Indicación de nombre de servidor (SNI), se puede ver la URL del servidor web que en este ejemplo es www.example.com y el cliente anunció 17 paquetes Cipher:
Consejo: Puede utilizar este filtro en Wireshark para buscar URL/SNI: tls.handshake.extensions_server_name == "www.example.com"
Este es un ejemplo de certificado que SWA envió al cliente
El tráfico de red se produce entre la dirección IP del proxy y la dirección IP del servidor Web.
El tráfico de SWA está destinado al puerto TCP 443 (no al puerto de proxy)
Aquí están los detalles de Cliente Hello de SWA a servidor web, como se puede ver SWA anunciado 12 Cipher Suites:
Nota: Las series Cipher observadas aquí difieren de las series Cipher en el saludo del cliente del cliente al SWA, ya que el SWA, configurado para descifrar este tráfico, utiliza sus propios cifrados.
Sugerencia: en el intercambio de claves de servidor de SWA a servidor web, aparece el certificado de servidor web. Sin embargo, si un proxy upstream encuentra la configuración para su SWA, su certificado aparece en lugar del certificado del servidor web.
Este es un ejemplo de HTTP CONNECT desde el cliente
Esto representa el flujo completo de tráfico desde el cliente al SWA, luego al servidor web y, finalmente, de vuelta al cliente.
Nota: Cada flujo de tráfico se distingue por un color diferente; el flujo del cliente al SWA es de un color y el flujo del SWA al servidor web es de otro.
A continuación se muestra un ejemplo de Registros de accesorios:
1706174571.215 582 10.61.70.23 TCP_MISS_SSL/200 39 CONNECT tunnel://www.example.com:443/ - DIRECT/www.example.com - DECRYPT_WEBCAT_7-DefaultGroup-DefaultGroup-NONE-NONE-NONE-DefaultGroup-NONE <"IW_ref",3.7,-,"-",-,-,-,-,"-",-,-,-,"-",-,-,"-","-",-,-,"IW_ref",-,"-","Reference","-","Unknown","Unknown","-","-",0.54,0,-,"-","-",-,"-",-,-,"-","-",-,-,"-",-,-> - - [ Request Details: ID = 1600, User Agent = "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:122.0) Gecko/20100101 Firefox/122.0", AD Group Memberships = ( NONE ) - ] [ Tx Wait Times (in ms): 1st byte to server = 113, Request Header = 0, Request to Server = 0, 1st byte to client = 113, Response Header = 0, Client Body = 79 ] [ Rx Wait Times (in ms): 1st request byte = 0, Request Header = 0, Client Body = 0, 1st response byte = 0, Response header = 0, Server response = 344, Disk Cache = 0; Auth response = 0, Auth total = 0; DNS response = 0, DNS total = 0, WBRS response = 0, WBRS total = 0, AVC response = 0, AVC total = 0, DCA response = 0, DCA total = 0, McAfee response = 0, McAfee total = 0, Sophos response = 0, Sophos total = 0, Webroot response = 0, Webroot total = 0, Anti-Spyware response = 0, Anti-Spyware total = 0, AMP response = 0, AMP total = 0; Latency = 0; "25/Jan/2024:10:22:51 +0100" ][Client Port = 24953, Server IP = 10.184.216.34, Server Port = 443]
1706174571.486 270 10.61.70.23 TCP_MISS_SSL/200 1106 GET https://www.example.com:443/ - DIRECT/www.example.com text/html DEFAULT_CASE_12-DefaultGroup-DefaultGroup-NONE-NONE-NONE-DefaultGroup-NONE <"IW_ref",3.7,1,"-",0,0,0,1,"-",-,-,-,"-",1,-,"-","-",-,-,"IW_ref",-,"Unknown","Reference","-","Unknown","Unknown","-","-",32.77,0,-,"Unknown","-",1,"-",-,-,"-","-",-,-,"-",-,-> - - [ Request Details: ID = 1630, User Agent = "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:122.0) Gecko/20100101 Firefox/122.0", AD Group Memberships = ( NONE ) - ] [ Tx Wait Times (in ms): 1st byte to server = 0, Request Header = 0, Request to Server = 0, 1st byte to client = 3, Response Header = 0, Client Body = 0 ] [ Rx Wait Times (in ms): 1st request byte = 0, Request Header = 0, Client Body = 0, 1st response byte = 264, Response header = 0, Server response = 2, Disk Cache = 0; Auth response = 0, Auth total = 0; DNS response = 0, DNS total = 0, WBRS response = 0, WBRS total = 1, AVC response = 0, AVC total = 0, DCA response = 0, DCA total = 0, McAfee response = 0, McAfee total = 0, Sophos response = 0, Sophos total = 0, Webroot response = 0, Webroot total = 0, Anti-Spyware response = 0, Anti-Spyware total = 1, AMP response = 0, AMP total = 0; Latency = 2; "25/Jan/2024:10:22:51 +0100" ][Client Port = 24953, Server IP = 10.184.216.34, Server Port = 443]
Nota: Como puede ver en la implementación transparente para el tráfico HTTPS hay 2 líneas en los registros de acceso, la primera línea es cuando el tráfico está cifrado y puede ver CONNECT y la URL del servidor web comienza con tunnel://. Si el descifrado está habilitado en SWA, la segunda línea contiene GET y toda la URL comienza con HTTPS, lo que significa que el tráfico se ha descifrado.
Si configuró su SWA para pasar a través del tráfico, aquí está el flujo general:
Este es el ejemplo de saludo del cliente desde SWA al servidor web:
Lo que es lo mismo que el saludo del cliente del cliente al SWA:
A continuación se muestra un ejemplo de AccessLog:
1706185288.920 53395 10.61.70.23 TCP_MISS/200 6549 CONNECT tunnel://www.example.com:443/ - DIRECT/www.example.com - PASSTHRU_WEBCAT_7-DefaultGroup-DefaultGroup-NONE-NONE-NONE-DefaultGroup-NONE <"IW_ref",3.7,-,"-",-,-,-,-,"-",-,-,-,"-",-,-,"-","-",-,-,"IW_ref",-,"-","Reference","-","Unknown","Unknown","-","-",0.98,0,-,"-","-",-,"-",-,-,"-","-",-,-,"-",-,-> - - [ Request Details: ID = 210, User Agent = "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:122.0) Gecko/20100101 Firefox/122.0", AD Group Memberships = ( NONE ) - ] [ Tx Wait Times (in ms): 1st byte to server = 233, Request Header = 0, Request to Server = 0, 1st byte to client = 119, Response Header = 0, Client Body = 0 ] [ Rx Wait Times (in ms): 1st request byte = 0, Request Header = 0, Client Body = 0, 1st response byte = 0, Response header = 0, Server response = 436, Disk Cache = 0; Auth response = 0, Auth total = 0; DNS response = 0, DNS total = 22, WBRS response = 0, WBRS total = 0, AVC response = 0, AVC total = 0, DCA response = 0, DCA total = 0, McAfee response = 0, McAfee total = 0, Sophos response = 0, Sophos total = 0, Webroot response = 0, Webroot total = 0, Anti-Spyware response = 0, Anti-Spyware total = 0, AMP response = 0, AMP total = 0; Latency = 22; "25/Jan/2024:13:21:28 +0100" ][Client Port = 59939, Server IP = 10.184.216.34, Server Port = 443]
El tráfico de red transpira entre la dirección IP del cliente y la dirección IP del servidor web.
El tráfico del cliente está destinado al puerto TCP 80 (no al puerto Proxy)
Este es un ejemplo de HTTP Get from Client
El tráfico de red se produce entre la dirección IP del proxy y la dirección IP del servidor Web.
El tráfico de SWA está destinado al puerto TCP 80 (no al puerto de proxy)
Este es un ejemplo de HTTP Get from Proxy
Esto representa el flujo completo de tráfico desde el cliente al SWA, luego al servidor web y, finalmente, de vuelta al cliente.
Nota: Cada flujo de tráfico se distingue por un color diferente; el flujo del cliente al SWA es de un color y el flujo del SWA al servidor web es de otro.
A continuación se muestra un ejemplo de Registros de accesorios:
1702318427.181 124 192.168.1.10 TCP_MISS/200 1787 GET http://www.example.com/ - DIRECT/www.example.com text/html DEFAULT_CASE_12-DefaultGroup-DefaultGroup-NONE-NONE-NONE-DefaultGroup-NONE <"-",-,-,"-",-,-,-,-,"-",-,-,-,"-",-,-,"-","-",-,-,"-",-,"-","-","-","-","-","-","-",115.29,0,-,"-","-",-,"-",-,-,"-","-",-,-,"-",-,-> - - [ Request Details: ID = 50, User Agent = "curl/8.4.0", AD Group Memberships = ( NONE ) - ] [ Tx Wait Times (in ms): 1st byte to server = 0, Request Header = 0, Request to Server = 0, 1st byte to client = 0, Response Header = 0, Client Body = 0 ] [ Rx Wait Times (in ms): 1st request byte = 1, Request Header = 0, Client Body = 0, 1st response byte = 124, Response header = 0, Server response = 0, Disk Cache = 0; Auth response = 0, Auth total = 0; DNS response = 0, DNS total = 0, WBRS response = 0, WBRS total = 0, AVC response = 0, AVC total = 0, DCA response = 0, DCA total = 0, McAfee response = 0, McAfee total = 0, Sophos response = 0, Sophos total = 0, Webroot response = 0, Webroot total = 0, Anti-Spyware response = 0, Anti-Spyware total = 0, AMP response = 124>, AMP total = 124<; Latency = 1; "11/Dec/2023:19:13:47 +0100" ][Client Port = 54468, Server IP = 10.184.216.34, Server Port = 80]
Esto representa el flujo completo de tráfico del cliente al SWA, cuando los datos están en la caché SWA.
Nota: Como puede ver, el servidor Web devuelve la respuesta HTTP 304: Cache not Modified (Caché no modificada). (en este ejemplo, Paquete número 27)
A continuación se muestra un ejemplo de la respuesta HTTP 304
A continuación se muestra un ejemplo de Registros de accesorios:
1702318789.560 105 192.168.1.10 TCP_REFRESH_HIT/200 1787 GET http://www.example.com/ - DIRECT/www.example.com text/html DEFAULT_CASE_12-DefaultGroup-DefaultGroup-NONE-NONE-NONE-DefaultGroup-NONE <"-",-,-,"-",-,-,-,-,"-",-,-,-,"-",-,-,"-","-",-,-,"-",-,"-","-","-","-","-","-","-",136.15,0,-,"-","-",-,"-",-,-,"-","-",-,-,"-",-,-> - - [ Request Details: ID = 360, User Agent = "curl/8.4.0", AD Group Memberships = ( NONE ) - ] [ Tx Wait Times (in ms): 1st byte to server = 0, Request Header = 0, Request to Server = 0, 1st byte to client = 0, Response Header = 0, Client Body = 0 ] [ Rx Wait Times (in ms): 1st request byte = 2, Request Header = 0, Client Body = 0, 1st response byte = 104, Response header = 0, Server response = 0, Disk Cache = 0; Auth response = 0, Auth total = 0; DNS response = 0, DNS total = 0, WBRS response = 0, WBRS total = 0, AVC response = 0, AVC total = 0, DCA response = 0, DCA total = 0, McAfee response = 0, McAfee total = 0, Sophos response = 0, Sophos total = 0, Webroot response = 0, Webroot total = 0, Anti-Spyware response = 0, Anti-Spyware total = 0, AMP response = 105>, AMP total = 105<; Latency = 2; "11/Dec/2023:19:19:49 +0100" ][Client Port = 54487, Server IP = 10.184.216.34, Server Port = 80]
El tráfico de red transpira entre la dirección IP del cliente y la dirección IP del servidor web.
El tráfico del cliente está destinado al puerto TCP 443 (no al puerto Proxy)
Aquí hay detalles del saludo del cliente del cliente al SWA, como puede ver en la indicación del nombre del servidor (SNI), se puede ver la URL del servidor web que en este ejemplo, es www.example.com .
Consejo: Puede utilizar este filtro en Wireshark para buscar URL/SNI: tls.handshake.extensions_server_name == "www.example.com"
A continuación se muestra un ejemplo de Intercambio de claves de servidor
El tráfico de red se produce entre la dirección IP del proxy y la dirección IP del servidor Web.
El tráfico de SWA está destinado al puerto TCP 443 (no al puerto de proxy)
A continuación se muestra un ejemplo de saludo de cliente de SWA a servidor web
Nota: Las series Cipher observadas aquí difieren de las series Cipher en el saludo del cliente del cliente al SWA, ya que el SWA, configurado para descifrar este tráfico, utiliza sus propios cifrados.
Sugerencia: en el intercambio de claves de servidor de SWA a servidor web, aparece el certificado de servidor web. Sin embargo, si un proxy upstream encuentra la configuración para su SWA, su certificado aparece en lugar del certificado del servidor web.
A continuación se muestra un ejemplo de Registros de accesorios:
1702319784.943 558 192.168.1.10 TCP_MISS_SSL/200 0 TCP_CONNECT 10.184.216.34:443 - DIRECT/www.example.com - DECRYPT_ADMIN_DEFAULT_ACTION_7-DefaultGroup-DefaultGroup-NONE-NONE-NONE-DefaultGroup-NONE <"-",-,-,"-",-,-,-,-,"-",-,-,-,"-",-,-,"-","-",-,-,"-",-,"-","-","-","-","-","-","-",0.00,0,-,"-","-",-,"-",-,-,"-","-",-,-,"-",-,-> - - [ Request Details: ID = 940, User Agent = -, AD Group Memberships = ( NONE ) - ] [ Tx Wait Times (in ms): 1st byte to server = 0, Request Header = 0, Request to Server = 0, 1st byte to client = 0, Response Header = 0, Client Body = 50 ] [ Rx Wait Times (in ms): 1st request byte = 0, Request Header = 45, Client Body = 0, 1st response byte = 0, Response header = 0, Server response = 249, Disk Cache = 0; Auth response = 0, Auth total = 0; DNS response = 0, DNS total = 5, WBRS response = 0, WBRS total = 0, AVC response = 0, AVC total = 0, DCA response = 0, DCA total = 0, McAfee response = 0, McAfee total = 0, Sophos response = 0, Sophos total = 0, Webroot response = 0, Webroot total = 0, Anti-Spyware response = 0, Anti-Spyware total = 0, AMP response = 558>, AMP total = 558<; Latency = 50; "11/Dec/2023:19:36:24 +0100" ][Client Port = 54515, Server IP = 10.184.216.34, Server Port = 443]
1702319785.190 247 192.168.1.10 TCP_MISS_SSL/200 1676 GET https://www.example.com:443/ - DIRECT/www.example.com text/html DEFAULT_CASE_12-DefaultGroup-DefaultGroup-NONE-NONE-NONE-DefaultGroup-NONE <"-",-,-,"-",-,-,-,-,"-",-,-,-,"-",-,-,"-","-",-,-,"-",-,"-","-","-","-","-","-","-",54.28,0,-,"-","-",-,"-",-,-,"-","-",-,-,"-",-,-> - - [ Request Details: ID = 960, User Agent = "curl/8.4.0", AD Group Memberships = ( NONE ) - ] [ Tx Wait Times (in ms): 1st byte to server = 0, Request Header = 0, Request to Server = 0, 1st byte to client = 50, Response Header = 50, Client Body = 0 ] [ Rx Wait Times (in ms): 1st request byte = 0, Request Header = 97, Client Body = 0, 1st response byte = 48, Response header = 0, Server response = 0, Disk Cache = 0; Auth response = 0, Auth total = 0; DNS response = 0, DNS total = 0, WBRS response = 0, WBRS total = 0, AVC response = 0, AVC total = 0, DCA response = 0, DCA total = 0, McAfee response = 0, McAfee total = 0, Sophos response = 0, Sophos total = 0, Webroot response = 0, Webroot total = 0, Anti-Spyware response = 0, Anti-Spyware total = 0, AMP response = 247>, AMP total = 247<; Latency = 97; "11/Dec/2023:19:36:25 +0100" ][Client Port = 54515, Server IP = 10.184.216.34, Server Port = 443]
Nota: Como puede ver en la implementación transparente para el tráfico HTTPS hay 2 líneas en los registros de acceso, la primera línea es cuando el tráfico está cifrado y puede ver TCP_CONNECT y la dirección IP del servidor web. Si el descifrado está habilitado en SWA, la segunda línea contiene GET y toda la URL comienza con HTTPS, lo que significa que el tráfico se ha descifrado y SWA conoce la URL.
Revisión | Fecha de publicación | Comentarios |
---|---|---|
1.0 |
13-May-2024 |
Versión inicial |