Un proxy HTTPS significa dúas conexións TLS, non unha

A etiqueta proxy HTTPS describe só o transporte entre o seu cliente e o proxy, e nada máis. Non di que o sitio web que hai detrás estea cifrado por esa mesma conexión, nin di que o proxy poida ler a páxina. Cando separa as dúas conexións, os erros de certificado deixan de ser misteriosos e a comparación cunha VPN vólvese concreta.

Dous pares de extremos, dúas verificacións

No modo túnel ordinario hai dúas relacións TLS. A primeira vai do seu cliente ao proxy e autentica o proxy. A segunda vai do seu cliente ao sitio web dentro do túnel e autentica o sitio web. Fallan de forma independente e configúranse de forma independente.

Teñen decisións de confianza separadas, cadeas de certificados separadas e mensaxes de fallo separadas. Un proxy cunha CA organizativa e un sitio web público cunha cadea pública poden necesitar lexitimamente unha configuración de verificación distinta, e iso non é unha mala configuración.

Tráteos como dúas conexións que comparten un socket, porque iso é o que son.

Que tuneliza realmente CONNECT

O cliente envía unha solicitude CONNECT co nome do host e o porto, e o proxy abre unha conexión TCP cara a ese destino. Despois de que o proxy responda, os bytes seguintes retransmítense sen interpretación, por iso o aperto de mans TLS do sitio web atravesa o proxy intacto. Así o proxy coñece o nome de destino e os metadatos da conexión, pero non recibe páxinas descifradas dese arranxo.

Esa distinción é todo o argumento de seguridade do modo túnel, e tamén é o seu límite.

Un proxy HTTP sen TLS no salto do proxy segue transportando un sitio HTTPS a través de CONNECT. O intercambio cliente-proxy vai en claro mentres que a conexión do sitio web non, e chamar a todo iso proxy HTTPS oculta esa diferenza.

Que certificado fallou

Cando a verificación falla, lea o extremo nomeado no erro antes de cambiar calquera axuste de confianza. Os dous fallos parécense nunha terminal e apuntan a correccións completamente distintas, por iso a primeira pregunta sempre é que conexión rexeitou.

curl separa as opcións exactamente por este motivo. O ficheiro CA do proxy configura a verificación do proxy, mentres que o ficheiro CA configura a verificación do servidor, e o comportamento do almacén de confianza aplicable tamén depende de como se compilou curl.

curl -v --proxy https://proxy.example.net:443 \
  --proxy-cacert org-ca.pem --cacert public-ca.pem https://www.example.com/

Suprimir unha comprobación non é unha reparación. Non demostra nada sobre ningún dos dous extremos.

A inspección é un arranxo distinto

A inspección TLS non é tunelización. Un intermediario inspector remata a relación de confianza cara ao sitio web e presenta o seu propio certificado ao cliente, así que o cliente verifica o intermediario e non o sitio. Iso pode ser lexítimo baixo un deseño aprobado, e é unha afirmación materialmente distinta da retransmisión byte a byte. Non supoña que todos os proxys inspeccionan, nin supoña que un salto de proxy cifrado o descarta.

Unha CA organizativa no seu almacén de confianza é unha pista sobre en que arranxo está, non unha proba. Pida o deseño en lugar de inferilo dunha cadea de certificados.

Eses dous arranxos dan respostas distintas á pregunta de quen pode ler a páxina.

Compare proxy e VPN nas mesmas catro liñas

A comparación só resulta útil cando ambos os despregamentos se describen do mesmo xeito.

Un proxy configurado para unha solicitude cobre esa solicitude. Non fai pasar cada proceso do dispositivo a través del, e o comando de exemplo é exactamente así de estreito. A cobertura dunha VPN depende do seu enrutamento e da súa política de aplicacións, que tamén hai que inspeccionar en lugar de supor. Ningunha das dúas opcións o cobre todo só porque se instalase.

Escriba as catro liñas para cada opción e o argumento adoita resolverse só. A comparación útil non é que etiqueta soa máis cifrada. É que segmentos están protexidos, quen se verifica nos seus extremos, en que intermediarios confía e que tráfico inclúe realmente a política.