Aula 6 - Protocolos de camada de aplicação

Prévia do material em texto

Protocolos de camada de aplicação
Introdução
A camada de aplicação de rede é composta tanto por protocolos que interagem diretamente com os usuários – como os navegadores de páginas web – quanto por aqueles que auxiliam a operação da internet – como o protocolo DNS.
Telnet e SSH, protocolos de acesso remoto, que são usados como ferramentas de software pelos operadores de rede e gestores dos aplicativos. 
SMTP e POP, protocolos de envio e recebimento de e-mails. 
DNS, FTP e HTTP protocolos muito importantes para a operação e a popularização do uso da internet.
Protocolos de acesso remoto Telnet e SSH
Podemos dizer que um dos protocolos mais básicos criados para redes de computadores é o que permite a execução de comandos em sistemas remotos, de maneira que os administradores das redes podem configurar e gerenciar sistemas operacionais e aplicativos a distância.
O protocolo Telnet, formalizado em 1983 pela RFC 854 (POSTEL; REYNOLDS, 1983), foi concebido para oferecer comunicação bidirecional de caracteres de 8 bits com base numa arquitetura cliente-servidor, criando um terminal virtual alfanumérico por meio do qual comandos digitados num terminal local são enviados para o servidor da rede e processados pelo SO (sistema operacional) remoto. Tais comandos podem levar à execução de um aplicativo, por exemplo, e os resultados são enviados de volta e apresentados no terminal local:
 Terminal remoto via protocolo Telnet
A figura apresenta dois computadores interligados pela internet, sendo um local e outro remoto. No computador local, temos um terminal físico ligado ao computador por um driver de terminal, que pertence ao Sistema Operacional local. Este driver está conectado a um software operando como cliente Telnet. O cliente Telnet está conectado ao protocolo TCP da pilha TCP/IP do Sistema Operacional, destacando os protocolos TCP, IP e Físico. Da camada Física parte a conexão com a internet. No computador remoto, a conexão com a internet chega na camada Física da pilha de protocolos TCP/IP implementada pelo Sistema Operacional remoto. Do protocolo TCP, a mensagem passa para o servidor Telnet remoto, que está conectado a um driver de pseudo-terminal do Sistema Operacional remoto. Deste driver, as mensagens são enviadas para os respectivos programas aplicativos em execução no computador remoto.
Para que o Telnet possa ser utilizado, é preciso que o SO remoto disponibilize um driver de pseudo-terminal ao qual o servidor Telnet estará ligado para enviar e receber as mensagens alfanuméricas. O cliente Telnet local estará ligado ao driver do SO local, ficando responsável por receber e enviar as mensagens para o terminal físico local.
Dependendo da implementação, o Telnet pode utilizar dois conjuntos de caracteres, um para os dados e outro para comandos. Por meio de uma sequência de teclas especiais digitadas pelo usuário no terminal local, esses comandos são interpretados pelo cliente e/ou servidor para definição de configurações opcionais da comunicação ou como controles enviados ao SO. De acordo com a RFC 854, alguns exemplos de comando são: 
· Ativar um modo específico de operação do terminal
· Sinalizar o fim de arquivo
· Interpretar o caractere seguinte como sendo um controle 
O protocolo SSH (secure shell), descrito na RFC 4254 (YLONEN; LONVICK, 2006), é usado para login remoto seguro e para transferência de arquivos. O SSH resolve o problema de segurança encontrado no protocolo Telnet, em que os caracteres de comando e de telas trocados entre cliente e servidor podem ser inspecionados por invasores da rede, visando a roubo de senhas de login trafegadas no formato de texto aberto (plain text). A comunicação entre cliente e servidor no SSH é criptografada ponto a ponto, impedindo que seja utilizada em ataques contra a segurança da rede. O protocolo SSH oferece diversas opções de autenticação de mensagens com alta segurança utilizando criptografia forte.
O SSH é implementado como serviço no modelo cliente-servidor, em que é o cliente SSH que se conecta ao servidor SSH e controla o processo de configuração segura da conexão, utilizando a chave pública de criptografia do servidor para verificar a sua identidade. O cliente SSH pode consultar um servidor de autenticação para verificar se a chave pública enviada pelo servidor SSH é legítima:
 Início de conexão entre cliente e servidor SSH
