¿El cifrado en HTTPS lo realiza el navegador o el sistema?

La 'S' en HTTPS significa 'seguro' (Protocolo de transferencia de hipertexto seguro) Es un protocolo de comunicación para comunicación segura que hace uso de Transport Layer Security (TLS) y su predecesora, Secure Sockets Layer (SSL).

TLS / SSL se inicializa en la capa 5 ( la capa de sesión ) luego funciona en la capa 6 ( la capa de presentación ). La mayoría de las aplicaciones, como navegadores web, clientes de correo electrónico o mensajería instantánea incorporan la funcionalidad de las capas OSI 5, 6 y 7.

Al referirse a HTTPS será una implementación de SSL / TLS en el contexto del protocolo HTTP. SSL / TLS se implementará en los navegadores (y servidor web) para proporcionar confidencialidad e integridad para el tráfico HTTPS ( encriptación real de los datos).

Chromium y Firefox utilizan una API llamada NSS para implementar SSL / TLS en sus respectivos navegadores.

Microsoft Windows, por ejemplo, tiene un paquete de seguridad llamado SChannel (canal seguro) que implementa SSL / TLS para proporcionar autenticación entre clientes y servidores. Schannel, por ejemplo, está siendo utilizado por los clientes / servidores de Microsoft Windows en un entorno de Active Directory.

En cuanto al proxy y la manipulación de los datos, depende del protocolo con el que esté trabajando. Un buen ejemplo para familiarizarse con un contexto HTTP (S) es echar un vistazo a Problema de Burp .

Hay muchas buenas respuestas aquí sobre cómo el navegador maneja el HTTPS, pero no estoy seguro de que se haya respondido a su pregunta real .

  

¿Se pueden manipular esos datos con éxito a través de un proxy (en el mismo sistema, no en la red)?

Aquí la respuesta es yes . Esto podría suceder de una de las dos maneras:

• El propio navegador está comprometido por un complemento, extensión o actualización maliciosos.
• El sistema está comprometido con el malware que ha modificado los certificados de raíz de confianza utilizados por el navegador (que pueden ser o no los mismos que utiliza el sistema operativo).

La respuesta es ... posiblemente .

Si especifica https:// , entonces el navegador se responsabiliza del cifrado. Algunos navegadores utilizan las API proporcionadas por el SO (mirando IE aquí), mientras que otros (por ejemplo, Firefox) llevan su propio criptográfico e ignoran completamente el criptográfico proporcionado por el SO.

La PKI garantiza la resistencia a la manipulación indebida. Por lo tanto, si el almacén de certificados de confianza de su sistema se corrompe, todas las apuestas se desactivan. Por ejemplo, algunas corporaciones instalarán su propio certificado de CA de firma interna, que les permite administrar el proxy en el medio en cualquier sesión segura del navegador sin que el navegador muestre ninguna alarma. Una vez más, en Windows, los certificados de CA son administrados por el sistema operativo si utiliza IE o Chrome, mientras que Firefox tiene su propia lista de CA de confianza única e independiente.

Pero si su sistema está comprometido, entonces estará brindado. No se puede garantizar la seguridad, ni siquiera SSL. Esto se debe a que los agentes maliciosos pueden incrustarse en cualquier parte de la cadena; quizás a nivel de red, pero quizás también en el navegador, o en el controlador de pantalla, o escuchando las pulsaciones de teclas ... nada es seguro. Existe una clase popular de malware hoy que se inserta en el navegador para leer y modificar los datos encriptados antes se encripta y después se desencripta. Un objetivo, por ejemplo, es modificar ligeramente su experiencia en un sitio de banca en línea para vaciar las cuentas bancarias y transferir todo su dinero al atacante.

El navegador cifra los datos, siempre que confíe en el certificado SSL / clave pública que le ha sido otorgado por el servidor al que está accediendo, que luego se pasa al servidor y se descifra para iniciar una "sesión" cifrada, entre dos entidades.

Explicación excelente y fácil de entender aquí .

  

1. El navegador se conecta a un servidor web (sitio web) protegido con SSL (https).   El navegador solicita que el servidor se identifique.
  
2. El servidor envía una copia de su certificado SSL, incluida la   clave pública.
  
3. El navegador comprueba la raíz del certificado contra una lista de CA confiables   y que el certificado no está vencido, no ha sido revocado, y que su   el nombre común es válido para el sitio web al que se está conectando. Si el navegador confía en el certificado, crea, cifra y envía   respalde una clave de sesión simétrica usando la clave pública del servidor.
  
4. El servidor descifra la clave de sesión simétrica usando su clave privada y   envía un acuse de recibo cifrado con la clave de sesión a   iniciar la sesión cifrada.
  
5. El servidor y el navegador ahora cifran todos los datos transmitidos con la sesión   clave.
  

Alguna información valiosa sobre las CA (Autoridades de Certificado): enlace

El navegador maneja el descifrado normalmente. Aunque hay algunas excepciones a esto. Los proxies pueden eliminar SSL (en cuyo caso el ícono del candado no se mostrará normalmente) o pueden ser un poco más inteligentes y renunciar a la SSL con un certificado en el que el cliente confía de tal manera que el candado todavía aparezca, pero la información sobre el certificado está cambiado. Las configuraciones realmente avanzadas realmente pueden monitorear la conexión SSL si tienen acceso a la clave privada del servidor sin cambiar nada, aunque se usan del lado del servidor, no del lado del cliente (debido a la forma en que se deriva la clave para una sesión SSL).

