O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.
A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.
Este documento descreve o fluxo de rede em uma rede configurada de Proxy, focada especificamente no Secure Web Appliance (SWA).
A Cisco recomenda que você tenha conhecimento destes tópicos:
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
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.
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:
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".
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.
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.
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.
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.
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.
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.
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. |
Code | Detalhes |
200 OK |
O código de resposta mais comum. Isso significa que a solicitação foi bem-sucedida sem problemas. |
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, |
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. |
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. |
Aqui ....
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)
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)
Aqui está um exemplo de HTTP Get 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.
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.
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]
Isso representa todo o fluxo de tráfego do cliente para o SWA, quando os dados estão no cache SWA.
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)
Aqui está um exemplo da Resposta HTTP 304
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]
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)
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:
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
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)
Aqui estão os detalhes do cliente Hello do SWA para o servidor web, como você pode ver SWA anunciado 12 Cipher Suites:
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
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.
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.
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.
Se você configurou seu SWA para passar pelo tráfego, este é o fluxo geral:
Aqui está um exemplo de saudação do cliente do SWA para o servidor Web:
Que é o mesmo que o Hello do cliente para o SWA:
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.
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)
Aqui está um exemplo de HTTP Get do cliente
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)
Aqui está um exemplo de HTTP Get do Proxy
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.
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.
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]
Isso representa todo o fluxo de tráfego do cliente para o SWA, quando os dados estão no cache SWA.
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
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]
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)
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 .
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
Observação: como você pode ver, o certificado é o que foi configurado no SWA como certificado de descriptografia.
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)
Aqui está um exemplo de Hello do cliente do SWA para o servidor Web
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.
Revisão | Data de publicação | Comentários |
---|---|---|
1.0 |
13-May-2024 |
Versão inicial |