Por que a criptografia não destrói o funcionamento das redes?

8

Eu tenho uma compreensão muito básica de como a criptografia funciona.

Meu conhecimento, na medida em que é de nível de descoberta CCNA no CISCO cursos (juntamente com algumas outras coisas, como Steve Gibson e Leo Laporte em " Segurança agora "em vários episódios).

Minha (s) pergunta (s) é (são):

A criptografia não quebraria o conceito de rede do destino de origem ip / mac e o endereço MAC em pacotes / quadros?

Porque ...

Obviamente, quaisquer dados de "descriptografia" (chaves) poderiam ser enviados com os dados, mas isso quebraria a segurança, ao passo que os switches não poderiam direcionar dados e construir suas tabelas MAC em uma rede interna.

Agora eu vou fazer algumas suposições sobre o que eu sei. Qualquer um:

  1. Os switches podem usar o que há nos pacotes IP & O cabeçalho encapsulado do endereço MAC acompanha os dados conhecidos das conexões anteriores para descriptografar os pacotes encapsulados com o endereço MAC dos quadros de origem e destino.
  2. Os roteadores podem usar o que está nos dados dos pacotes / conexões anteriores para descriptografar os pacotes encapsulados com os endereços IP de origem e de destino.
  3. Todo o conceito de criptografia na internet é impraticável (obviamente falso)
  4. MACs / ip de origem e destino são enviados sem criptografia para pacotes criptografados. (Se este for o caso, isso significa que um man-in-the-middle poderia capturar todos os dados, registrá-los e gastar tanto tempo quanto eles, por favor, brutam forçando as chaves a descriptografá-los?)

Ou então, minhas suposições são falsas por algum motivo (por que elas são falsas?).

Esta questão nasce do conhecimento inteiramente teórico de aprender esses cursos, então, por favor, vá a tantos detalhes quanto você estiver absolutamente disposto, mesmo se estiver pensando que está declarando o óbvio. Eu estou pedindo isso por razões puramente acadêmicas / intensa curiosidade, não porque eu tenha um problema prático.

    
por Dmatig 18.12.2009 / 21:03

4 respostas

5

Sua suposição # 4 está parcialmente correta. Frequentemente, em tecnologias como SSL / TLS, endereços IP & Os endereços MAC são enviados sem criptografia. Mais especificamente, se olharmos para o Modelo de Rede OSI , os endereços IP fazem parte do nível 3, os endereços MAC são parte do nível dois, enquanto o SSL / TLS está no nível 4. A maioria das tecnologias de criptografia funciona acima do nível 3, de modo que o endereçamento possa ser lido por roteadores e comutadores padrão.

Para resolver o problema do homem, as tecnologias de criptografia precisam fornecer algum tipo de autenticação antes de iniciar a sessão criptografada. No exemplo SSL / TLS, o uso de certificados fornecidos por uma autoridade de certificação confiável (ou seja, Verisign) é usado para autenticação.

    
por 18.12.2009 / 21:06
6

Para entrar em detalhes possivelmente indesejados: A criptografia ocorre na camada de transporte e acima, exatamente pelos motivos de sua preocupação. A camada de transporte é a imediatamente acima do IP e outros esquemas de endereçamento. Isso significa que as informações necessárias para esses protocolos não são criptografadas, porque os dados pertencem a uma camada inferior.

Por exemplo, o TLS e seu predecessor SSL são criptografados na camada de transporte. Isso significa que os únicos dados não criptografados são os cabeçalhos IP.

Enquanto isso, quando você optar por criptografar um e-mail em seu programa de e-mail favorito, ele só criptografará a mensagem de e-mail real, enquanto os cabeçalhos IP, TCP e SMTP não serão criptografados. Essa mensagem, por sua vez, pode ser transmitida por meio de uma conexão TLS. O TLS irá criptografar as partes TCP e SMTP, criptografando efetivamente o corpo da mensagem duas vezes. O cabeçalho IP não criptografado seria suficiente para obtê-lo do seu computador para o servidor de e-mail. O servidor de email, em seguida, descriptografaria o TLS, permitindo-lhe ver que esta é uma mensagem TCP SMTP. Em seguida, ele passaria isso para o programa SMTP, que poderia enviá-lo para a caixa de entrada correta. Uma vez lá, o leitor de e-mail do usuário teria as informações necessárias para descriptografar o corpo da mensagem.

    
por 18.12.2009 / 21:11
5

O número 4 é verdadeiro. Quando um pacote criptografado é enviado, os dados são criptografados, não os endereços de origem e destino.

Dê uma olhada neste pacote de login do SSH:

Ele é exibido como um pacote de solicitação criptografado. Como você pode ver, os detalhes de origem e destino são visíveis.

    
por 18.12.2009 / 21:06
2

WEP e WPA são tags para a questão, que são para redes sem fio. Esses protocolos lidam com criptografia para a camada de rede, mas são usados para impedir que as pessoas que não estão na rede possam ver o que a rede está enviando.

Todos os nós de uma rede sem fio devem conhecer a chave de criptografia, para que o roteador da rede possa decodificar todo o tráfego. Acredito que isso implica que qualquer nó conectado a uma rede sem fio criptografada possa farejar todo o tráfego nessa rede.

Portanto, o WEP e o WPA não protegem contra usuários mal-intencionados que estão na mesma rede que você. Você ainda precisa usar outras camadas de criptografia para ocultar o tráfego delas.

Editar:

Depois de ler o 802.11i (conhecido como WEP2), vejo que ele usa uma chave separada para pacotes broadcast e multicast (Group Temporal Key). O tráfego Unicast é criptografado usando uma Pair Pair Key, que é uma chave usada para o tráfego entre a estação base e um dispositivo sem fio. WEP também funciona dessa maneira. Isso significa que dois dispositivos sem fio não podem ler o tráfego um do outro, pois eles não compartilham a mesma chave.

Acredito que o WEP usa uma chave compartilhada para todos os nós.

Em qualquer caso, os ambientes corporativos geralmente usam a tecnologia VPN no topo do link sem fio. Essa camada adicional de criptografia fornece segurança do dispositivo sem fio até o servidor VPN. Mesmo se a rede sem fio for detectada, os pacotes da VPN ainda serão criptografados.

    
por 18.12.2009 / 22:30