Os dados sempre são criptografados nas comunicações IPv6?


30

Não consigo obter uma resposta direta para essa pergunta. A Wikipedia diz que "IPsec é parte integrante do conjunto de protocolos básicos no IPv6", mas isso significa que TODAS as comunicações são sempre criptografadas ou significa que a criptografia é opcional, mas os dispositivos devem ser capazes de entendê-lo (caso seja usado) )?

Se a criptografia é opcional, é o sistema operacional que decide se deve usar criptografia ou é o aplicativo? Os sistemas operacionais e softwares populares geralmente ativam a criptografia?

Eu mesmo investigaria isso, mas não tenho conectividade IPv6.

Atualização: Ok, então é opcional. Minha pergunta de acompanhamento: normalmente, é o aplicativo que define se deve usar criptografia ou é o sistema operacional?

Um exemplo específico: imagine que tenho uma versão recente do Windows com suporte nativo ao ipv6 e procuro algo no ipv6.google.com usando o Mozilla Firefox. Seria criptografado?


16
O IPSec é como uma fechadura na porta; pode fazer parte da porta, mas não significa que a porta esteja necessariamente trancada.
Chris S

@ Chris S: Comentário impressionante, você tem meu voto positivo para isso.
precisa

Respostas:


31

Não.

O IPv6 possui o IPsec integrado como parte do protocolo, e não é um problema, como acontece com o IPv4. No entanto, isso não significa que está ativado por padrão, apenas significa que é uma sobrecarga (teoricamente) mais baixa na pilha de rede.

Geralmente, o uso de IPsec é determinado no nível IP da pilha de rede e, portanto, determinado pelas próprias políticas do sistema. por exemplo, o sistema A pode ter uma política que exija que o AH e o ESP tenham qualquer comunicação com a sub-rede 4.0.0.0/8.

Atualização: para ficar claro, o aplicativo não se importa - ele apenas sabe que precisa abrir uma conexão de rede em algum lugar e enviar / receber dados nela. O sistema precisa descobrir se o IPsec deve ser negociado para a conexão solicitada fornecida. O IPsec foi projetado para ser um mecanismo de autenticação / criptografia de baixo nível e foi criado propositadamente para que protocolos e aplicativos de nível superior não precisem se preocupar com isso.

Dito isso, é apenas mais um controle de segurança no nível da rede e não deve necessariamente ser usado isoladamente ou para garantir 'segurança' - se você estiver tentando resolver um problema de autenticação, é perfeitamente possível que você deseje o aplicativo para impor algum tipo de autenticação no nível do usuário, deixando a autenticação no nível da máquina para IPsec.


11
Obrigado por descartar claramente um mito horrivelmente popular.
Marcin

3
Oh, as coisas que poderiam ter sido. Talvez consigamos isso no IPv8 em algumas centenas de anos.
Michael Hampton

11
Discordo - a criptografia deve sempre ser possível e, na melhor das hipóteses, muito fácil. Exigir um certo tipo de controle de segurança, independentemente da existência de outros controles, é um pouco míope no que diz respeito aos casos de uso em que você não deseja ativamente a criptografia no nível de IP.
growse

20

Resposta curta: Não.

Resposta longa: o IPsec foi considerado ao projetar o IPv6, no sentido de que, diferentemente do IPv4, o IPsec (quando usado) faz parte do cabeçalho do IPv6.

Mais explicações: no IPv4, o IPsec é executado em cima do próprio IP. Na verdade, é um protocolo da Camada 4 que 'se disfarça' como um protocolo da Camada 3 (para que os protocolos L4 habituais do TCP e UDP ainda possam funcionar). O ESP (Encapsulating Security Payload) não pode se estender entre pacotes IP. Como resultado, os pacotes IPsec geralmente terão capacidade de carga útil bastante reduzida se a fragmentação for impedida. Além disso, como está no topo do IP, o cabeçalho do IP não está protegido.

No IPv6, o IPsec faz parte do próprio IP. Ele pode abranger pacotes, já que o cabeçalho ESP agora faz parte do cabeçalho do IP. E como é integrado ao IP, mais partes do cabeçalho IP podem ser protegidas.

Espero que minha explicação "em poucas palavras" seja suficientemente clara.


11
Na verdade, o AH assina o pacote inteiro , o que significa que nada pode ser alterado (ou seja, o NAT o interrompe.) É por isso que poucos túneis IPSec realmente usam o AH. E é um dos muitos cabeçalhos de extensão , não literalmente "parte do cabeçalho do IP".
21716 Ricky Beam

2

Para você Pergunta de acompanhamento:

O sistema operacional define quando usar a criptografia. Essas opções de "política" estão nos painéis de controle / políticas de configuração. Você diz coisas como "se você deseja se conectar a qualquer endereço na sub-rede ab12 :: você deve ter Blah1234 secreto". Existem opções para usar a PKI.

No momento, um aplicativo não pode adicionar a essa política ou exigir que ela seja configurada. Há uma menção na seção ipv6 do soquete do Linux ipv6 "O suporte IPSec para cabeçalhos EH e AH está ausente". Portanto, as pessoas pensaram nisso, mas atualmente não há implementações de trabalho conhecidas.


1

À sua pergunta de seguimento sim e não.

Os aplicativos podem especificar criptografia, mas a criptografia é feita no nível do aplicativo. Há uma grande variedade de pares de protocolos não criptografados / criptografados usando portas diferentes, como HTTP / HTTPS, LDAP / LDAPS, IMAP / IMAPS e SMTP / SSMTP. Todos eles usam criptografia SSL ou TLS. Alguns serviços oferecem uma opção startTLS que permite que uma conexão criptografada seja iniciada na porta normalmente não criptografada. O SSH é um aplicativo que sempre usa uma conexão criptografada. A criptografia é de ponta a ponta para esses casos. (Existe um algoritmo de criptografia NULL que pode ser usado e o conteúdo criptografado será transportado sem criptografia.)

O IPSEC é configurado pelo administrador e o aplicativo não saberá se a conexão está ou não criptografada. Vi principalmente o IPSEC usado para conectar o tráfego entre LANs através de conexões não seguras (conexões VPN). Eu acredito que o IPSEC pode se aplicar a apenas parte da rota, portanto, em alguns segmentos da rede, os dados são transmitidos de forma clara (sem criptografia).

Com uma opção, usarei a criptografia de aplicativo, pois a criptografia de rede não é muito usada.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.