El cifrado SSL está configurado por el navegador (o cualquier aplicación que utilice SSL), incluso cuando un proxy local reside en el sistema. Un ejemplo, por ejemplo, es que cuando realiza un pentest necesita configurar un proxy local para tener su propio certificado para poder descifrar el tráfico entre el navegador y el punto final.

Las especificaciones de SSL / TLS dictan el protocolo por cable, pero no dicen nada sobre cómo se implementa un cliente. Por lo general, el kernel del sistema operativo proporciona un socket TCP básico sin cifrar. Para implementar la capa SSL, el navegador llama a las funciones en una biblioteca criptográfica (como OpenSSL , SSLeay, < a href="http://www.gnutls.org/"> GNUtls o NSS ) . Por lo tanto, la compatibilidad con SSL suele ocurrir en espacio de usuario , en el mismo proceso que el resto del navegador.

En cuanto a si considera que la compatibilidad con SSL es proporcionada por el "sistema", depende. El navegador puede enlazar a la biblioteca criptográfica de forma estática o dinámica. Una biblioteca dinámica (o DLL) podría distribuirse con el sistema operativo, o el proveedor del navegador puede enviar su propia copia de la biblioteca.

En el lado del servidor, la situación es a menudo similar, donde un módulo de servidor web proporciona soporte SSL (en el espacio de usuario, en el mismo proceso que el resto del servidor web). Sin embargo, las configuraciones alternativas también son comunes. El soporte criptográfico puede ser acelerado por hardware . Un proxy inverso, como un equilibrador de carga, puede colocarse frente al servidor web real y traducir entre HTTP y HTTPS, en cuyo caso los datos pueden viajar sin cifrar dentro de la red del proveedor de contenido.

Para solucionar el problema de la intercepción y manipulación de datos: Cualquier persona que tenga acceso a la clave privada del servidor puede descifrar fácilmente la transmisión . Como corolario, cualquier servidor que presente un certificado firmado por una autoridad de certificados en la que confíe su navegador puede falsificar el sitio web, siempre que el nombre de host en el certificado coincida con el nombre de host en la URL. (Por ejemplo, Opera opera un proxy para su producto Opera Mini . El navegador Opera Mini canaliza todo el tráfico a través del proxy de Opera y confía plenamente en el certificado presentado por el proxy. Por lo tanto, aunque el tráfico entre el navegador y el proxy puede estar cifrado, y el tráfico entre el proxy y el servidor web de contenido puede estar cifrado, Opera tiene la capacidad técnica de leer todos los datos a través de su proxy.) Finalmente, cualquier persona que tenga la capacidad de manipular el navegador (por alguna extensión o mecanismo de complemento) o el enlazador dinámico (usando algo como LD_PRELOAD) o la lista de certificados de confianza del navegador también podría interceptar los datos, aunque señala que la integridad del cliente se ha visto tan comprometida que no hay esperanza para ninguna seguridad significativa.

Un proxy instalado en la máquina cliente puede interceptar un tráfico HTTPS de descifrado.

Sin embargo, para hacer esto, debe colocar su propio certificado en el almacén de certificados raíz de confianza. Al hacerlo, se le indicarán al usuario varios desafíos de seguridad, que no se pueden omitir fácilmente. Por lo tanto, es poco probable que esta técnica sea utilizada por malware a menos que el usuario sea lo suficientemente tonto como para permitir que suceda.

Un gran ejemplo de software que utiliza esta técnica para propósitos no nefarios es Fiddler : una herramienta de depuración HTTP / HTTPS para desarrolladores web.

• Puede leer acerca de cómo habilitar el descifrado HTTPS en Fiddler aquí .
• Puedes ver capturas de pantalla de los diálogos que el usuario debe aceptar aquí .

¿Qué quieres decir con "sistema"? El cifrado debe ocurrir en alguna biblioteca. Esto puede considerarse como parte del sistema de alguna manera, y de otra manera como parte del navegador. (Incluso el navegador en sí es parte del sistema, en el sentido de que está instalado para todos los usuarios que comparten el ejecutable).

La granularidad de seguridad es que todo el navegador y sus componentes se encuentran en el mismo contexto de seguridad (por ejemplo, el proceso del sistema operativo con su propio espacio de direcciones). El cifrado tiene lugar en ese proceso.

Para interceptar los datos de texto sin formato, el software tendría que encontrar una forma de violar el contexto de seguridad del navegador. Esto suele ser posible en sistemas operativos que solo tienen políticas de seguridad generales, para el código que de alguna manera ha adquirido privilegios de superusuario.

Por ejemplo, en sistemas operativos similares a Unix podemos usar la llamada al sistema ptrace para adjuntar a un proceso, y hacer varias cosas como suspender y reanudar su ejecución, monitorear las llamadas al sistema o examinar / modificar su memoria.

Los datos que ingresan al navegador, como las pulsaciones de teclado que ingresa en los formularios, se originan en algún otro contexto de seguridad, a saber, el que contiene el controlador del teclado en el kernel del sistema operativo. Eso también puede ser atacado por un programa privilegiado que puede obtener acceso a los datos que pasan a través de los controladores.

Sin embargo, un proxy HTTP / HTTPS (a diferencia de un programa de superusuario malicioso que se asoma a los procesos) que se ejecuta en la misma máquina no tendría acceso al tráfico de texto sin formato. Lo que pasa a través de un proxy es el protocolo HTTPS encriptado.