Luego de tanto trabajar hemos dado con la solución de esta cuestión que agunos usuarios de nuestro espacio tienen. Si quieres compartir algún dato no dudes en dejar tu comentario.
Solución:
¿Cómo funciona HTTPS?
HTTPS se basa en publico privado-key criptografía. Esto básicamente significa que hay una key par: El publico key se utiliza para el cifrado y el secreto privado key es necesario para el descifrado.
A certificado es básicamente un público key 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 solicitó el usuario.
- 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 el público key y lo utiliza para cifrar cierta información antes de enviarla al servidor. El servidor puede descifrarlo porque el el servidor tiene el privado correspondiente key.
¿Cómo evita HTTPS los ataques de hombre en el medio?
En este caso, ¿podrá G obtener el certificado que A obtuvo anteriormente de W?
Sí, el certificado es público. key con la etiqueta. El servidor web lo enviará a cualquiera que se conecte a él.
Si G puede obtener el certificado, ¿significa eso que G podrá descifrar los datos?
No. El certificado contiene el público key del servidor web. El proxy malintencionado no está en posesión de la propiedad privada coincidente. key. Entonces, si el proxy reenvía el certificado real al cliente, no puede descifrar la información que el cliente envía al servidor web.
El servidor proxy puede intentar falsificar el certificado y proporcionar su propio key en lugar de. Esto, sin embargo, destruir la firma de las autoridades de certificación. El navegador advertirá sobre el certificado no válido.
¿Existe alguna forma de que un servidor proxy pueda leer HTTPS?
Si el el administrador de su computadora coopera, es posible que un servidor proxy rastree las conexiones https. Esto se usa en algunas empresas para buscar virus y hacer cumplir las pautas de uso aceptable.
A autoridad de certificación local está configurado y el administrador le dice a su navegador que este CA es confiable. El servidor proxy utiliza esta CA para firmar sus certificados falsificados.
Ah, y por supuesto, los usuarios tienden a hacer clic en las advertencias de seguridad.
Suponiendo que los usuarios no hagan clic en las advertencias de certificados (y asumiendo que está ejecutando un cliente sin modificar), la respuesta es: No, el proxy no puede descifrar los datos..
Para obtener una explicación detallada de cómo HTTPS evita que un intermediario descifre su tráfico, consulte cualquier recurso estándar sobre SSL / TLS, por ejemplo,
-
¿Cómo es posible que las personas que observan el establecimiento de una conexión HTTPS no sepan cómo descifrarla?
-
Página de Wikipedia sobre TLS
PD: El certificado es un dato público. Contiene el público del servidor. key y 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).
Del blog de tecnología de Philipp C. Heckel con algunas ediciones ligeras:
Si bien se puede atacar el tráfico HTTP no cifrado sin tener que lidiar con certificados X.509 y autoridades de certificación (CA), las conexiones HTTPS cifradas con SSL cifran todas las solicitudes y respuestas entre el cliente y el servidor de un extremo a otro. Y debido a que 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 verificando dos condiciones: Primero, verifica si su certificado fue firmado por una CA conocida por el cliente. Y en segundo lugar, 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 true, 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 https://www.facebook.com, el proxy genera un certificado para “www.facebook.com” y lo firma con su propia CA. Siempre que el cliente confíe en esta CA, ambas condiciones mencionadas anteriormente son true (CA de confianza, mismo 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.
Para que este ataque funcione, se deben cumplir algunas condiciones:
- Servidor proxy como puerta de enlace estándar (HTTP y HTTPS): Para el proxy HTTP y HTTPS, el servidor proxy debe, por supuesto, poder interceptar los paquetes IP, lo que significa que debe estar en algún lugar a lo largo de la ruta del paquete. La forma más sencilla de lograrlo es cambiar la puerta de enlace predeterminada en el dispositivo cliente a la dirección del servidor proxy.
- CA de proxy de confianza (solo HTTPS): Para que funcione el proxy HTTPS, el cliente debe conocer (¡y confiar!) La CA del proxy, es decir, la CA key El archivo debe agregarse al almacén de confianza del cliente.
Si está interesado en detectar de forma transparente sockets SSL simples, puede intentar
SSLsplit, un proxy de intermediario TLS / SSL transparente. Hay muchas formas de atacar SSL, pero no necesita certificados SSL falsos, una Autoridad de Certificación (CA) deshonesta o variaciones de los ataques SSL de intermediario del experto en seguridad Moxie Marlinspike. ¿Por qué tomarse tantas molestias cuando puede comprar un proxy de interceptación SSL, como ProxySG de Blue Coat Systems o su dispositivo SSL Netronome recientemente adquirido para hacer el trabajo por usted?
De Steven J. Vaughan-Nichols en ZDNet (extraído):
Blue Coat, el nombre más importante en el negocio de la interceptación SSL, está lejos de ser el único que ofrece interceptación SSL y rompimiento 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 interceptación SSL en su lugar, esto es lo que realmente sucede:
Si su empresa ha configurado el proxy correctamente, no sabrá que nada está mal porque habrán acordado que el certificado SSL interno del proxy se registre en su máquina como un certificado válido. De lo contrario, recibirá un mensaje de error emergente que, si hace clic en para continuar, aceptará el certificado digital “falso”. En cualquier caso, obtiene una conexión segura al proxy, obtiene una conexión segura al sitio externo, y todo lo que se envía a través del proxy se puede leer en texto sin formato. ¡Ups!
