Contents

Introdução

Pré-requisitos

Requisitos

Componentes Utilizados

Tipos diferentes de implantação de proxy

Handshake TLS

Código de Resposta HTTP

1xx : informativo

2xx: êxito

3xx:redirecionamento

Códigos 4xx: erro do cliente

5xx: erro do servidor

Implantação Explícita

Tráfego HTTP em implantação explícita sem autenticação

Cliente e SWA

Servidor Web e SWA

Tráfego Com Dados Armazenados Em Cache

Tráfego HTTPs em implantação explícita sem autenticação

Cliente e SWA

Servidor Web e SWA

Tráfego HTTPS de passagem

Implantação transparente

Tráfego HTTP na implantação transparente sem autenticação

Cliente e SWA

Servidor Web e SWA

Tráfego Com Dados Armazenados Em Cache

Tráfego HTTPs em implantação transparente sem autenticação

Cliente e SWA

Servidor Web e SWA

Informações Relacionadas

Introdução

Este documento descreve o fluxo de rede em uma rede configurada de Proxy, focada especificamente no Secure Web Appliance (SWA).

Pré-requisitos

Requisitos

A Cisco recomenda que você tenha conhecimento destes tópicos:

- Conceitos básicos de TCP/IP.

- Conhecimento básico da configuração do Proxy.

- Conhecimento básico do mecanismo de autenticação usado no ambiente com o Proxy.

As abreviações usadas nestes artigos são:

TCP: Transmission Control Protocol (Protocolo de controle de transmissão)

UDP: Protocolo de datagrama de usuário

IP: Protocolo de Internet

GRE: Encapsulamento de roteamento genérico

HTTP: Protocolo HTTP.

HTTPS: protocolo de transferência de hipertexto seguro.

URL: Uniform Resource Locator

TLS: Segurança da camada de transporte

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Tipos diferentes de implantação de proxy

Handshake TLS

Um handshake TLS em HTTPS ocorre quando um cliente e um servidor se comunicam pela Internet, fornecendo uma conexão segura. O processo mantém a privacidade e a integridade dos dados entre dois aplicativos em comunicação. Ele opera através de uma série de etapas em que o cliente e o servidor concordam com os padrões e códigos de criptografia para todas as transmissões subsequentes. O handshake tem como objetivo impedir qualquer acesso não autorizado ou manipulação por terceiros. Ele também autentica as identidades das partes que se comunicam para eliminar a representação. Esse processo é crucial no HTTPS, pois garante que os dados permaneçam seguros durante o trânsito.

Estas são as etapas de um handshake TLS:

1. Hello do cliente: o cliente inicia o processo de handshake com uma mensagem hello. Essa mensagem contém a versão TLS do cliente, conjuntos de cifras suportados e uma string de bytes aleatórios conhecida como "aleatório do cliente".

2. Alô do servidor: o servidor responde com uma mensagem de saudação. Essa mensagem inclui a versão TLS escolhida pelo servidor, o conjunto de cifras selecionado, uma sequência de bytes aleatória conhecida como "servidor aleatório" e o certificado digital do servidor. Se necessário, o servidor também solicita o certificado digital do cliente para autenticação mútua.

3. O cliente verifica o certificado do servidor: o cliente verifica o certificado digital do servidor com a autoridade de certificação que o emitiu. Isso garante ao cliente que está se comunicando com o servidor legítimo.

4. Segredo Pré-mestre: O cliente envia uma string de bytes aleatória, conhecida como "segredo pré-mestre", que contribui para a criação das chaves de sessão. O cliente criptografa esse segredo pré-mestre com a chave pública do servidor, de modo que somente o servidor pode descriptografá-lo com sua chave privada.

5. Master Secret: o cliente e o servidor usam o segredo pré-mestre e as strings de byte aleatórias das mensagens de saudação para calcular independentemente o mesmo "segredo mestre". Esse segredo compartilhado é a base para a geração das chaves de sessão.

6. Cliente finalizado: O cliente envia uma mensagem "finalizado", criptografada com a chave de sessão, para sinalizar a conclusão da parte do cliente do handshake.

7. Servidor concluído: o servidor envia uma mensagem "Concluído", também criptografada com a chave de sessão, para sinalizar a conclusão da parte do handshake do servidor.

Código de Resposta HTTP

1xx : informativo

Code

Detalhes

100 Continuar