A figura apresenta a imagem uma sequência de mensagens trocadas entre o cliente SSH e o servidor SSH. Na mensagem 1, o cliente inicia a conexão contactando o servidor. Na mensagem 2, o servidor envia a sua chave pública. Na mensagem 3 são trocadas mensagens onde cliente e servidor negociam parâmetros de segurança. Na mensagem 4, o cliente envia informações de login para o Sistema Operacional remoto.
Depois que um canal seguro de comunicação tiver sido estabelecido entre cliente e servidor SSH, o procedimento de login será iniciado. Em caso de êxito no login, todas as mensagens trocadas posteriormente serão criptografadas com um par de chaves simétricas geradas especificamente para essa conexão.
O cliente SSH pode utilizar um centro de distribuição de chaves (KDC – key distribution center) tanto para comprovar sua legitimidade quanto para também se certificar que o servidor SSH é legítimo (RICCIARDI, 2007). Inicialmente, são registradas as chaves secretas dos clientes e do serviço de rede, no caso o SSH, que serão armazenadas na base de dados do KDC.
Depois, o cliente SSH autentica-se perante o servidor de autenticação (AS – autentication server), passando o identificador do usuário e sua senha, que serão convertidos numa chave secreta e confrontados com o valor armazenado na base de dados do KDC. Em caso de confirmada a identidade do usuário, o cliente SSH solicita então um ticket de serviço SSH ao servidor de concessão de tickets (TGS – ticket granting server). Esse ticket de serviço será enviado pelo cliente para o servidor no momento da negociação dos parâmetros de segurança (mensagem 3 da figura 2). Nessa arquitetura, tanto o cliente SSH quanto o servidor SSH certificam-se da legitimidade um do outro para estabelecer um canal de comunicação ponto a ponto seguro:
  Conexão SSH usando servidor de autenticação
A figura apresenta a arquitetura cliente-servidor SSH utilizando um Centro de Distribuição de Chaves, que é composto por uma base de dados, um Servidor TGS e um Servidor de Autenticação. O cliente SSH recebe o identificador e senha do usuário e se autentica com o Servidor de Autenticação. Depois, acessa o Servidor TGS e recebe um ticket do serviço SSH. Então, o cliente SSH envia este ticket para o servidor SSH durante a negociação de parâmetros de segurança.
Protocolos de e-mail SMTP e POP
O protocolo SMTP (simple mail transfer protocol), descrito na RFC 5321 (KLENSIN, 2008), e o POP3 (post office protocol version 3), detalhado na RFC 1939 (MYERS; ROSE, 1996), são utilizados respectivamente para despachar uma mensagem de e-mail ao destinatário e para receber essa mensagem.
Para entender como eles funcionam, é preciso descrever as funções dos diferentes elementos que compõem a arquitetura de um sistema de e-mail. Em linhas gerais, são dois tipos de agentes baseados no modelo cliente-servidor: 
· MTA (message transfer agent, ou agente de transferência de mensagem)
· MAA (message access agent, ou agente de acesso à mensagem).
Tomando como exemplo o ambiente descrito na figura 4, o cliente MTA que opera no computador da Alice recebe um e-mail que ela deseja enviar para o Bob e o transmite via SMTP para o servidor MTA da Alice, que o coloca numa fila de e-mails a serem enviados. O cliente MTA local analisa o endereço de destino do e-mail da Alice e envia-o para o servidor MTA em que o Bob possui sua caixa postal de e-mails. O e-mail da Alice é então armazenado na caixa postal do Bob. Em momento oportuno, o cliente MAA do computador do Bob solicita ao seu servidor MAA, via protocolo POP3, todos os e-mails que foram armazenados na caixapostal. É quando o e-mail enviado pela Alice finalmente chega ao seu destinatário.
 Arquitetura do sistema de e-mail
