TLS viaja dentro do canal de controle, não por todo o túnel

Ver a palavra TLS numa descrição de VPN e concluir que um proxy web vai compreender o tráfego é um atalho comum. Dentro deste protocolo os pares trocam os seus próprios pacotes, e o TLS corre como parte de um canal dentro dessa troca. A carga útil que interessa ao utilizador viaja num formato de mensagem diferente, e é por isso que os dois nunca coincidem com uma sessão HTTPS comum.

O envelope vem primeiro

Cada pacote do túnel começa com o cabeçalho do próprio protocolo: um tipo de mensagem, um identificador de chave e, sobre um transporte de fluxo de bytes, um prefixo de comprimento que marca onde o pacote termina. Um leitor que não analisa esse envelope não pode saber onde começa o campo seguinte.

outer transport (UDP datagram or TCP stream)
  -> OpenVPN header (opcode, key id, length where needed)
    -> control message (reliability wrapper, TLS exchange)
    -> data message (protected inner packet)

Esse esboço é um mapa e não uma tabela de bytes, porque os campos exatos dependem do tipo de mensagem, embora o primeiro octeto empacote sempre o opcode e o identificador de chave juntos. Adivinhar o tipo de mensagem pelo número da porta é como os descodificadores acabam a etiquetar mal o que veem. A ordem é o que importa para o diagnóstico: transporte, depois o envelope do protocolo, depois um de dois tipos de trabalho. Leia o envelope antes de formar qualquer opinião sobre o que vem a seguir. Um descodificador que começa no lugar errado produz disparates com muita confiança.

A camada de fiabilidade pertence ao protocolo

As mensagens de controle precisam de entrega ordenada e confirmada, e o protocolo providencia isso ele mesmo com confirmações e retransmissões. Uma confirmação pode chegar como mensagem própria ou viajar com outra mensagem de controle, o que faz as capturas parecerem irregulares a quem espera uma troca limpa.

A vantagem é que o handshake TLS recebe um portador fiável mesmo quando o transporte exterior é UDP. O custo é que um único datagrama pode conter apenas parte dessa conversa, pelo que tratá-lo como um registo TLS autónomo produz disparates. A remontagem tem de acontecer na camada do protocolo. É por isso que um pacote capturado raramente parece um passo completo do handshake.

Mudar o transporte exterior para TCP não elimina esta camada. Transporte fiável significa menos retransmissões ao nível do protocolo, não que o enquadramento desapareça ou que o tráfego se torne HTTP.

Os pacotes de dados usam um formato diferente

Assim que a sessão existe, a carga útil chega como mensagens de dados que transportam pacotes IP internos ou tramas Ethernet. Estão protegidos com as suas próprias chaves e o seu próprio processamento, e não são registos de aplicação TLS em nenhum sentido que uma biblioteca TLS aceitaria.

Essa separação é visível na configuração: o canal de controle e o canal de dados têm definições de cifra separadas, pelo que uma linha de registo que nomeia um não diz nada sobre o outro. Ler uma cifra de controle forte como prova de uma cifra de dados forte é um erro de relatório comum.

Mantenha também uma ideia errada relacionada fora da explicação. O TLS não é um canal de chave pública ao lado de um canal de dados simétrico, porque o próprio TLS protege os seus registos de forma simétrica assim que as chaves são estabelecidas. A verdadeira distinção é o papel e o formato do pacote, não o tipo de criptografia que cada lado usa.

Porque é que um proxy HTTPS não pode ajudar

Um proxy que termina TLS espera um fluxo de registos TLS e depois um protocolo de aplicação dentro dele. O canal de controle deste protocolo é transportado dentro do seu próprio enquadramento com uma camada de fiabilidade em volta, pelo que um proxy que termina lê esse enquadramento como entrada corrompida.

Um reencaminhador transparente que deixa passar bytes ou datagramas sem os interpretar pode funcionar, desde que não reescreva nem remonte o fluxo. A pergunta a fazer sobre qualquer intermediário é se reencaminha o transporte e o enquadramento reais, e não se suporta TLS em algum lugar. Faça essa pergunta antes de passar uma noite com regras de proxy. A maioria das falhas aqui é arquitetural e não uma definição em falta.

Ler uma captura corretamente

Espere primeiro uma troca de controle, depois um número muito maior de mensagens de dados, ambas a partilhar um transporte. Se a fase de controle termina e a fase de dados encrava, a falha diz respeito a chaves, encaminhamento ou filtragem do caminho de dados e não ao handshake. Capture algumas mensagens de dados e verifique se saem do cliente. Essa única observação divide a procura a meio.

As descrições históricas dos métodos de chave na documentação do protocolo não implicam que uma dada versão ainda suporte todos os formatos antigos. Verifique a versão que executa antes de construir uma expectativa sobre um parágrafo que descreve como as coisas funcionavam antigamente.