Geralmente visto em relação ao protocolo ICAP. Esta é uma resposta informativa que permite que o cliente saiba que pode continuar a enviar dados. Em relação aos serviços ICAP (como varredura de vírus), o servidor pode querer ver somente a primeira quantidade x de bytes. Quando ele termina de examinar o primeiro conjunto de bytes e não detectou um vírus, ele envia uma mensagem 100 Continue (Continuar) para informar ao cliente que ele deve enviar o restante do objeto.

2xx: Êxito

Code

Detalhes

200 OK

O código de resposta mais comum. Isso significa que a solicitação foi bem-sucedida sem problemas.

3xx: Redirecionamento

Code

Detalhes

301 Redirecionamento Permanente

Este é um redirecionamento Permanente, você pode ver este código quando estiver redirecionando para o subdomínio www.

302 Redirecionamento Temporário

Este é um redirecionamento temporário. O cliente é instruído a fazer uma nova solicitação para o objeto especificado no cabeçalho Location:.

304 Não Modificado

Isto é em resposta a um GIMS (GET If-modified-since). Este é literalmente um HTTP GET padrão que inclui o cabeçalho If-modified-since: <date>. Esse cabeçalho informa ao servidor que o cliente tem uma cópia do objeto solicitado em seu cache local e que a data em que o objeto foi buscado está incluída. Se o objeto tiver sido modificado desde essa data, o servidor responderá com 200 OK e uma cópia nova do objeto. Se o objeto não tiver sido alterado desde a data de busca, o servidor retornará uma resposta 304 Não modificado.

Redirecionamento de Autenticação 307

Isso é visto principalmente, na Implantação de Proxy transparente, quando o servidor Proxy é configurado para autenticar a solicitação e redireciona a solicitação para outra URL para autenticar o usuário,

Códigos 4xx: erro do cliente

Code

Detalhes

400 Solicitação Incorreta

Isso sugere um problema com a solicitação HTTP, pois ela não está em conformidade com a sintaxe apropriada. Possíveis razões podem incluir vários cabeçalhos em uma única linha, espaços dentro de um cabeçalho ou a falta de HTTP/1.1 no URI, entre outros. Para obter a sintaxe correta, consulte RFC 2616.

401 Não autorizado

Autenticação de Servidor Web Necessária

O acesso ao objeto solicitado requer autenticação. O código 401 é utilizado para autenticação com um servidor Web de destino. Quando o SWA opera em modo transparente e a autenticação é habilitada no proxy, ele retorna um 401 para o cliente, já que o dispositivo se apresenta como se fosse o OCS (servidor de conteúdo de origem).

Os métodos de autenticação que podem ser usados estão detalhados em um cabeçalho de resposta HTTP 'www-authenticate:'. Isso informa ao cliente se o servidor está solicitando NTLM, básico ou outras formas de autenticação.

403 Negado

O cliente não pode acessar o objeto solicitado. Várias razões podem levar um servidor a negar acesso a objetos. O servidor normalmente fornece uma descrição da causa dentro dos dados HTTP ou da resposta HTML.

404 Não encontrado

O objeto solicitado não existe no servidor.

407 Autenticação de proxy necessária

Isso é o mesmo que um 401, exceto que ele é especificamente para autenticação em um proxy e não no OCS. Isso é enviado somente se a solicitação tiver sido enviada explicitamente ao proxy.

Um 407 não pode ser enviado a um cliente enquanto o SWA estiver configurado como proxy transparente, pois o cliente não sabe que o proxy existe. Se este for o caso, o cliente provavelmente FIN ou RST o soquete TCP.

5xx: erro do servidor

Code

Detalhes

501 Erro interno do servidor

Falha genérica do servidor Web.

502 Gateway com problema

Ocorre quando um servidor que atua como gateway ou proxy recebe uma resposta inválida de um servidor de entrada. Ele sinaliza que o gateway recebeu uma resposta inadequada do servidor upstream ou de origem.

Serviço 503 Indisponível

Significa que o servidor não pode lidar com a solicitação devido a uma sobrecarga temporária ou manutenção agendada. Isso implica que o servidor está temporariamente fora de serviço, mas pode estar disponível novamente após algum tempo.

504 Tempo limite do gateway

Indica que um cliente ou proxy não recebeu uma resposta em tempo hábil do servidor Web ao tentar acessar para carregar a página da Web ou atender outra solicitação do navegador. Isso geralmente implica que o servidor upstream está inoperante.