A figura apresenta a arquitetura do sistema de e-mail, formada por quatro computadores. O computador da Alice executa um cliente do protocolo MTA, o seu computador se comunica com o servidor de e-mail local por meio de uma conexão LAN ou WAN, usando o protocolo SMTP. Com esta conexão, o cliente MTA envia um e-mail para o servidor MTA, que o coloca numa fila local. No mesmo servidor de e-mail local, um cliente MTA se conecta via internet ao servidor e-mail remoto e envia a mensagem tirada da fila de mensagens locais para o servidor MTA remoto via protocolo SMTP. O servidor MTA remoto, coloca a mensagem numa caixa de mensagens. Um servidor MAA envia a mensagem da caixa de e-mail via LAN ou WAN para o cliente MAA do computador do Bob, via protocolo POP3.
O protocolo POP3 é usado pelo cliente MAA, que está sendo executado no computador do usuário para se conectar ao servidor MAA e receber os e-mails armazenados na sua caixa postal, conforme descrito na RFC 1939 (MYERS; ROSE, 1996).
Esse protocolo resolve a questão de o computador do usuário não estar sempre ligado ou conectado à internet, motivo pelo qual as caixas postais dos usuários serem localizadas no servidor de MAA. Quando o usuário deseja baixar seus e-mails, o cliente MAA do seu computador abre uma conexão TCP com o servidor MAA, envia nome e senha do usuário, recebe uma lista de e-mails armazenados na caixa postal e baixa cada um desses e-mails, armazenando-os no computador do usuário.
O POP3 tem dois modos de operação distintos. No primeiro, cada um dos e-mails lidos da caixa postal do servidor MAA é apagado, restando apenas a cópia do e-mail no computador de destino. No segundo modo de operação, o e-mail lido não é apagado da caixa postal do servidor MAA, podendo ser novamente baixado e reorganizado.
Para superar algumas limitações do POP3, o protocolo IMAP4 (internet message access protocol version 4, revision 1) foi implementado, conforme descrito na RFC 3501 (CRISPIN, 2003), permitindo:
· verificação do cabeçalho dos e-mails antes de baixá-los para o computador do usuário;
· pesquisa de e-mails por palavras-chave antes de baixá-los;
· transferência parcial de e-mails muito grandes, contendo, por exemplo, conteúdo multimídia;
· criação, eliminação ou renomeação de pastas no servidor de e-mails;
· criação de uma hierarquia de pastas de e-mails.
DNS, FTP e HTTP
DNS
O DNS provê serviços de rede importantes para a operação de toda a internet. Um deles é o de conversão de nomes de nós da rede em endereços IP. Ele é importante pois, mesmo que uma rede tenha todos os seus endereços IP alterados, por exemplo, o acesso aos servidores de páginas web, correio eletrônico e transferência de arquivos endereçados via seus respectivos nomes continuam sem nenhuma alteração.
Os domínios são organizados hierarquicamente, conforme descrito na RFC 1034 (MOCKAPETRIS, 1987a). Analisando o nome de um servidor de páginas web, por exemplo, www.sp.senac.br, identificamos o domínio “senac”, que possui subdomínio “sp” agregado à esquerda por um caractere “.”. O domínio “senac” é, por sua vez, subdomínio de “br”. O domínio “br” está no topo da hierarquia, sendo subdomínio apenas do domínio raiz. Por fim, o nome “www”, à esquerda, identifica o nome de um servidor web.
O protocolo de DNS, conforme descrito na RFC 1035 (MOCKAPETRIS, 1987b), é empregado na resolução de nomes na internet, isto é, tradução de nomes em endereços IP por meio da consulta interativa e recorrente aos servidores de DNS, como no modelo cliente-servidor. Inicialmente, a consulta é feita utilizando o protocolo UDP, seguida de uma consulta utilizando o protocolo TCP caso a primeira tenha falhado.
 Resolução de nomes utilizando o protocolo DNS
1. Consulta: 
2. Consulta:
3. Edu:
4. Consulta:
5. Washington.edu
6. Consulta
7. Cs.washington.edu
8. Consulta
9. Robot.cs.washington.edu
10. Robot.cs.washington.edu
A figura apresenta uma sequência de 10 mensagens utilizadas para a resolução do nome internet “flits.cs.vu.nl...de um computador originador de uma consulta ao servidor DNS local. Na mensagem 1, o computador originador envia uma consulta sobre o endereço IP do nome “robot.cs.washington..edu” para o servidor de nomes local, cujo endereço é “cs.vu.nl”. Na mensagem 2, o servidor de nome local envia uma consulta ao servidor de nomes raiz da internet, cujo endereço é “a.root-servers.net” recebendo como resposta a mensagem 3 indicando qual servidor responde pelo domínio “edu”. O servidor de nomes local então envia a mensagem 4 de consulta para o servidor de nomes do domínio “edu”, cujo endereço é “a.root-servers.net”, recebendo como resposta a mensagem 5 indicando qual servidor responde pelo domínio “Washington.edu”. Em seguida, o servidor de nomes local envia a mensagem 6 de consulta para o servidor de nomes do domínio “UW”, recebendo como resposta a mensagem 7 indicando qual servidor responde pelo domínio “cs.washington.edu”. Então, o servidor de nomes local envia a mensagem 8 de consulta para o servidor de nomes do domínio “UWCS”, recebendo a mensagem 9 com o endereço IP do nome “robot.cs.washington.edu”. Por fim, o servidor de nome envia a mensagem 10 com o endereço IP do nome “robot.cs.washington.edu” para o computador que originou a consulta original.
O protocolo de DNS estabelece a troca de mensagens com uma estrutura formada por cabeçalho, seção de perguntas, seção de respostas, seção de autoridades e seção de informações adicionais (FOROUZAN, 2010). A seção de respostas contém registros de recursos (RR – resource record), em que cada nome do domínio está associado a um registro específico, indicando diretamente a associação do nome com o seu endereço IP correspondente. A seção de autoridades é composta de RRs com um nome de domínio e o nome do servidor responsável pelo respectivo mapeamento de endereços IP nesse domínio.
A seção de informações adicionais também é formada por RRs contendo o endereço IP de servidores de resolução de domínios relacionados nas seções de resposta ou de autoridades, por exemplo.
A estrutura das mensagens trocadas entre cliente e servidor de DNS é apresentada na figura 6, conforme descrito na RFC 1035 (MOCKAPETRIS, 1987b).
 Estrutura das mensagens do protocolo DNS: consulta e resposta.
