Un proxy HTTPS significa dos conexiones TLS, no una
El salto del proxy y el sitio web son relaciones TLS separadas con confianzas separadas. Lea qué extremo falló antes de cambiar cualquier ajuste de certificado.
La etiqueta proxy HTTPS describe solo el transporte entre su cliente y el proxy, y nada más. No dice que el sitio web que hay detrás esté cifrado por esa misma conexión, ni dice que el proxy pueda leer la página. Cuando separa las dos conexiones, los errores de certificado dejan de ser misteriosos y la comparación con una VPN se vuelve concreta.
Dos pares de extremos, dos verificaciones
En el modo túnel ordinario hay dos relaciones TLS. La primera va de su cliente al proxy y autentica el proxy. La segunda va de su cliente al sitio web dentro del túnel y autentica el sitio web. Fallan de forma independiente y se configuran de forma independiente.
Tienen decisiones de confianza separadas, cadenas de certificados separadas y mensajes de fallo separados. Un proxy con una CA organizativa y un sitio web público con una cadena pública pueden necesitar legítimamente una configuración de verificación distinta, y eso no es una mala configuración.
Trátelos como dos conexiones que comparten un socket, porque eso es lo que son.
Qué tuneliza realmente CONNECT
El cliente envía una solicitud CONNECT con el nombre del host y el puerto, y el proxy abre una conexión TCP hacia ese destino. Después de que el proxy responde, los bytes siguientes se retransmiten sin interpretación, por eso el apretón de manos TLS del sitio web atraviesa el proxy intacto. Así el proxy conoce el nombre de destino y los metadatos de la conexión, pero no recibe páginas descifradas de ese arreglo.
Esa distinción es todo el argumento de seguridad del modo túnel, y también es su límite.
Un proxy HTTP sin TLS en el salto del proxy sigue transportando un sitio HTTPS a través de CONNECT. El intercambio cliente-proxy va en claro mientras que la conexión del sitio web no, y llamar a todo eso proxy HTTPS oculta esa diferencia.
Qué certificado falló
Cuando la verificación falla, lea el extremo nombrado en el error antes de cambiar cualquier ajuste de confianza. Los dos fallos se parecen en una terminal y apuntan a correcciones completamente distintas, por eso la primera pregunta siempre es qué conexión rechazó.
curl separa las opciones exactamente por este motivo. El archivo CA del proxy configura la verificación del proxy, mientras que el archivo CA configura la verificación del servidor, y el comportamiento del almacén de confianza aplicable también depende de cómo se compiló curl.
curl -v --proxy https://proxy.example.net:443 \
--proxy-cacert org-ca.pem --cacert public-ca.pem https://www.example.com/Suprimir una comprobación no es una reparación. No demuestra nada sobre ninguno de los dos extremos.
La inspección es un arreglo distinto
La inspección TLS no es tunelización. Un intermediario inspector termina la relación de confianza hacia el sitio web y presenta su propio certificado al cliente, así que el cliente verifica al intermediario y no al sitio. Eso puede ser legítimo bajo un diseño aprobado, y es una afirmación materialmente distinta de la retransmisión byte a byte. No suponga que todos los proxys inspeccionan, ni suponga que un salto de proxy cifrado lo descarta.
Una CA organizativa en su almacén de confianza es una pista sobre en qué arreglo está, no una prueba. Pida el diseño en lugar de inferirlo de una cadena de certificados.
Esos dos arreglos dan respuestas distintas a la pregunta de quién puede leer la página.
Compare proxy y VPN en las mismas cuatro líneas
La comparación solo resulta útil cuando ambos despliegues se describen del mismo 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 |
Un proxy configurado para una solicitud cubre esa solicitud. No hace pasar cada proceso del dispositivo a través de él, y el comando de ejemplo es exactamente así de estrecho. La cobertura de una VPN depende de su enrutamiento y de su política de aplicaciones, que también hay que inspeccionar en lugar de suponer. Ninguna de las dos opciones lo cubre todo solo porque se haya instalado.
Escriba las cuatro líneas para cada opción y el argumento suele resolverse solo. La comparación útil no es qué etiqueta suena más cifrada. Es qué segmentos están protegidos, quién se verifica en sus extremos, en qué intermediarios confía y qué tráfico incluye realmente la política.