Implantação Explícita

Aqui ....

Tráfego HTTP em implantação explícita sem autenticação

Cliente e SWA

O tráfego de rede transpira entre o endereço IP do cliente e o endereço IP da interface proxy SWA (geralmente é a interface P1, mas pode ser a interface P2 ou de gerenciamento, depende da configuração do proxy).

O tráfego do cliente é destinado à porta TCP 80 ou 3128 para o SWA (as portas proxy do SWA padrão são TCP 80 e 3128, neste exemplo, usamos a porta 3128)

- Handshake TCP.

- HTTP Get do cliente (IP de destino = SWA IP , Porta de destino = 3128 )

- Resposta HTTP do proxy ( IP de origem = SWA )

- Transferência de dados

- Encerramento da conexão TCP (Handshake de 4 Vias)

Cliente de imagem para SWA, modo HTTP explícito

Servidor Web e SWA

O tráfego de rede ocorre entre o endereço IP do Proxy e o endereço IP do servidor Web.

O tráfego do SWA é destinado à porta TCP 80 e originado com uma porta aleatória (não a porta de proxy)

- Handshake TCP.

- HTTP Get do Proxy (IP de Destino = Servidor Web , Porta de Destino = 80 )

- Resposta HTTP do servidor Web ( IP de origem = servidor proxy )

- Transferência de dados

- Encerramento da conexão TCP (Handshake de 4 Vias)

Imagem - HTTP-SWA para servidor Web-Explicit-no cache

Aqui está um exemplo de HTTP Get do cliente

Imagem - Cliente para SWA HTTP GET - Explícito

Isso representa todo o fluxo de tráfego do cliente para o SWA, depois para o servidor Web e, finalmente, de volta para o cliente.

Imagem - Todo o tráfego HTTP Explícito - sem cache

Observação: cada fluxo de tráfego é diferenciado por uma cor diferente; o fluxo do cliente para o SWA é de uma cor e o fluxo do SWA para o servidor Web é de outra.

Imagem - Fluxo de Tráfego HTTP Explícito - sem cache

Aqui está um exemplo de registros de acesso:

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]

Tráfego Com Dados Armazenados Em Cache

Isso representa todo o fluxo de tráfego do cliente para o SWA, quando os dados estão no cache SWA.

Imagem - dados em cache explícitos do HTTP

Observação: Como você pode ver, o Servidor Web retorna a resposta HTTP 304: Cache não Modificado. (neste exemplo, o número de pacote 1947)

Imagem - Fluxo HTTP Explícito com cache

Aqui está um exemplo da Resposta HTTP 304

Imagem - Resposta HTTP 304 explícita

Aqui está um exemplo de registros de acesso:

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]

Tráfego HTTPs em implantação explícita sem autenticação

Cliente e SWA

O tráfego de rede transpira entre o endereço IP do cliente e o endereço IP da interface proxy SWA (normalmente é a interface P1, mas pode ser a interface P2 ou de gerenciamento, depende da configuração do proxy).

O tráfego do cliente é destinado à porta TCP 80 ou 3128 para o SWA (as portas proxy do SWA padrão são TCP 80 e 3128, neste exemplo, usamos a porta 3128)

- Handshake TCP.

- HTTP CONNECT do cliente (IP de destino = SWA, Porta de destino = 3128 )

- Resposta HTTP do proxy ( IP de origem = SWA )

- Hello do cliente com SNI do URL (IP de origem = Cliente)

- Hello do servidor ( IP de origem = SWA )

- Server Key Exchange (IP de origem = SWA)

- Intercâmbio de chave do cliente (IP de origem = Cliente)

- Transferência de dados

- Encerramento da conexão TCP (Handshake de 4 Vias)

Imagem - Cliente HTTPS para SWA-Explicit - Sem cache

Aqui estão os detalhes do cliente Hello do cliente para o SWA, como você pode ver na indicação de nome de servidor (SNI) o URL do servidor web pode ser visto, que neste exemplo, é www.example.com e o cliente anunciou 17 conjuntos de cifras:

Imagem - hello do cliente HTTPS - Explícito - Cliente para SWA

Dica: você pode usar esse filtro no Wireshark para procurar URL/SNI : tls.handshake.extensions_server_name == "www.example.com"

Aqui está um exemplo de certificado que SWA enviou ao cliente