FTP
O protocolo FTP (file transfer protocol) permite a transferência segura e eficiente de arquivos via rede de computadores, que é um dos serviços mais utilizados atualmente na internet, conforme descrito na RFC 959 (POSTEL; REYNOLDS, 1985).
Ao contrário de outros protocolos que adotam o modelo cliente-servidor, o FTP estabelece duas conexões TCP simultâneas entre cliente e servidor: uma para troca de controles (porta 21) e outra para transferência de dados (porta 20).
É pela conexão de controle que o cliente FTP define o tipo de arquivo a ser transferido, a sua estrutura de dados e o modo de transmissão. Só depois dessas definições é que o conteúdo do arquivo passa a ser transferido pela conexão de dados.
 Conexões de comandos e dados do protocolo FTP
A figura apresenta o esquema de conexão cliente-servidor do protocolo FTP. No computador cliente, existe uma interface com o usuário, o disco local e dois processos, um de controle da conexão de controle do FTP e outro processo de transferência de dados que controla a conexão de dados do FTP. No outro computador operando como servidor FTP, também encontramos a conexão com o disco local e dois processos, um de controle da conexão de controle do FTP e outro processo de transferência de dados que controla a conexão de dados do FTP.
HTTP
O protocolo HTTP (hypertext transfer protocol) opera na camada de aplicação do TCP/IP e é usado para a implementação de sistemas de informação colaborativos e distribuídos, formado por páginas web no formato de hypertexto, conforme descrito na RFC 7230 (FIELDING; RESCHKE,2014). O conjunto de todas as páginas web é que forma a WWW (world wide web). Uma página web é composta por um arquivo no formato HTML (hypertext markup language) que contém referências a outros objetos, como imagens e vídeos, conforme descrito na RFC 1866 (BERNERS-LEE; CONNOLLY, 1995). Cada página web e respectivos objetos possuem um identificador denominado URL (uniform resource locator), formado pelo nome do servidor (hostname) em que a página está hospedada e pelo caminho (path) até o objeto por ela referenciado (KUROSE; ROSS, 2013).
Por exemplo, a URL apresentada a seguir pode ser dividida em duas partes. A primeira refere-se ao hostname, que também é referenciado como site web. A segunda parte descreve o caminho de um objeto do tipo imagem:
	 https://www.sp.senac.br/
	 imagens/eventos/ARrisqueSe.jpg
	 Hostname
	 Caminho do objeto tipo imagem
O HTTP adotou o modelo cliente-servidor de comunicação, que utiliza o protocolo TCP para envio de requisições e recepção de respostas. O cliente HTTP, que é comumente chamado de navegador web (browser), é comandado por uma interface com o usuário, o qual fornece a URL da página web que deseja consultar e a recebe na tela do computador ou do celular.
 Arquitetura do protocolo HTTP
A figura apresenta a arquitetura do HTTP, composta por um computador cliente e dois servidores HTTP, denominados site A e site B. O cliente HTTP envia uma solicitação para o servidor do site A e recebe uma página web A. O cliente HTTP também envia uma solicitação para o servidor do site B e recebe uma página web B.
O servidor HTTP fica permanentemente aguardando a solicitação de uma página web. A conexão cliente-servidor pode ser: 
· Não persistente: servidor estabelece uma conexão com o cliente, recebe a solicitação da página desejada, envia seu conteúdo e encerra a conexão.
· Persistente: em vez de encerrar a conexão, o servidor a mantém para que o cliente possa enviar novas solicitações, eliminando o tempo repetidamente gasto com a desconexão e reconexão.
Protocolo HTTPS
SEVIÇOS PRESTADOS VIA SERVIDORES HTTP:
· NAVEGAÇÃO EM SITES
· INTERNET BANKING
· E-COMMERCE
COMO GARANTIR A SEGURANÇA DOS DADOS DURANTE A NAGVEGAÇÃO WEB?
HTTP X HTTPS
SSL / TLS
COMPOSIÇÃO DO PROTOCOLO HTTPS
CRIPTOGRAFIA
FUNCIONAMENTO DO PROTOCOLO SSL
FLUXO DE MENSAGENS VIA HTTPS