¿Previene https el ataque en el medio del servidor proxy?

¿Cómo funciona HTTPS?

HTTPS se basa en criptografía de clave pública / privada . Básicamente, esto significa que hay un par de claves: la clave pública se usa para el cifrado y la clave privada secreta se requiere para el descifrado.

Un certificado es básicamente una clave pública con una etiqueta que identifica al propietario.

Entonces, cuando su navegador se conecte a un servidor HTTPS, el servidor responderá con su certificado. El navegador comprueba si el certificado es válido :

• la información del propietario debe coincidir con el nombre del servidor que el usuario solicitó.
• el certificado debe estar firmado por una autoridad de certificación confiable.

Si no se cumple una de estas condiciones, se informa al usuario sobre el problema.

Después de la verificación, el navegador extrae la clave pública y la utiliza para cifrar cierta información antes de enviarla al servidor. El servidor puede descifrarlo porque el servidor tiene la clave privada correspondiente .

¿Cómo previene HTTPS al hombre en los ataques medios?

  

En este caso, ¿G podrá obtener el certificado que A obtuvo previamente de W?

Sí, el certificado es la clave pública con la etiqueta. El servidor web lo enviará a cualquier persona que se conecte a él.

  

Si G puede obtener el certificado, ¿eso significa que G podrá descifrar los datos?

No. El certificado contiene la clave pública del servidor web . El proxy malicioso no está en posesión de la clave privada correspondiente. Entonces, si el proxy reenvía el certificado real al cliente, no podrá descifrar la información que el cliente envía al servidor web.

El servidor proxy puede intentar falsificar el certificado y proporcionar su propia clave pública. Sin embargo, esto destruirá la firma de las autoridades de certificación . El navegador advertirá sobre el certificado inválido.

¿Hay alguna forma en que un servidor proxy pueda leer HTTPS?

Si el administrador de su computadora coopera , es posible que un servidor proxy pueda detectar conexiones https. Esto se usa en algunas compañías para buscar virus y hacer cumplir las pautas de uso aceptable.

Una autoridad de certificación local está configurada y el administrador le dice a su navegador que esta CA es confiable . El servidor proxy utiliza esta CA para firmar sus certificados falsificados.

Ah, y por supuesto, el usuario tiende a eliminar las advertencias de seguridad.

Suponiendo que los usuarios no hagan clic en las advertencias de cert (y suponiendo que está ejecutando un cliente no modificado), la respuesta es: No, el proxy no puede descifrar los datos .

Para obtener una explicación detallada de cómo HTTPS evita que un usuario intermedio descifre su tráfico, consulte cualquier recurso estándar en SSL / TLS, por ejemplo,

• ¿Cómo es posible que las personas que observan que se está estableciendo una conexión HTTPS no sabrían cómo descifrarla?

• página de Wikipedia en TLS

P.S. El certificado es de datos públicos. Contiene la clave pública del servidor y el nombre de dominio, ninguno de los cuales es secreto. Observar el certificado no ayuda al atacante a descifrar los datos. (Sí, el proxy puede observar el certificado, pero esto es inofensivo).

De Blog de tecnología de Philipp C. Heckel con algunas ediciones ligeras:

  

Mientras se puede atacar el tráfico HTTP no cifrado sin tener que lidiar con los certificados X.509 y las autoridades de certificación (CA), las conexiones HTTPS cifradas con SSL cifran cada solicitud y respuesta entre el cliente y el servidor de extremo a extremo. Y como los datos transferidos están encriptados con un secreto compartido, un intermediario (o un proxy) no puede descifrar los paquetes de datos intercambiados. Cuando el cliente abre una conexión SSL / TLS al servidor web seguro, verifica la identidad del servidor al verificar dos condiciones: Primero, verifica si su certificado fue firmado por una CA conocida por el cliente. Y segundo, se asegura de que el nombre común (CN, también: nombre de host) del servidor coincida con el que se conecta. Si ambas condiciones son verdaderas, el cliente asume que la conexión es segura.

     

Para poder rastrear la conexión, el servidor proxy puede actuar como una autoridad de certificación, sin embargo, no es muy confiable: en lugar de emitir certificados a personas u organizaciones reales, el proxy genera certificados dinámicamente para cualquier nombre de host que se necesite. para una conexión. Si, por ejemplo, un cliente desea conectarse a enlace , el proxy genera un certificado para "www.facebook.com" y lo firma con su propio CA. Siempre que el cliente confíe en esta CA, ambas condiciones mencionadas anteriormente son verdaderas (CA de confianza, misma CN), lo que significa que el cliente cree que el servidor proxy es de hecho "www.facebook.com". La siguiente figura muestra el flujo de solicitud / respuesta para este escenario. Este mecanismo se denomina proxy HTTPS transparente.

     

    

Paraqueesteataquefuncione,hayalgunascondicionesquedebencumplirse:

    

• Servidorproxycomopuertadeenlaceestándar(HTTPyHTTPS):tantoparaelproxyHTTPcomoparaelHTTPS,elservidorproxydebepoder,porsupuesto,interceptarlospaquetesIP,loquesignificaquedebeestarenalgúnlugarenelcaminodelrutadelpaquete.Laformamássencilladelograrestoescambiarlapuertadeenlacepredeterminadaeneldispositivoclientealadireccióndelservidorproxy.
  