Imagem - Certificado HTTPS - Explícito - SWA para cliente

Servidor Web e SWA

O tráfego de rede ocorre entre o endereço IP do Proxy e o endereço IP do servidor Web.

O tráfego do SWA é destinado à porta TCP 443 (não à porta proxy)

- Handshake TCP.

- Hello do cliente (IP de destino = servidor Web , porta de destino = 443 )

- Servidor Hello ( IP de origem = servidor Web )

- Transferência de dados

- Encerramento da conexão TCP (Handshake de 4 Vias)

Imagem - HTTPS - Explícito - SWA para servidor Web

Aqui estão os detalhes do cliente Hello do SWA para o servidor web, como você pode ver SWA anunciado 12 Cipher Suites:

Imagem - Hello do cliente HTTPS - SWA para servidor Web - Sem cache

Observação: os conjuntos de cifras observados aqui diferem dos conjuntos de cifras no Hello do cliente para SWA, pois o SWA, configurado para descriptografar esse tráfego, utiliza suas próprias cifras.

Dica: na troca de chaves do servidor de SWA para o servidor Web, o certificado do servidor Web é exibido. No entanto, se um Proxy de Upstream encontrar configuração para o seu SWA, o certificado será exibido em vez do certificado do Servidor Web.

Aqui está um exemplo de HTTP CONNECT do cliente

Imagem - Conexão HTTP do Cliente

Isso representa todo o fluxo de tráfego do cliente para o SWA, depois para o servidor Web e, finalmente, de volta para o cliente.

Imagem - HTTPS completo explícito - Sem cache

Observação: cada fluxo de tráfego é diferenciado por uma cor diferente; o fluxo do cliente para o SWA é de uma cor e o fluxo do SWA para o servidor Web é de outra.

Imagem - Fluxo HTTPS - Explícito - Sem Cache

Aqui está um exemplo de registros de acesso:

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]

Observação: como você pode ver na implantação transparente para o tráfego HTTPS, há 2 linhas nos registros de acesso, a primeira linha é quando o tráfego é criptografado e você pode ver CONNECT e a URL do servidor Web começa com tunnel://. Se a Descriptografia estiver habilitada no SWA, a segunda linha conterá GET e a URL inteira começará com HTTPS, o que significa que o tráfego foi descriptografado.

Tráfego HTTPS de passagem

Se você configurou seu SWA para passar pelo tráfego, este é o fluxo geral:

Imagem - Passagem HTTPS - Explícita - Fluxo

Aqui está um exemplo de saudação do cliente do SWA para o servidor Web:

Imagem - Passagem HTTPS - Explícito - SWA para Servidor Web - Hello do cliente

Que é o mesmo que o Hello do cliente para o SWA:

Imagem - Passagem HTTPS - Explícita - Cliente para SWA - Hello do cliente

Aqui está um exemplo 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]

Observação: como você pode ver, é apenas uma única linha e a ação é PASSTHRU.

Implantação transparente

Tráfego HTTP na implantação transparente sem autenticação

Cliente e SWA

O tráfego de rede ocorre entre o endereço IP do cliente e o endereço IP do servidor Web.

O tráfego do cliente é destinado à porta TCP 80 (não à porta de proxy)

- Handshake TCP.

- HTTP Get do cliente (IP de destino = servidor Web , Porta de destino = 80 )

- Resposta HTTP do Proxy ( IP de Origem = Servidor Web )

- Transferência de dados

- Encerramento da conexão TCP (Handshake de 4 Vias)

Imagem - Cliente para Proxy - HTTP - Transparente - Sem Autenticação

Aqui está um exemplo de HTTP Get do cliente

Imagem - Cliente para Proxy - HTTP - Transparente - Sem Autenticação - Cliente HTTP Get

Servidor Web e SWA

O tráfego de rede ocorre entre o endereço IP do Proxy e o endereço IP do servidor Web.

O tráfego do SWA é destinado à porta TCP 80 (não à porta proxy)

- Handshake TCP.

- HTTP Get do Proxy (IP de Destino = Servidor Web , Porta de Destino = 80 )

- Resposta HTTP do servidor Web ( IP de origem = servidor proxy )

- Transferência de dados

- Encerramento da conexão TCP (Handshake de 4 Vias)

Imagem - Proxy e Servidor Web - HTTP - Transparente - Sem Autenticação

