HTTPS Basic Auth vs IPsec: o que cada um protege

Abra as ferramentas de programador, carregue a aplicação interna e veja um pedido passar por quatro pontos de controlo antes de a página ser renderizada. Primeiro o nome é resolvido, depois abre-se uma ligação TCP, depois um handshake TLS estabelece quem é o servidor, e só então a aplicação pergunta quem é você. Trate esses eventos como separados, porque cada um falha com evidência diferente e cada um pertence a uma equipa diferente. A maior parte da confusão em incidentes vem de ler um 401 como problema de túnel, ou um problema de túnel como palavra-passe errada.

Ponto de controlo um: é este o servidor com quem queria falar

O handshake TLS responde a essa pergunta antes de qualquer credencial ser enviada. O seu cliente valida a cadeia de certificados contra um armazém de confiança e verifica se o nome no certificado corresponde ao anfitrião que escreveu. Se isso falhar, o navegador mostra um erro de certificado e nunca envia o cabeçalho Authorization. Um pedido de palavra-passe não é, portanto, prova de que o servidor é genuíno; é prova de que a aplicação respondeu.

Aqui aparece a primeira fronteira. O TLS protege a ligação até ao seu ponto de terminação. Se um balanceador de carga terminar o TLS e encaminhar HTTP simples para a aplicação, o segmento cifrado termina no balanceador, e as credenciais só estão protegidas nesse primeiro salto.

Ponto de controlo dois: o que viaja de facto numa troca 401

A autenticação HTTP Basic envia o identificador de utilizador e a palavra-passe num cabeçalho, codificados em Base64 como descrito no RFC 7617. Authorization: Basic dXNlcjpwYXNz é a forma; a codificação é reversível por qualquer pessoa que consiga ler o pedido, por isso todo o sigilo vem do transporte por baixo. curl -v mostra tanto o desafio WWW-Authenticate: Basic como o cabeçalho que devolve.

Esse cabeçalho diz à aplicação quem está a pedir. Não diz à rede quem pode ligar-se, e não cifra nada por si só. A aplicação ainda tem de verificar a credencial contra um armazém e decidir o que essa conta pode fazer, o que é autorização e acontece depois da autenticação.

Onde fica o túnel IPsec nesse caminho

Agora caminhe para fora a partir do navegador. Um túnel IPsec entre gateways protege tráfego selecionado entre dois gateways de segurança, não entre o seu portátil e o processo da aplicação. O ESP em modo túnel envolve o pacote original, os gateways cifram-no e autenticam-no, e os endereços internos sobrevivem para que o lado oposto possa encaminhar o pedido para a aplicação.

A seleção é a parte que derruba as pessoas. Túneis baseados em política usam seletores de tráfego, muitas vezes expressos como listas de controlo de acesso, para decidir que pacotes entram no túnel. Túneis baseados em rotas usam, em vez disso, uma interface virtual e a tabela de rotas. No Linux, ip xfrm policy mostra os seletores e ip xfrm state as associações de segurança estabelecidas; num equipamento de firewall o equivalente é a tabela SA do túnel mais um rastreador de pacotes.

A consequência merece ser dita sem rodeios. Um pacote pode estar dentro de um túnel perfeitamente saudável e ainda assim transportar um pedido HTTPS que a aplicação rejeita, e credenciais válidas podem chegar por um caminho sem qualquer túnel se o encaminhamento o permitir.

Leia a falha na camada que a reportou

Um 401 significa que a aplicação não aceitou a credencial. Um 403 significa que aceitou a identidade e recusou a operação. Um erro TLS significa que o cliente não aceitou o servidor. Sem rota ou uma incompatibilidade de política significa que o pacote nunca chegou ao gateway do outro lado. Quatro falhas diferentes, quatro responsáveis diferentes, e nenhuma delas é diagnosticada a olhar para o formulário de início de sessão.

Use a evidência que cada camada produz: o painel de rede do navegador para estado e cabeçalhos, openssl s_client -connect host:443 para a cadeia de certificados, os contadores SA e registos do gateway para tráfego de túnel, e o registo da aplicação para a decisão da conta. Quando duas camadas reportam erros ao mesmo tempo, corrija primeiro a mais baixa, porque um túnel morto mascara facilmente uma falha de autenticação e vice-versa.

Mapeie um serviço de ponta a ponta

Escreva cinco linhas para o serviço que está a diagnosticar: que pares o túnel liga, que sub-redes e portas os seletores permitem, onde o TLS termina e que identidade o certificado afirma, que conta e papel da aplicação são usados, e onde cada camada regista. Mantenha-as numa página, porque o objetivo do mapa é mostrar onde termina a responsabilidade de uma camada e começa a seguinte.

Depois teste um caso negativo por camada. Use uma palavra-passe errada e confirme que recebe um 401, não um tempo esgotado. Ligue-se de uma sub-rede fora dos seletores e confirme que o pacote não é tunelado. Apresente um certificado para o nome errado e confirme que o cliente recusa antes de enviar credenciais. Esses três resultados dizem-lhe mais sobre o desenho do que qualquer diagrama de caixas.

Por fim, decida deliberadamente que proteção cada relação precisa. A autenticação Basic sobre TLS é uma escolha razoável para uma pequena ferramenta interna atrás de um gateway; não substitui a autorização por utilizador nem a proteção do tráfego para além do ponto de terminação TLS. O túnel protege o caminho, o certificado protege o salto e o 401 protege a conta, e só o último sabe quem você é.