Um proxy HTTPS significa duas conexões TLS, não uma
O salto do proxy e o site são relações TLS separadas com confiança separada. Leia qual extremo falhou antes de alterar qualquer configuração de certificado.
O rótulo proxy HTTPS descreve apenas o transporte entre seu cliente e o proxy, e nada mais. Ele não diz que o site por trás é criptografado por essa mesma conexão, nem diz que o proxy pode ler a página. Quando você separa as duas conexões, os erros de certificado deixam de ser misteriosos e a comparação com uma VPN fica concreta.
Dois pares de extremos, duas verificações
No modo túnel comum existem duas relações TLS. A primeira vai do seu cliente ao proxy e autentica o proxy. A segunda vai do seu cliente ao site dentro do túnel e autentica o site. Elas falham de forma independente e são configuradas de forma independente.
Elas têm decisões de confiança separadas, cadeias de certificados separadas e mensagens de falha separadas. Um proxy com uma CA organizacional e um site público com uma cadeia pública podem legitimamente precisar de uma configuração de verificação diferente, e isso não é uma configuração errada.
Trate-os como duas conexões que por acaso compartilham um socket, porque é isso que são.
O que o CONNECT realmente tuneliza
O cliente envia uma solicitação CONNECT nomeando o host e a porta, e o proxy abre uma conexão TCP para esse destino. Depois que o proxy responde, os bytes seguintes são repassados sem interpretação, e é por isso que o handshake TLS do site atravessa o proxy intacto. O proxy assim aprende o nome de destino e os metadados da conexão, e não recebe páginas descriptografadas desse arranjo.
Essa distinção é todo o argumento de segurança do modo túnel, e também é o seu limite.
Um proxy HTTP sem TLS no salto do proxy ainda transporta um site HTTPS através do CONNECT. A troca entre cliente e proxy é em texto claro enquanto a conexão do site não é, e chamar tudo isso de proxy HTTPS esconde essa diferença.
Qual certificado falhou
Quando a verificação falha, leia o extremo nomeado no erro antes de alterar qualquer configuração de confiança. As duas falhas parecem semelhantes em um terminal e apontam para correções completamente diferentes, por isso a primeira pergunta é sempre qual conexão recusou.
O curl separa as opções exatamente por esse motivo. O arquivo CA do proxy configura a verificação do proxy, enquanto o arquivo CA configura a verificação do servidor, e o comportamento do armazenamento de confiança aplicável também depende de como o curl foi compilado.
curl -v --proxy https://proxy.example.net:443 \
--proxy-cacert org-ca.pem --cacert public-ca.pem https://www.example.com/Suprimir uma verificação não é um reparo. Não estabelece nada sobre nenhum dos dois extremos.
A inspeção é um arranjo diferente
A inspeção TLS não é tunelamento. Um intermediário inspetor encerra a relação de confiança com o site e apresenta seu próprio certificado ao cliente, então o cliente verifica o intermediário e não o site. Isso pode ser legítimo sob um projeto aprovado, e é uma afirmação materialmente diferente do repasse byte a byte. Não presuma que todo proxy inspeciona, nem presuma que um salto de proxy criptografado exclui isso.
Uma CA organizacional no seu armazenamento de confiança é uma pista sobre em qual arranjo você está, não uma prova. Peça o projeto em vez de inferi-lo de uma cadeia de certificados.
Esses dois arranjos dão respostas diferentes à pergunta sobre quem pode ler a página.
Compare proxy e VPN nas mesmas quatro linhas
A comparação só se torna útil quando as duas implantações são descritas do mesmo modo.
| Line | What to state |
|---|---|
| Protected segments | Which hops are encrypted, and between which endpoints |
| Verified identities | What each end proves, and against which trust anchor |
| Trusted intermediaries | Who can read or alter traffic by design |
| Traffic included | Which processes and destinations the policy actually covers |
Um proxy configurado para uma solicitação cobre essa solicitação. Ele não faz cada processo do dispositivo passar por ele, e o comando de exemplo é exatamente tão estreito. A cobertura de uma VPN depende do seu roteamento e da sua política de aplicativos, que também precisam ser inspecionados em vez de presumidos. Nenhuma das opções cobre tudo só porque foi instalada.
Escreva as quatro linhas para cada opção e o argumento geralmente se resolve sozinho. A comparação útil não é qual rótulo soa mais criptografado. É quais segmentos estão protegidos, quem é verificado nas suas pontas, em quais intermediários você confia e qual tráfego a política realmente inclui.