• CAdeproxydeconfianza(soloHTTPS):paraqueelproxydeHTTPSfuncione,elclientedebeconocer(yconfiar)laCAdeproxy,esdecir,elarchivodeclavedelaCAdebeagregarsealalmacéndeconfianzadelcliente.
  

     

Si está interesado en rastrear de manera transparente sockets SSL sin formato, es posible que desee probar SSLsplit , un proxy de hombre en el medio TLS / SSL transparente. Hay muchas formas de atacar SSL, pero no necesita certificados SSL falsos, una Autoridad de Certificación (CA) fraudulenta o variaciones en los ataques SSL de hombre en el medio de la experta en seguridad Moxie Marlinspike. ¿Por qué afrontar todos esos problemas cuando solo puede comprar un proxy de intercepción SSL, como el ProxySG de Blue Coat Systems o su dispositivo Netronome SSL recientemente adquirido para hacer el trabajo por usted?

De Steven J. Vaughan- Nichols en ZDNet (extraído):

  

Blue Coat, el nombre más grande en el negocio de la intercepción de SSL, está lejos de ser el único que ofrece intercepción de SSL y rompe en una caja. Hasta hace poco, por ejemplo, Microsoft le vendería un programa, Forefront Threat Management Gateway 2010, que también podría hacer el trabajo por usted. Con un programa o dispositivo proxy de intercepción SSL instalado, esto es lo que realmente sucede:

     

    

Sisuempresahaconfiguradoelproxycorrectamente,nosabráquenadaestádeshabilitadoporquehabrádispuestoqueelcertificadoSSLinternodelproxyestéregistradoensumáquinacomouncertificadoválido.Delocontrario,recibiráunmensajedeerroremergenteque,sihaceclicenparacontinuar,aceptaráelcertificadodigital"falso". En cualquier caso, obtiene una conexión segura con el proxy, obtiene una conexión segura con el sitio externo, y todo lo que se envía a través del proxy se puede leer en texto sin formato. Whoops.

Dependiendo de la configuración de la red en la que esté, es posible que los administradores vean el contenido de las conexiones HTTPS (y posiblemente de las VPN).

Obviamente, es posible interceptar el tráfico en la red, pero el problema habitual es que no pueden emitir certificados válidos para todos los sitios que visita, por lo que verá muchas advertencias de certificados cada vez que acceda a un HTTPS sitio, si intentan descifrar el tráfico para verlo.

Sin embargo, si está utilizando una máquina proporcionada por la empresa, podrían instalar una nueva Autoridad de certificación y luego usarla para crear certificados SSL para los sitios que visite, por lo que no aparecería como un problema.

Con el lado VPN de las cosas, podría ser más complejo si la VPN no usa SSL, pero se aplica la misma teoría. Si accede a Internet desde una máquina que pertenece a otra persona en una red que controlan, es probable que puedan acceder a cualquier contenido que ingrese.

Si busca evitar este tipo de problema, usaría un dispositivo que posee / controla para acceder a Internet, de esa forma debería recibir una advertencia si se produce alguna intercepción de SSL.

Correcto, los administradores de la red corporativa implementan un ataque de intermediario contra el cliente TLS con su propia CA para que puedan ver lo que está saliendo de su red. Probablemente tendrán un dispositivo que creará un certificado sobre la marcha que es válido para gmail.com cuando visite gmail.com. La razón por la que hacen esto no es para jugar contra el Dr. Evil, sino para evitar que los secretos comerciales sean expulsados de su edificio a través de su conexión a Internet. En serio, no haga su banca privada en una computadora de trabajo.

Si usa un producto de software que no usa el almacén de certificados del sistema (por ejemplo, una instancia de OpenVPN), entonces, no, no pueden interceptar ni decodificar su tráfico porque no confía en su CA. Puede lograr el mismo resultado utilizando una aplicación portátil de Firefox, por ejemplo. Y en la mayoría de los navegadores, puede verificar los detalles de su conexión segura y ver quién es la AC para asegurarse de quién está escuchando o no.

El proxy puede bloquear https y solo permitir http desde el navegador. Luego puede iniciar su propia conexión https para pasar las solicitudes al servidor.

La mayoría de los usuarios no se darán cuenta.

Se supone que HSTS debe detener esto, pero no se usa ampliamente.

Los productos de terminación SSL o proxy SSL como Bluecoat deben estar en su red y considerando el costo, los procedimientos de instalación involucrados y la política de seguridad normal que tendría cualquier organización que instale estos productos: las amenazas de un atacante malintencionado utilizando un SSL comercial producto de terminación es casi cero. OTOH: un experto de confianza con acceso al NOC (centro de operaciones de red) podría, de hecho, monitorear el tráfico terminado en SSL y revelar información confidencial.

Esta es una preocupación común (justificada o no) para las compañías que implementan sistemas DLP.

SIN EMBARGO, DICHO TODO LO QUE HAY - hay otro vector de ataque que es común en el espacio de la banca doméstica que no requiere un proxy de red y tiene ataques piggback / shim en el navegador - ya que el DOM tiene acceso para despejar el tráfico de texto antes llega a la tubería SSL: este es un vector de ataque conveniente y, a menudo, se instala a través de una extensión del navegador. Hay un excelente artículo de Stackexchange sobre shims - ¿Se puede instalar un shim (también conocido como polyfill) en IE, FF o Chrome sin el conocimiento del usuario, y puede leer las contraseñas ingresadas por el usuario en una página de inicio de sesión?