Segurança de rede - Camada de transporte
A segurança da rede envolve proteger os dados contra ataques enquanto eles estão em trânsito em uma rede. Para atingir esse objetivo, muitos protocolos de segurança em tempo real foram projetados. Existem padrões populares para protocolos de segurança de rede em tempo real, como S / MIME, SSL / TLS, SSH e IPsec. Conforme mencionado anteriormente, esses protocolos funcionam em diferentes camadas do modelo de rede.
No último capítulo, discutimos alguns protocolos populares que são projetados para fornecer segurança na camada de aplicativo. Neste capítulo, discutiremos o processo de obtenção da segurança da rede na camada de transporte e os protocolos de segurança associados.
Para rede baseada em protocolo TCP / IP, camadas físicas e de enlace de dados são geralmente implementadas no terminal do usuário e no hardware da placa de rede. As camadas TCP e IP são implementadas no sistema operacional. Qualquer coisa acima de TCP / IP é implementada como processo do usuário.
Necessidade de Segurança da Camada de Transporte
Vamos discutir uma transação comercial típica na Internet.
Bob visita o site de Alice para vender produtos. Em um formulário do site, Bob insere o tipo de bem e a quantidade desejada, seu endereço e detalhes do cartão de pagamento. Bob clica em Enviar e aguarda a entrega da mercadoria com débito do valor do preço de sua conta. Tudo isso parece bom, mas, na ausência de segurança de rede, Bob poderia ter algumas surpresas.
Se as transações não usassem confidencialidade (criptografia), um invasor poderia obter as informações de seu cartão de pagamento. O invasor pode então fazer compras às custas de Bob.
Se nenhuma medida de integridade de dados for usada, um invasor pode modificar o pedido de Bob em termos de tipo ou quantidade de mercadorias.
Por último, se nenhuma autenticação de servidor for usada, um servidor pode exibir o famoso logotipo de Alice, mas o site pode ser um site malicioso mantido por um invasor, que está se fazendo passar por Alice. Depois de receber o pedido de Bob, ele poderia pegar o dinheiro de Bob e fugir. Ou ele poderia realizar um roubo de identidade coletando o nome de Bob e os detalhes do cartão de crédito.
Os esquemas de segurança da camada de transporte podem resolver esses problemas aprimorando a comunicação de rede baseada em TCP / IP com confidencialidade, integridade de dados, autenticação de servidor e autenticação de cliente.
A segurança nesta camada é usada principalmente para proteger transações da Web baseadas em HTTP em uma rede. No entanto, ele pode ser empregado por qualquer aplicativo que execute TCP.
Filosofia de Design TLS
Os protocolos de segurança da camada de transporte (TLS) operam acima da camada TCP. O projeto desses protocolos usa interfaces de programas de aplicativos (API) populares para TCP, chamados de "soquetes" para fazer a interface com a camada TCP.
Os aplicativos agora têm interface com a camada de segurança de transporte em vez de com o TCP diretamente. O Transport Security Layer fornece uma API simples com soquetes, que é semelhante e análoga à API do TCP.
No diagrama acima, embora o TLS resida tecnicamente entre o aplicativo e a camada de transporte, da perspectiva comum é um protocolo de transporte que atua como uma camada TCP aprimorada com serviços de segurança.
O TLS foi projetado para operar sobre TCP, o protocolo confiável da camada 4 (não no protocolo UDP), para tornar o projeto do TLS muito mais simples, porque ele não precisa se preocupar com 'tempo limite' e 'retransmissão de dados perdidos'. A camada TCP continua fazendo isso normalmente, o que atende à necessidade de TLS.
Por que o TLS é popular?
A razão da popularidade do uso de segurança na Camada de Transporte é a simplicidade. O design e a implantação da segurança nesta camada não requerem nenhuma mudança nos protocolos TCP / IP implementados em um sistema operacional. Apenas os processos e aplicativos do usuário precisam ser projetados / modificados, o que é menos complexo.
Secure Socket Layer (SSL)
Nesta seção, discutimos a família de protocolos projetados para TLS. A família inclui as versões 2 e 3 do SSL e o protocolo TLS. SSLv2 agora foi substituído por SSLv3, portanto, vamos nos concentrar em SSL v3 e TLS.
Breve História do SSL
No ano de 1995, a Netscape desenvolveu o SSLv2 e foi usado no Netscape Navigator 1.1. O SSL version1 nunca foi publicado e usado. Posteriormente, a Microsoft aprimorou o SSLv2 e introduziu outro protocolo semelhante, denominado Private Communications Technology (PCT).
A Netscape melhorou substancialmente o SSLv2 em várias questões de segurança e implantou o SSLv3 em 1999. A Internet Engineering Task Force (IETF) subsequentemente, introduziu um protocolo TLS (Transport Layer Security) semelhante como um padrão aberto. O protocolo TLS não é interoperável com SSLv3.
O TLS modificou os algoritmos criptográficos para expansão e autenticação de chaves. Além disso, a TLS sugeriu o uso de criptografia aberta Diffie-Hellman (DH) e Digital Signature Standard (DSS) no lugar da criptografia RSA patenteada usada em SSL. Mas, devido à expiração da patente RSA em 2000, não existiam fortes razões para os usuários mudarem do SSLv3 amplamente implantado para o TLS.
Características importantes do SSL
Os principais recursos do protocolo SSL são os seguintes -
SSL fornece segurança de conexão de rede por meio de -
Confidentiality - As informações são trocadas de forma criptografada.
Authentication- As entidades de comunicação se identificam por meio do uso de certificados digitais. A autenticação do servidor da Web é obrigatória, enquanto a autenticação do cliente é opcional.
Reliability - Mantém verificações de integridade da mensagem.
SSL está disponível para todos os aplicativos TCP.
Suportado por quase todos os navegadores da web.
Oferece facilidade para fazer negócios com novas entidades online.
Desenvolvido principalmente para Web e-commerce.
Arquitetura de SSL
SSL é específico para TCP e não funciona com UDP. SSL fornece Interface de Programação de Aplicativo (API) para aplicativos. Bibliotecas / classes C e Java SSL estão prontamente disponíveis.
O protocolo SSL é projetado para interagir entre o aplicativo e a camada de transporte, conforme mostrado na imagem a seguir -
O próprio SSL não é um protocolo de camada única, conforme representado na imagem; na verdade, é composto de duas subcamadas.
A subcamada inferior é composta por um componente do protocolo SSL chamado SSL Record Protocol. Este componente fornece serviços de integridade e confidencialidade.
A subcamada superior é composta por três componentes de protocolo relacionados ao SSL e um protocolo de aplicativo. O componente do aplicativo fornece o serviço de transferência de informações entre as interações cliente / servidor. Tecnicamente, ele também pode operar na camada SSL. Três componentes de protocolo relacionados ao SSL são -
- Protocolo de handshake SSL
- Alterar protocolo de especificação de criptografia
- Protocolo de alerta.
Esses três protocolos gerenciam todas as trocas de mensagens SSL e são discutidos posteriormente nesta seção.
Funções de componentes do protocolo SSL
Os quatro subcomponentes do protocolo SSL lidam com várias tarefas para comunicação segura entre a máquina cliente e o servidor.
Protocolo de Registro
A camada de registro formata as mensagens de protocolo da camada superior.
Ele fragmenta os dados em blocos gerenciáveis (comprimento máximo de 16 KB). Opcionalmente, compacta os dados.
Criptografa os dados.
Fornece um cabeçalho para cada mensagem e um hash (Message Authentication Code (MAC)) no final.
Transfere os blocos formatados para a camada TCP para transmissão.
Protocolo de handshake SSL
É a parte mais complexa do SSL. Ele é chamado antes da transmissão de qualquer dado do aplicativo. Ele cria sessões SSL entre o cliente e o servidor.
O estabelecimento da sessão envolve autenticação de servidor, negociação de chave e algoritmo, estabelecimento de chaves e autenticação de cliente (opcional).
Uma sessão é identificada por um conjunto exclusivo de parâmetros de segurança criptográfica.
Várias conexões TCP seguras entre um cliente e um servidor podem compartilhar a mesma sessão.
Ações do protocolo de handshake em quatro fases. Estas são discutidas na próxima seção.
Protocolo ChangeCipherSpec
A parte mais simples do protocolo SSL. É composto por uma única mensagem trocada entre duas entidades que se comunicam, o cliente e o servidor.
Conforme cada entidade envia a mensagem ChangeCipherSpec, ela muda seu lado da conexão para o estado seguro conforme acordado.
O estado pendente dos parâmetros de codificação é copiado para o estado atual.
A troca desta mensagem indica que todas as trocas de dados futuras são criptografadas e a integridade está protegida.
Protocolo de Alerta SSL
Este protocolo é usado para relatar erros - como mensagem inesperada, registro incorreto de MAC, falha na negociação de parâmetros de segurança, etc.
Ele também é usado para outros fins - como notificar o fechamento da conexão TCP, notificar o recebimento de um certificado inválido ou desconhecido, etc.
Estabelecimento da Sessão SSL
Conforme discutido acima, existem quatro fases de estabelecimento da sessão SSL. Eles são tratados principalmente pelo protocolo SSL Handshake.
Phase 1 - Estabelecer recursos de segurança.
Esta fase compreende a troca de duas mensagens - Client_hello e Server_hello .
Client_hello contém uma lista de algoritmos criptográficos suportados pelo cliente, em ordem decrescente de preferência.
Server_hello contém a especificação de cifra selecionada (CipherSpec) e um novo session_id .
O CipherSpec contém campos como -
Algoritmo de cifra (DES, 3DES, RC2 e RC4)
Algoritmo MAC (baseado em MD5, SHA-1)
Algoritmo de chave pública (RSA)
Ambas as mensagens têm “nonce” para evitar o ataque de repetição.
Phase 2 - Autenticação de servidor e troca de chaves.
O servidor envia o certificado. O software cliente vem configurado com chaves públicas de várias organizações “confiáveis” (CAs) para verificar o certificado.
O servidor envia o conjunto de criptografia escolhido.
O servidor pode solicitar o certificado do cliente. Normalmente não é feito.
Servidor indica fim de Server_hello .
Phase 3 - Autenticação de cliente e troca de chaves.
O cliente envia o certificado, apenas se solicitado pelo servidor.
Ele também envia o segredo pré-mestre (PMS) criptografado com a chave pública do servidor.
O cliente também envia a mensagem Certificate_verify se o certificado for enviado por ele para provar que ele possui a chave privada associada a este certificado. Basicamente, o cliente assina um hash das mensagens anteriores.
Phase 4 - Terminar.
O cliente e o servidor enviam mensagens Change_cipher_spec um para o outro para fazer com que o estado de cifra pendente seja copiado para o estado atual.
A partir de agora, todos os dados são criptografados e protegidos por integridade.
A mensagem “Concluído” de cada extremidade verifica se os processos de troca de chaves e autenticação foram bem-sucedidos.
Todas as quatro fases, discutidas acima, acontecem no estabelecimento da sessão TCP. O estabelecimento da sessão SSL começa após TCP SYN / SYNACK e termina antes do TCP Fin.
Retomando uma sessão desconectada
É possível retomar uma sessão desconectada (por meio de mensagem de alerta ), se o cliente enviar um hello_request ao servidor com a informação de session_id criptografada .
O servidor então determina se o session_id é válido. Se validado, ele troca mensagens ChangeCipherSpec e concluídas com o cliente e retoma as comunicações seguras.
Isso evita o recálculo de parâmetros de cifra de sessão e economiza computação no servidor e no cliente.
Chaves de Sessão SSL
Vimos que durante a Fase 3 do estabelecimento da sessão SSL, um segredo pré-mestre é enviado pelo cliente ao servidor criptografado usando a chave pública do servidor. O segredo mestre e várias chaves de sessão são gerados da seguinte forma -
O segredo mestre é gerado (via gerador de números pseudo-aleatórios) usando -
O segredo pré-master.
Dois nonces (RA e RB) trocados nas mensagens client_hello e server_hello.
Seis valores secretos são derivados deste segredo mestre como -
Chave secreta usada com MAC (para dados enviados pelo servidor)
Chave secreta usada com MAC (para dados enviados pelo cliente)
Chave secreta e IV usados para criptografia (por servidor)
Chave secreta e IV usados para criptografia (por cliente)
Protocolo TLS
A fim de fornecer um padrão de Internet aberto de SSL, a IETF lançou o protocolo Transport Layer Security (TLS) em janeiro de 1999. O TLS é definido como um padrão de Internet proposto no RFC 5246.
Características Salientes
O protocolo TLS tem os mesmos objetivos do SSL.
Ele permite que os aplicativos cliente / servidor se comuniquem de maneira segura por meio da autenticação, evitando a interceptação e resistindo à modificação da mensagem.
O protocolo TLS fica acima da camada TCP de transporte orientado a conexão confiável na pilha de camadas de rede.
A arquitetura do protocolo TLS é semelhante ao protocolo SSLv3. Tem dois subprotocolos: o protocolo TLS Record e o protocolo TLS Handshake.
Embora os protocolos SSLv3 e TLS tenham arquitetura semelhante, várias alterações foram feitas na arquitetura e no funcionamento, especialmente para o protocolo de handshake.
Comparação de protocolos TLS e SSL
Existem oito diferenças principais entre os protocolos TLS e SSLv3. Estes são os seguintes -
Protocol Version - O cabeçalho do segmento do protocolo TLS carrega o número da versão 3.1 para diferenciar entre o número 3 carregado pelo cabeçalho do segmento do protocolo SSL.
Message Authentication- TLS emprega um código de autenticação de mensagem hash com chave (H-MAC). A vantagem é que o H-MAC opera com qualquer função hash, não apenas MD5 ou SHA, conforme explicitamente declarado pelo protocolo SSL.
Session Key Generation - Existem duas diferenças entre o protocolo TLS e SSL para geração de material de chave.
O método de computação dos segredos mestre e pré-mestre é semelhante. Mas no protocolo TLS, o cálculo do segredo mestre usa o padrão HMAC e a saída da função pseudo-aleatória (PRF) em vez do MAC ad-hoc.
O algoritmo para calcular chaves de sessão e valores de iniciação (IV) é diferente no protocolo TLS e no protocolo SSL.
Mensagem de protocolo de alerta -
O protocolo TLS suporta todas as mensagens usadas pelo protocolo de Alerta do SSL, exceto nenhuma mensagem de alerta de certificado sendo redundante. O cliente envia um certificado vazio caso a autenticação do cliente não seja necessária.
Muitas mensagens de alerta adicionais são incluídas no protocolo TLS para outras condições de erro, como record_overflow, decode_error etc.
Supported Cipher Suites- SSL suporta conjuntos de criptografia RSA, Diffie-Hellman e Fortezza. O protocolo TLS suporta todos os naipes, exceto Fortezza.
Client Certificate Types- TLS define os tipos de certificado a serem solicitados em uma mensagem certificate_request . SSLv3 suporta tudo isso. Além disso, o SSL oferece suporte a certos outros tipos de certificado, como Fortezza.
Verificação de certificado e mensagens concluídas -
Em SSL, o procedimento de mensagem complexo é usado para a mensagem certificate_verify . Com o TLS, as informações verificadas estão contidas nas próprias mensagens de handshake, evitando esse procedimento complexo.
A mensagem finalizada é calculada de maneiras diferentes em TLS e SSLv3.
Padding of Data- No protocolo SSL, o preenchimento adicionado aos dados do usuário antes da criptografia é a quantidade mínima necessária para tornar o tamanho total dos dados igual a um múltiplo do comprimento do bloco da cifra. No TLS, o preenchimento pode ser qualquer quantidade que resulte em um tamanho de dados que seja um múltiplo do comprimento do bloco da cifra, até um máximo de 255 bytes.
As diferenças acima entre os protocolos TLS e SSLv3 estão resumidas na tabela a seguir.
Navegação segura - HTTPS
Nesta seção, discutiremos o uso do protocolo SSL / TLS para realizar uma navegação segura na web.
HTTPS definido
O protocolo HTTP (Hyper Text Transfer Protocol) é usado para navegação na web. A função de HTTPS é semelhante a HTTP. A única diferença é que o HTTPS oferece navegação “segura” na web. HTTPS significa HTTP sobre SSL. Este protocolo é usado para fornecer a conexão criptografada e autenticada entre o navegador da Web do cliente e o servidor do site.
A navegação segura por HTTPS garante que o seguinte conteúdo seja criptografado -
- URL da página da web solicitada.
- Conteúdo da página da Web fornecido pelo servidor ao cliente do usuário.
- Conteúdo dos formulários preenchidos pelo usuário.
- Cookies estabelecidos em ambas as direções.
Trabalho de HTTPS
O protocolo de aplicativo HTTPS normalmente usa um de dois protocolos de segurança de camada de transporte populares - SSL ou TLS. O processo de navegação segura é descrito nos pontos a seguir.
Você solicita uma conexão HTTPS a uma página da web inserindo https: // seguido de URL na barra de endereço do navegador.
O navegador da web inicia uma conexão com o servidor da web. O uso de https invoca o uso do protocolo SSL.
Um aplicativo, navegador neste caso, usa a porta do sistema 443 em vez da porta 80 (usada no caso de http).
O protocolo SSL passa por um protocolo de handshake para estabelecer uma sessão segura, conforme discutido nas seções anteriores.
O site inicialmente envia seu certificado digital SSL para o seu navegador. Na verificação do certificado, o handshake SSL progride para trocar os segredos compartilhados da sessão.
Quando um certificado digital SSL confiável é usado pelo servidor, os usuários veem um ícone de cadeado na barra de endereço do navegador. Quando um Certificado de validação estendida é instalado em um site, a barra de endereço fica verde.
Uma vez estabelecida, esta sessão consiste em várias conexões seguras entre o servidor da web e o navegador.
Uso de HTTPS
O uso de HTTPS fornece confidencialidade, autenticação do servidor e integridade da mensagem ao usuário. Permite a condução segura do comércio eletrônico na Internet.
Impede a escuta de dados e nega o roubo de identidade, que são ataques comuns em HTTP.
Os navegadores e servidores da web atuais são equipados com suporte HTTPS. O uso de HTTPS sobre HTTP, entretanto, requer mais poder de computação no cliente e na extremidade do servidor para realizar a criptografia e o handshake SSL.
Protocolo Secure Shell (SSH)
As principais características do SSH são as seguintes -
SSH é um protocolo de rede executado na camada TCP / IP. Ele foi projetado para substituir o TELNET, que fornecia meios não seguros de instalação de logon remoto.
O SSH fornece uma comunicação cliente / servidor segura e pode ser usado para tarefas como transferência de arquivos e e-mail.
SSH2 é um protocolo predominante que fornece segurança de comunicação de rede aprimorada em relação à versão anterior SSH1.
SSH definido
O SSH é organizado em três subprotocolos.
Transport Layer Protocol- Esta parte do protocolo SSH fornece confidencialidade de dados, autenticação de servidor (host) e integridade de dados. Opcionalmente, também pode fornecer compactação de dados.
Server Authentication- As chaves do host são assimétricas, como as chaves públicas / privadas. Um servidor usa uma chave pública para provar sua identidade a um cliente. O cliente verifica se o servidor contatado é um host “conhecido” no banco de dados que mantém. Depois que o servidor é autenticado, as chaves de sessão são geradas.
Session Key Establishment- Após a autenticação, o servidor e o cliente concordam com a cifra a ser usada. As chaves de sessão são geradas pelo cliente e pelo servidor. As chaves de sessão são geradas antes da autenticação do usuário para que nomes de usuários e senhas possam ser enviados criptografados. Essas chaves são geralmente substituídas em intervalos regulares (digamos, a cada hora) durante a sessão e são destruídas imediatamente após o uso.
Data Integrity- SSH usa algoritmos de código de autenticação de mensagem (MAC) para verificar a integridade dos dados. É uma melhoria em relação ao CRC de 32 bits usado pelo SSH1.
User Authentication Protocol- Esta parte do SSH autentica o usuário no servidor. O servidor verifica se o acesso é concedido apenas aos usuários pretendidos. Muitos métodos de autenticação são usados atualmente, como senhas digitadas, Kerberos, autenticação de chave pública, etc.
Connection Protocol - Isso fornece vários canais lógicos em uma única conexão SSH subjacente.
Serviços SSH
O SSH fornece três serviços principais que permitem o fornecimento de muitas soluções seguras. Esses serviços são descritos resumidamente a seguir -
Secure Command-Shell (Remote Logon)- Permite ao usuário editar arquivos, ver o conteúdo dos diretórios e acessar aplicativos no dispositivo conectado. Os administradores de sistemas podem iniciar / visualizar / interromper serviços e processos remotamente, criar contas de usuário e alterar permissões de arquivos / diretórios e assim por diante. Todas as tarefas viáveis no prompt de comando de uma máquina agora podem ser executadas com segurança na máquina remota usando logon remoto seguro.
Secure File Transfer- SSH File Transfer Protocol (SFTP) é projetado como uma extensão para SSH-2 para transferência segura de arquivos. Em essência, é um protocolo separado em camadas sobre o protocolo Secure Shell para lidar com as transferências de arquivos. SFTP criptografa o nome de usuário / senha e os dados do arquivo sendo transferidos. Ele usa a mesma porta do servidor Secure Shell, ou seja, a porta do sistema nº 22.
Port Forwarding (Tunneling)- Permite que os dados de aplicativos baseados em TCP / IP não seguros sejam protegidos. Após a configuração do encaminhamento de porta, o Secure Shell redireciona o tráfego de um programa (geralmente um cliente) e o envia através do túnel criptografado para o programa do outro lado (geralmente um servidor). Vários aplicativos podem transmitir dados em um único canal seguro multiplexado, eliminando a necessidade de abrir muitas portas em um firewall ou roteador.
Benefícios e limitações
Os benefícios e limitações do emprego de segurança de comunicação na camada de transporte são os seguintes -
Benefícios
A Segurança da Camada de Transporte é transparente para os aplicativos.
O servidor está autenticado.
Os cabeçalhos da camada de aplicativo ficam ocultos.
É mais refinado do que os mecanismos de segurança na camada 3 (IPsec), pois funciona no nível de conexão de transporte.
Limitações
Aplicável apenas a aplicativos baseados em TCP (não UDP).
Os cabeçalhos TCP / IP estão claros.
Adequado para comunicação direta entre o cliente e o servidor. Não atende a aplicativos seguros que usam cadeia de servidores (por exemplo, e-mail)
SSL não fornece não repúdio, pois a autenticação do cliente é opcional.
Se necessário, a autenticação do cliente precisa ser implementada acima do SSL.
Resumo
Um grande número de aplicativos da web surgiu na Internet na última década. Muitos portais de e-Governance e e-Commerce estão online. Essas aplicações requerem que a sessão entre o servidor e o cliente seja segura, fornecendo confidencialidade, autenticação e integridade das sessões.
Uma forma de mitigar um ataque potencial durante a sessão de um usuário é usar um protocolo de comunicação seguro. Dois desses protocolos de comunicação, Secure Sockets Layer (SSL) e Transport Layer Security (TLS), são discutidos neste capítulo. Ambos os protocolos funcionam na camada de transporte.
Outro protocolo da camada de transporte, Secure Shell (SSH), projetado para substituir o TELNET, fornece meios seguros de instalação de logon remoto. É capaz de fornecer vários serviços, como Secure Command Shell e SFTP.
O emprego da segurança da camada de transporte tem muitos benefícios. No entanto, o protocolo de segurança projetado nessa camada pode ser usado apenas com TCP. Eles não fornecem segurança para a comunicação implementada usando UDP.