Laboratorio: Captura de pacotes HTTP: mudanças entre as edições

De Wiki Cursos IFPR Foz
Ir para navegaçãoIr para pesquisar
Linha 38: Linha 38:
#Quantos bytes de conteúdo são baixados pelo seu navegador?  
#Quantos bytes de conteúdo são baixados pelo seu navegador?  


===A Interação HTTP GET Condicional/Resposta===
==A Interação HTTP GET Condicional/Resposta==


A maioria dos navegadores web tem uma '''memória ''cache''''' que permite armazenar as últimas páginas acessadas. Desta forma o nagegador realiza um '''GET condicional''' quando busca um objeto HTTP a fim de verificar se o objeto em ''cache'' é o mesmo que está sendo provido pelo servidor.
A maioria dos navegadores web tem uma '''memória ''cache''''' que permite armazenar as últimas páginas acessadas. Desta forma o nagegador realiza um '''GET condicional''' quando busca um objeto HTTP a fim de verificar se o objeto em ''cache'' é o mesmo que está sendo provido pelo servidor.
Linha 59: Linha 59:
#Qual o tamanho da primeira e segunda mensagem de retorno do servidor?
#Qual o tamanho da primeira e segunda mensagem de retorno do servidor?


==Baixando Documentos Longos==


Nos exemplos até agora, os documentos baixados foram simples e pequenos arquivos em HTML. Vamos ver o que acontece quando baixamos um arquivo em HTML grande.
;Procdedimentos:
#Inicie o navegador web;
#Limpe o '''''cache''''' do seu navegador;
#Inicie o Wireshark;
#Digite o seguinte URL no navegador http:200.17.101.9/redes/redes2.html;
#Pare a captura de pacotes e selecione o filtro '''http''' para que apenas as mensagens HTTP seja exibidas.
Na janela de listagem de pacotes, você deve ver a sua mensagem HTTP GET, seguida por uma reposta em vários pacotes. Esta resposta em vários pacotes merece uma explicação. Lembre-se da seção 2.2 do livro (veja a figura 2.9) que a mensagem de resposta HTTP consiste de uma linha de status, seguida por zero ou mais linhas de cabeçalhos, seguida por uma linha em branco, seguida pela carga útil (Content-Length). No caso do nossa HTTP GET, a carga útil na resposta é o arquivo HTTP completo. No nosso caso aqui, o arquivo em HTML é bastante longo, e a informação de 11747 bytes é muito grande para caber em um segmento TCP. A resposta HTTP simples é então quebrada em vários pedaços pelo TCP, com cada pedaço sendo contido dentro de um segmento TCP separado. Cada segmento TCP é capturado em um pacote separado pelo Wireshark, clique sobre o 9 "Reassembled TCP Segments" no Wireshark.
Responda às seguintes questões:
#Quantas mensagens HTTP GET foram enviadas pelo seu navegador?
#Quantos segmentos TCP foram necessários para carregar a resposta?
#Qual é o código de status e a frase associada com a resposta à mensagem HTTP GET?
#No segundo GET realizado, quantos segmentos TCP foram necessários para obtenção da resposta do servidor?
#O que explica a diferença entre a primeira e segunda requisições?
===Documentos HTML com Objetos Incluídos===
Agora que vimos como o Wireshark mostra o tráfego capturado para arquivos em HTML grandes, nós podemos observar o que acontece quando o seu browser baixa um arquivo com objetos incluídos, no nosso exemplo, imagens que estão armazenadas em outros servidores. Faça o seguinte:
#inicie o navegador web;
#limpe o cache do seu navegador;
#inicie o Wireshark;
#digite o URL no navegador http://www.sj.ifsc.edu.br/~odilson/RED29004/RED29004_arq3.html seu navegador deve exibir um arquivo pequeno em HTML com duas imagens incluídas. Estas duas imagens estão referenciadas no arquivo em HTML. Isto é, as imagens não estão no arquivo em HTML, ao invés disso, há um URL para cada imagem no arquivo em HTML. Como discutido no livro, seu navegador terá que baixar estas imagens dos locais correspondentes. A imagem da esquerda, '''redesWL_network.jpeg''', está em ibxk.com.br. A imagem da direita, '''as-redes-sociais-como-instrumento-de-manipulacao-da-consciencia-coletiva.html.jpg''', está em lounge.obviousmag.org;
#pare a captura de pacotes, e digite “http” na caixa de texto de especificação de filtro, para que apenas as mensagens HTTP seja exibidas.
Responda às seguintes questões:
#Quantas mensagens HTTP GET foram enviadas pelo seu navegador?
#Para quais endereços na Internet estas mensagens foram enviadas?
#Você consegue dizer se o seu navegador baixou as duas imagens em seqüência, ou se foram baixadas dos dois locais distintos em paralelo? Explique.
===Autenticação HTTP===
Finalmente, vamos tentar visitar um local na web que é protegido por senha e examinar a seqüência de mensagens HTTP trocadas com este local. O URL http://www.sj.ifsc.edu.br/~odilson/RED29004/Seguro/ é protegido por senha. O usuário é “red29004” (sem as aspas), e a senha é “seguro” (novamente, sem as aspas). Então vamos acessar o local protegido por senha. Faça o seguinte:
#inicie o navegador web;
#limpe o cache do seu navegador;
#inicie o Wireshark;
#digite o URL no navegador http://www.sj.ifsc.edu.br/~odilson/RED29004/Seguro/ seu navegador apresentará um ''pop up'' solicitando usuário e senha;
#forneça usuário e senha e o navegador apresentará uma "linda" página já conhecida;
#pare a captura de pacotes, e digite "http" na caixa de texto de especificação de filtro, para que apenas as mensagens HTTP seja exibidas.
Agora vamos examinar a saída do Wireshark. Você pode querer primeiro ler sobre a autenticação HTTP revisando o material fácil de ler (em inglês) [http://frontier.userland.com/stories/storyReader$2159 HTTP Access Authentication Framework]
Responda às seguintes questões:
#Qual é a resposta do servidor (código de status e frase) para a primeiro mensagem HTTP GET do seu navegador?
#Quando o seu navegador envia a mensagem HTTP GET pela segunda vez, qual o novo campo que está incluído na mensagem?
O nome de usuário (red29004) e a senha (seguro) que você digitou foram codificados na cadeia de caracteres (cmVkMjkwMDQ6c2VndXJv) após o cabeçalho “Authorization: Basic” na mensagem HTTP GET (primeira). Parece que o nome e senha estão criptografados, mas na verdade estão simplesmente codificados em um formato denominado Base64. O nome do usuário e a senha não estão criptografados! Para ver isso, vá para https://www.base64decode.org/ e digite o texto cmVkMjkwMDQ6c2VndXJv e pressione DECODE. Voilá! Você traduziu de Base64 para ASCII, e desta forma consegue ver o nome de usuário e a senha! Sabendo que alguém pode baixar o Wireshark e capturar pacotes (não somente os próprios), e alguém pode traduzir de Base64 para ASCII (você acabou de fazê-lo!), deve estar claro para você que o uso de senhas apenas em locais na web não garantem segurança, a não ser que medidas adicionais sejam tomadas. Não tema! Há meios de fazer o acesso WWW ser mais seguro. Contudo, nós claramente precisamos de algo que vá além do ''framework'' básico de autenticação HTTP!
===HTTPS===
Para finalizar, vamos capturar sequências de mensagens HTTPS, somente a título de comparação. Execute os seguintes procedimentos:
#inicie o navegador web;
#limpe o cache do seu navegador;
#inicie o Wireshark;
#digite o URL no navegador https://www.base64decode.org/ seu navegador apresentará um site já apresentado/utilizado;
#pare a captura de pacotes e digite "ssl" na caixa de texto de especificação de filtro, para que apenas as mensagens criptografadas sejam exibidas.
Responda:
#Compare a sequência de troca de mensagens (GET e resposta) entre o HTTP (das seções anteriores) com o ssl, existe alguma similaridade?
#Que tipos de campos são mais presentes nesse tipo de mensagens?
#Você consegue identificar o conteúdo de alguma nas mensagens ssl?





Edição das 20h34min de 23 de abril de 2015

Laboratório: Captura de pacotes HTTP

Para este laboratório será utilizado a ferramenta de captura de pacotes wireshark
Veja no link as instruções para download e instalação do wireshark, bem como as instruções para uso do ferramenta.
O laboratório deve ser realizado em uma máquina virtual, em virtude da necessidade de conta de administrador para instalar os aplicativos e utilizar o wireshark.

Fonte: [1].

Objetivos

O objetivo deste laboratório é estudar o funcionamento da Aplicação Web e explorar o funcionamento do protocolo HTTP, incluindo as mensagens de pedido (GET) e resposta, formatos de mensagens HTTP, baixando arquivos grandes em HTML, baixando arquivos em HTML com objetos incluídos, e autenticação e segurança HTTP.

Pedido e Resposta HTTP

Vamos iniciar a nossa exploração do HTTP baixando um arquivo em HTML pequeno, sem objetos incluídos.

Procedimentos
  1. Inicie o navegador;
  2. Inicie o Wireshark e selelcione o filtro http, de tal forma que apenas as mensagens HTTP capturadas serão exibidas na janela de listagem de pacotes. ;
  3. Inicie a captura de pacotes
  4. Digite o seguinte URL no navegador http:200.17.101.9/redes/redes1.html;
  5. Pare a captura de pacotes.
Análise dos pacotes capturados
  1. Verifique a mensagem GET (enviada pelo seu navegador para o servidor) e a mensagem de resposta do servidor para o seu navegador;
  2. Verifique os detalhes da mensagem GET;
  3. Verifique o encapsulamento dos protocolos, com a mensagem HTTP sendo transportada em um segmento TCP, que é carregado em um datagrama IP, que por sua vez é levado em um quadro Ethernet.
Perguntas
  1. O seu navegador executa HTTP 1.0 ou 1.1?
  2. Qual a versão de HTTP do servidor?
  3. Quais idiomas o seu navegador indica que pode aceitar ao servidor?
  4. Qual o endereço IP do seu computador e do servidor?
  5. Qual o número da porta TCP utilizada no seu computador e pelo servidor?
  6. Qual o endereço MAC do seu computador?
  7. É possível veridficar o MAC do servidor?
  8. Qual o código de status retornado do servidor para o seu navegador?
  9. Quando o arquivo em HTML que você baixou foi modificado no servidor pela última vez?
  10. Quantos bytes de conteúdo são baixados pelo seu navegador?

A Interação HTTP GET Condicional/Resposta

A maioria dos navegadores web tem uma memória cache que permite armazenar as últimas páginas acessadas. Desta forma o nagegador realiza um GET condicional quando busca um objeto HTTP a fim de verificar se o objeto em cache é o mesmo que está sendo provido pelo servidor.

Procedimentos
  1. Inicie o navegador web;
  2. Limpe o cache do seu navegador (Firefox: Editar -> Preferências -> Avançado);
  3. Inicie o Wireshark e selelcione o filtro http, de tal forma que apenas as mensagens HTTP capturadas serão exibidas na janela de listagem de pacotes. ;
  4. Digite o seguinte URL no navegador http:200.17.101.9/redes/redes1.html;
  5. Visualize os pacores capturados;
  6. Pressione o botão “atualizar” no navegador;
  7. Pare a captura de pacotes.
Perguntas
  1. Inspecione o conteúdo da primeira mensagem HTTP GET do seu navegador para o servidor. Você vê uma linha If-Modified-Since?
  2. Inspecione o conteúdo da resposta do servidor. O servidor retornou explicitamente o conteúdo do arquivo? Como você pode dizer isso?
  3. Agora inspecione o conteúdo da segunda mensagem HTTP GET do seu navegador para o servidor. Você vê uma linha If-Modified-Since? Caso a resposta seja afirmativa, qual informação segue o cabeçalho If-Modified-Since?
  4. Qual é o código de status e a frase retornada do servidor na resposta à segunda mensagem HTTP GET? É diferente do código de retorno da primeira mensagem?
  5. O servidor retornou explicitamente o conteúdo do arquivo? Explique.
  6. Qual o tamanho da primeira e segunda mensagem de retorno do servidor?

Baixando Documentos Longos

Nos exemplos até agora, os documentos baixados foram simples e pequenos arquivos em HTML. Vamos ver o que acontece quando baixamos um arquivo em HTML grande.

Procdedimentos
  1. Inicie o navegador web;
  2. Limpe o cache do seu navegador;
  3. Inicie o Wireshark;
  4. Digite o seguinte URL no navegador http:200.17.101.9/redes/redes2.html;
  5. Pare a captura de pacotes e selecione o filtro http para que apenas as mensagens HTTP seja exibidas.

Na janela de listagem de pacotes, você deve ver a sua mensagem HTTP GET, seguida por uma reposta em vários pacotes. Esta resposta em vários pacotes merece uma explicação. Lembre-se da seção 2.2 do livro (veja a figura 2.9) que a mensagem de resposta HTTP consiste de uma linha de status, seguida por zero ou mais linhas de cabeçalhos, seguida por uma linha em branco, seguida pela carga útil (Content-Length). No caso do nossa HTTP GET, a carga útil na resposta é o arquivo HTTP completo. No nosso caso aqui, o arquivo em HTML é bastante longo, e a informação de 11747 bytes é muito grande para caber em um segmento TCP. A resposta HTTP simples é então quebrada em vários pedaços pelo TCP, com cada pedaço sendo contido dentro de um segmento TCP separado. Cada segmento TCP é capturado em um pacote separado pelo Wireshark, clique sobre o 9 "Reassembled TCP Segments" no Wireshark.

Responda às seguintes questões:

  1. Quantas mensagens HTTP GET foram enviadas pelo seu navegador?
  2. Quantos segmentos TCP foram necessários para carregar a resposta?
  3. Qual é o código de status e a frase associada com a resposta à mensagem HTTP GET?
  4. No segundo GET realizado, quantos segmentos TCP foram necessários para obtenção da resposta do servidor?
  5. O que explica a diferença entre a primeira e segunda requisições?

Documentos HTML com Objetos Incluídos

Agora que vimos como o Wireshark mostra o tráfego capturado para arquivos em HTML grandes, nós podemos observar o que acontece quando o seu browser baixa um arquivo com objetos incluídos, no nosso exemplo, imagens que estão armazenadas em outros servidores. Faça o seguinte:

  1. inicie o navegador web;
  2. limpe o cache do seu navegador;
  3. inicie o Wireshark;
  4. digite o URL no navegador http://www.sj.ifsc.edu.br/~odilson/RED29004/RED29004_arq3.html seu navegador deve exibir um arquivo pequeno em HTML com duas imagens incluídas. Estas duas imagens estão referenciadas no arquivo em HTML. Isto é, as imagens não estão no arquivo em HTML, ao invés disso, há um URL para cada imagem no arquivo em HTML. Como discutido no livro, seu navegador terá que baixar estas imagens dos locais correspondentes. A imagem da esquerda, redesWL_network.jpeg, está em ibxk.com.br. A imagem da direita, as-redes-sociais-como-instrumento-de-manipulacao-da-consciencia-coletiva.html.jpg, está em lounge.obviousmag.org;
  5. pare a captura de pacotes, e digite “http” na caixa de texto de especificação de filtro, para que apenas as mensagens HTTP seja exibidas.

Responda às seguintes questões:

  1. Quantas mensagens HTTP GET foram enviadas pelo seu navegador?
  2. Para quais endereços na Internet estas mensagens foram enviadas?
  3. Você consegue dizer se o seu navegador baixou as duas imagens em seqüência, ou se foram baixadas dos dois locais distintos em paralelo? Explique.

Autenticação HTTP

Finalmente, vamos tentar visitar um local na web que é protegido por senha e examinar a seqüência de mensagens HTTP trocadas com este local. O URL http://www.sj.ifsc.edu.br/~odilson/RED29004/Seguro/ é protegido por senha. O usuário é “red29004” (sem as aspas), e a senha é “seguro” (novamente, sem as aspas). Então vamos acessar o local protegido por senha. Faça o seguinte:

  1. inicie o navegador web;
  2. limpe o cache do seu navegador;
  3. inicie o Wireshark;
  4. digite o URL no navegador http://www.sj.ifsc.edu.br/~odilson/RED29004/Seguro/ seu navegador apresentará um pop up solicitando usuário e senha;
  5. forneça usuário e senha e o navegador apresentará uma "linda" página já conhecida;
  6. pare a captura de pacotes, e digite "http" na caixa de texto de especificação de filtro, para que apenas as mensagens HTTP seja exibidas.

Agora vamos examinar a saída do Wireshark. Você pode querer primeiro ler sobre a autenticação HTTP revisando o material fácil de ler (em inglês) HTTP Access Authentication Framework

Responda às seguintes questões:

  1. Qual é a resposta do servidor (código de status e frase) para a primeiro mensagem HTTP GET do seu navegador?
  2. Quando o seu navegador envia a mensagem HTTP GET pela segunda vez, qual o novo campo que está incluído na mensagem?

O nome de usuário (red29004) e a senha (seguro) que você digitou foram codificados na cadeia de caracteres (cmVkMjkwMDQ6c2VndXJv) após o cabeçalho “Authorization: Basic” na mensagem HTTP GET (primeira). Parece que o nome e senha estão criptografados, mas na verdade estão simplesmente codificados em um formato denominado Base64. O nome do usuário e a senha não estão criptografados! Para ver isso, vá para https://www.base64decode.org/ e digite o texto cmVkMjkwMDQ6c2VndXJv e pressione DECODE. Voilá! Você traduziu de Base64 para ASCII, e desta forma consegue ver o nome de usuário e a senha! Sabendo que alguém pode baixar o Wireshark e capturar pacotes (não somente os próprios), e alguém pode traduzir de Base64 para ASCII (você acabou de fazê-lo!), deve estar claro para você que o uso de senhas apenas em locais na web não garantem segurança, a não ser que medidas adicionais sejam tomadas. Não tema! Há meios de fazer o acesso WWW ser mais seguro. Contudo, nós claramente precisamos de algo que vá além do framework básico de autenticação HTTP!

HTTPS

Para finalizar, vamos capturar sequências de mensagens HTTPS, somente a título de comparação. Execute os seguintes procedimentos:

  1. inicie o navegador web;
  2. limpe o cache do seu navegador;
  3. inicie o Wireshark;
  4. digite o URL no navegador https://www.base64decode.org/ seu navegador apresentará um site já apresentado/utilizado;
  5. pare a captura de pacotes e digite "ssl" na caixa de texto de especificação de filtro, para que apenas as mensagens criptografadas sejam exibidas.

Responda:

  1. Compare a sequência de troca de mensagens (GET e resposta) entre o HTTP (das seções anteriores) com o ssl, existe alguma similaridade?
  2. Que tipos de campos são mais presentes nesse tipo de mensagens?
  3. Você consegue identificar o conteúdo de alguma nas mensagens ssl?



--Evandro.cantu (discussão) 16h36min de 23 de abril de 2015 (BRT)