A cifra do túnel WSS termina no terminador TLS, não no aplicativo

Um túnel transportado dentro de um WebSocket seguro tem exatamente a cifra que o cliente colocou nele, nem mais. O esquema wss:// diz que o TLS protege uma conexão em um salto. Não diz nada sobre se os bytes dentro das mensagens WebSocket são protegidos separadamente, e essa distinção decide quem pode ler o seu tráfego quando algo no meio termina o TLS.

Duas camadas que parecem uma só

Um WebSocket seguro é TLS com um aperto de mão WebSocket executado por cima, como descreve RFC 6455 nas suas seções de conexão e segurança. A camada TLS autentica o servidor e cifra o fluxo, e então a camada WebSocket enquadra o que a aplicação decidir enviar.

São duas decisões independentes, e um diagrama que desenha um único cadeado sobre todo o caminho esconde a segunda. Pergunte quem termina a conexão TLS. Depois pergunte o que o cliente coloca dentro de cada mensagem. Tudo o mais sobre a implantação decorre dessas duas respostas.

Desenho A: o transporte é a única cifra

No desenho mais simples, o cliente pega em pacotes IP crus e embrulha-os em mensagens WebSocket. Nada lá dentro é cifrado, então o componente que detém a sessão TLS lê cargas em texto simples. Quando esse componente é o seu próprio servidor de túnel, este é o ponto final previsto e o desenho é coerente, porque o servidor iria sempre ver o tráfego.

Torna-se outra disposição quando um proxy de inspeção fica no caminho e termina o TLS com um certificado em que o cliente confia. Esse proxy detém agora o mesmo texto simples que o servidor teria, e nenhuma quantidade de enquadramento WebSocket muda isso. O armazenamento de confiança do cliente decidiu este resultado muito antes de o túnel abrir, porque escolheu aceitar esse certificado para esse nome. O proxy também vê o anfitrião pedido e o tamanho de cada mensagem, o que basta para tirar a impressão digital de muita atividade sem decifrar mais nada.

Desenho B: a carga transporta as suas próprias chaves

No segundo desenho, o cliente cifra e autentica os seus pacotes com um protocolo VPN que tem a sua própria identidade de par e troca de chaves, e depois transporta o resultado dentro de mensagens WebSocket. Terminar o TLS exterior aqui expõe texto cifrado, não tráfego. O proxy pode ver tamanhos e tempos das mensagens, e nada mais na carga. É uma exposição muito menor, e ainda assim são metadados que vale a pena nomear numa revisão em vez de descartar.

Os próprios pontos finais do protocolo interior continuam a ver texto simples, o que é o sentido da disposição e também o seu limite. Se um componente no ponto final está autorizado a ler dados antes da cifra ou depois da decifração, a camada extra não o restringe. As chaves, e o software que as trata, continuam a ser a fronteira que importa.

Um rótulo VPN, um ícone de cliente familiar ou uma página de marketing não são prova de que este desenho exista. Ler o formato da carga é.

Rastreie onde o texto simples aparece de facto

O esquema do URL dá-lhe um facto, por isso obtenha o resto a partir das interfaces. Execute as verificações abaixo por ordem, porque cada uma estreita a seguinte:

ss -tnp | grep -E ':(443|8443)\b'
ip -br link show type tun
openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief
tcpdump -ni tun0 -c 5 -X

Comece pela conexão exterior. Uma sessão TCP de longa duração para a porta TLS é o aspeto de um portador WebSocket, e uma segunda sessão para um anfitrião não relacionado merece explicação antes de olhar mais fundo. Depois encontre a interface de túnel no cliente, porque um dispositivo tun ou tap diz-lhe que o cliente trata pacotes IP em vez de fazer proxy de um único fluxo de aplicação.

A captura na interface de túnel costuma resolver a questão da carga. Cabeçalhos legíveis ali significam que os pacotes interiores nunca foram cifrados separadamente, enquanto cargas de alta entropia significam que foram. Repita a captura na interface exterior e compare as duas: se ambas parecerem aleatórias, a camada interior faz trabalho que a exterior não pode desfazer.

Reveja a confiança que realmente concedeu

Um certificado de raiz corporativo instalado é um facto sobre o armazenamento de confiança do cliente, não uma afirmação sobre o que qualquer proxy registra ou inspeciona. Estabeleça a política implementada e o caminho de conexão real em vez de inferir comportamento da presença de uma CA.

Em equipamento gerido, pergunte ao administrador que componente termina o TLS, se o cliente valida um certificado fixado ou um público, e qual é o formato da carga. Essas três respostas produzem uma conclusão que poderá defender mais tarde.

Escreva o resultado como uma fronteira e não como um veredicto. "O TLS termina no proxy de inspeção, e a carga interior é cifrada separadamente com chaves que só os pontos finais têm" é uma afirmação verificável que sobrevive a uma mudança de fornecedor. "Os WebSockets são seguros" não.