Aqui está um exemplo de HTTP Get do Proxy

Imagem - Proxy para Servidor Web - HTTP - Transparente - Sem Autenticação - Proxy HTTP Get

Isso representa todo o fluxo de tráfego do cliente para o SWA, depois para o servidor Web e, finalmente, de volta para o cliente.

Imagem - Tráfego total - HTTP - Transparente - Sem autenticação

Observação: cada fluxo de tráfego é diferenciado por uma cor diferente; o fluxo do cliente para o SWA é de uma cor e o fluxo do SWA para o servidor Web é de outra.

Imagem - Fluxo HTTP do WCCP

Aqui está um exemplo de registros de acesso:

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]

Tráfego Com Dados Armazenados Em Cache

Isso representa todo o fluxo de tráfego do cliente para o SWA, quando os dados estão no cache SWA.

Imagem - Em Cache - Tráfego Total - HTTP - Transparente - Sem Autenticação

Observação: Como você pode ver, o Servidor Web retorna a resposta HTTP 304: Cache não Modificado. (neste exemplo, Pacote número 27)

Aqui está um exemplo da Resposta HTTP 304

Imagem - Em Cache - Resposta HTTP 304 - HTTP - Transparente - Sem Autenticação

Aqui está um exemplo de registros de acesso:

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]

Tráfego HTTPs em implantação transparente sem autenticação

Cliente e SWA

O tráfego de rede ocorre entre o endereço IP do cliente e o endereço IP do servidor Web.

O tráfego do cliente é destinado à porta TCP 443 (não à porta proxy)

- Handshake TCP.

- Cliente de handshake TLS Hello - Servidor Hello - Troca de chaves do servidor - Troca de chaves do cliente

- Transferência de dados

- Encerramento da conexão TCP (Handshake de 4 Vias)

Imagem - Cliente para Proxy - HTTPs - Transparente - Sem Autenticação

Aqui estão os detalhes do cliente Hello do cliente para o SWA, como você pode ver na indicação de nome do servidor (SNI), a URL do servidor web pode ser vista, que neste exemplo é www.example.com .

Imagem - Hello do cliente - Cliente para proxy - Transparente - Sem autenticação

Dica: você pode usar esse filtro no Wireshark para procurar URL/SNI : tls.handshake.extensions_server_name == "www.example.com"

Aqui está um exemplo de troca de chave de servidor

Imagem - Troca de chaves do servidor - Cliente para proxy - Transparente - Sem autenticação

Observação: como você pode ver, o certificado é o que foi configurado no SWA como certificado de descriptografia.

Servidor Web e SWA

O tráfego de rede ocorre entre o endereço IP do Proxy e o endereço IP do servidor Web.

O tráfego do SWA é destinado à porta TCP 443 (não à porta proxy)

- Handshake TCP.

- Cliente de handshake TLS Hello - Servidor Hello - Troca de chaves do servidor - Troca de chaves do cliente

- Transferência de dados

- Encerramento da conexão TCP (Handshake de 4 Vias)

Imagem - Proxy para Servidor Web - HTTPs - Transparente - Sem autenticação

Aqui está um exemplo de Hello do cliente do SWA para o servidor Web

Imagem - Hello do cliente - Proxy para servidor Web - Transparente - Sem autenticação

Observação: os conjuntos de cifras observados aqui diferem dos conjuntos de cifras no Hello do cliente para SWA, pois o SWA, configurado para descriptografar esse tráfego, utiliza suas próprias cifras.

Dica: na troca de chaves do servidor de SWA para o servidor Web, o certificado do servidor Web é exibido. No entanto, se um Proxy de Upstream encontrar configuração para o seu SWA, o certificado será exibido em vez do certificado do Servidor Web.

Aqui está um exemplo de registros de acesso:

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]

Observação: como você pode ver na implantação transparente para o tráfego HTTPS, há 2 linhas nos registros de acesso, a primeira linha é quando o tráfego é criptografado e você pode ver TCP_CONNECT e o endereço IP do servidor Web. Se a Descriptografia estiver habilitada no SWA, a segunda linha conterá GET e a URL inteira começará com HTTPS, o que significa que o tráfego foi descriptografado e o SWA conhece a URL.

Informações Relacionadas

- Suporte Técnico e Documentação - Cisco Systems

- Configurar Parâmetro de Desempenho em Logs de Acesso - Cisco