Red de conocimiento informático - Programación de la red - El período de prueba no pasó porque estaba en el sitio web 1024 de la empresa...

El período de prueba no pasó porque estaba en el sitio web 1024 de la empresa...

Recientemente examiné una pregunta de Zhihu: durante el período de prueba, un estudiante de operaciones reprobó el período de prueba porque visitó un sitio web 1024 mientras trabajaba.

También vi muchos tweets en los últimos dos días, en el sentido de que antes de ver una película corta, debes prestar atención a si la URL es HTTPS, porque HTTPS está encriptado y otros no lo sabrán. .

Después de ver las preguntas anteriores, no puedo evitar querer preguntar (este circuito cerebral también es...):

En resumen, ¿pescas online durante el horario laboral? ? Incluso si el acceso es vía HTTPS, si la empresa lo sabe, ¿por qué medio?

[Error en la carga de la imagen...(image-ab58e2-1614692093957)]

Este artículo habla de mis opiniones, que se dividen principalmente en los siguientes aspectos:

HTTPS, también conocido como HTTP sobre TLS, TLS era anteriormente SSL y existen varias versiones.

La figura anterior describe la relación entre TLS (cada subprotocolo) y HTTP en la pila de protocolos TCP/IP. HTTP TLS también es HTTPS.

En comparación con HTTP, las ventajas de HTTPS:

La figura anterior presenta brevemente el proceso de protocolo de enlace de HTTPS. Los estudiantes interesados ​​pueden usar WireShark para capturar paquetes y observar en detalle cada uno de ellos. Pasos para ayudar a comprender el proceso completo de HTTPS. No entraré en detalles aquí.

En términos generales, el cliente y el servidor negocian un algoritmo de cifrado y los parámetros aleatorios correspondientes admitidos por ambas partes a través de una "reunión de protocolo de enlace" y obtienen un par de claves. Todas las transmisiones posteriores se realizan a través de este par. de claves. Cifrado y descifrado.

Este par de claves es genial. Por ejemplo, para cifrar y transmitir un mensaje "tangleithu", el cliente transmite el texto cifrado "xyyaabbccdd" obtenido mediante cifrado de clave pública y el servidor utiliza su propia clave privada. para descifrar el texto cifrado, justo a tiempo para obtener "tangleithu".

No hay ningún error en el medio, garantizando así la integridad y privacidad de los datos. Este proceso es relativamente complicado y no se describirá en detalle en este artículo.

Por tanto, cuando se accede a un sitio web a través de HTTPS, aunque se intercepte y monitorice el tráfico, la información obtenida se cifra y no se puede ver ningún contenido sustancial.

Por ejemplo, como se muestra en la figura siguiente, cuando visito un sitio web, la información obtenida a través de la captura de paquetes Wirehark solo puede obtener algunas direcciones IP de comunicación.

¿Estás aliviado ahora? En el proceso de pesca, incluso si se conoce la dirección IP a la que se accede, ¿no parece importar? De hecho, puede obtener mucha información con su dirección IP.

Afortunadamente, se descubrió que esta IP era Github, no...

[Error en la carga de la imagen...(image-5b829a-1614692093957)]

Quizás se alegrará de no poder ver ni siquiera el nombre de dominio de un sitio web, por lo que podrá pescar con confianza.

¿Pero es esto cierto?

[Error en la carga de la imagen...(image-795ebb-1614692093957)]

¿HTTPS es realmente completamente seguro? ¿Ni siquiera puedes conseguir el nombre de dominio que deseas visitar? La respuesta es no. El HTTPS anterior tiene algo muy importante en la fase de protocolo de enlace: el certificado.

SNI: Rayado de nombres de dominio

Al acceder a un sitio HTTPS, primero se establecerá una conexión SSL con el servidor. El primer paso es solicitar el certificado del servidor.

Cuando una IP de Servidor solo corresponde a un nombre de dominio (sitio), es muy conveniente que cuando cualquier cliente lo solicite, se puede devolver el certificado correspondiente al nombre de dominio (servicio) sin pensarlo.

Pero las direcciones IP (IPv4) son limitadas. ¿Qué debemos hacer cuando varios nombres de dominio reutilizan la misma dirección IP?

Cuando el servidor envía el certificado, no sabe a qué nombre de dominio está accediendo el navegador, por lo que no puede enviar diferentes certificados basados ​​en diferentes nombres de dominio.

Por lo tanto, se actualizó el protocolo TLS y se agregó SNI (Indicación de nombre de servidor), que resuelve la extensión SSL/TLS de un servidor que utiliza múltiples nombres de dominio y certificados.

Ahora todos los clientes principales admiten este protocolo. No me pregunten cómo sé esto. Pasé mucho tiempo haciendo esto en el trabajo...

Su principio es: antes de establecer una conexión SSL con el servidor, primero envíe el nombre de dominio del. sitio que desea visitar (nombre de host), para que el servidor devuelva un certificado apropiado basado en este nombre de dominio. No hay forma de cifrar o descifrar en este momento, por lo que al menos este nombre de dominio está disperso.

Como se muestra en la figura siguiente, la captura de pantalla anterior es en realidad la captura del paquete de visitar mi blog personal (www.tanglei.name). Cuando el cliente envía una solicitud de protocolo de enlace, conscientemente trae su propio nombre de dominio. .

Por lo tanto, incluso con HTTPS, la información del nombre de dominio al que se accede está en un estado disperso. Sus visitas a pequeños sitios web de películas durante el trabajo dejarán rastros. Si está conectado a la red de la empresa, naturalmente quedará atrapado.

Además de la fuga de nombres de dominio, en realidad existe un riesgo más grave: los ataques de intermediario.

Ataque de intermediario

Como se mencionó anteriormente, la clave de HTTPS en realidad reside en este certificado.

Como puede verse por el nombre, un ataque de intermediario es un "intermediario" entre el cliente y el servidor. El "intermediario" disfraza a la otra parte entre el cliente y el servidor. .

Como se muestra en la figura siguiente, este "MitmProxy" actúa como intermediario y se engaña entre sí:

Ataque de intermediario, fuente evil0x

Puede instalar MitmProxy o Fiddler o similar. Pruebe el software de captura de paquetes y luego habilite el proxy.

En este momento, cuando utilices tu teléfono móvil para acceder a Baidu, obtendrás la siguiente información:

Antes de confiar en el certificado

Ten en cuenta que la conexión No es una conexión privada, pero el navegador ha reconocido el certificado. Algo no está bien, no hay confianza. Y si el teléfono tiene instalado el certificado de Fiddler en este momento, se podrá acceder a él normalmente.

Una vez que el certificado sea confiable, podrá acceder a él normalmente.

Por lo tanto, cuando confíe en el certificado, podrá ver todo frente al intermediario.

Si utiliza una computadora de la empresa, supongo que tiene las operaciones correspondientes para confiar en el certificado, ¿o tiene un software de cliente similar instalado en su teléfono móvil?

Tómese el tiempo para mirar los detalles de instalación del certificado en su teléfono (como el de mi teléfono):

Mi antigua empresa era muy cautelosa con la seguridad de la información y el teléfono Tenía un teléfono de trabajo, no se puede instalar ninguna aplicación no autorizada. Quién sabe qué hará la aplicación en silencio. (El último punto de acceso, QQ escanea el historial del navegador, ¿lo sabía?)

Por supuesto, varias aplicaciones definitivamente no son vegetarianas y no permitirán que los "ataques de intermediario" tengan éxito, por lo que fácilmente. Echemos un vistazo.

Como se mencionó anteriormente, para implementar un ataque de intermediario, la clave es si el certificado es confiable. El comportamiento del navegador es que el certificado permite al usuario autorizar si confía en él, y el propio desarrollador puede controlar la aplicación.

Por ejemplo, intenté capturar y descifrar paquetes HTTPS en una comunidad anónima mediante un método similar, pero finalmente fallé.

Se trata de la tecnología "SSL Pinning". La aplicación puede verificar por sí misma si el certificado devuelto por el servidor durante el protocolo de enlace SSL es legal. La tecnología de "fijación SSL" significa que en la aplicación solo se confían los certificados fijos o las claves públicas.

Debido a que el certificado del servidor debe devolverse al cliente durante la fase de protocolo de enlace, si el cliente está empaquetando, colocará el certificado del servidor localmente y lo comparará durante el paso del certificado de verificación del protocolo de enlace. es exactamente el mismo que el certificado local integrado antes de que se inicie la solicitud de red.

En caso contrario, la conexión se desconectará directamente y no estará disponible. Por supuesto, en circunstancias normales, el uso de esta tecnología puede evitar que se descifre la información HTTPS.

Sin embargo, existen otras tecnologías que pueden descifrar este método, como algunas tecnologías Hook en Android, específicamente para evitar la lógica de verificación fuerte de certificados locales.

Los estudiantes interesados ​​pueden estudiarlo con fines de aprendizaje. Sin embargo, se dice que este método requiere enraizamiento, jailbreak, etc. del sistema, y ​​requiere algunas configuraciones de permisos más altas.

Por ello, también se nos advierte que no instalemos algún software de forma aleatoria, si no tenemos cuidado, podemos ser engañados y dejarnos correr desnudos por Internet.

Por un lado, se filtra información de privacidad personal y, por otro, también se puede robar información muy importante como las contraseñas de las cuentas.

Por supuesto, la computadora de la oficina debe estar conectada a la red de la empresa. A través de la introducción anterior, también debe saber que la empresa sabe exactamente qué sitios web navegó y cuándo.

Ocurre exactamente lo mismo si tu teléfono móvil está conectado a la red de la empresa (ni siquiera necesitas instalar el software Agent). Esto nos recuerda que debemos intentar utilizar nuestra propia red móvil para acceder de forma privada a Internet.

Como se mencionó anteriormente, si cierta información confidencial que involucra privacidad, como algún software de PC y aplicaciones móviles, se cifra y se transmite internamente, no será un gran problema si el cifrado del contenido (incluido, entre otros, HTTPS) no está descifrado.

Sin embargo, esto por supuesto depende del nivel de estos diseñadores de software. Por ejemplo, la identificación mostrada al mundo exterior por el mismo usuario anónimo no puede ser la misma. Si son iguales, se expondrá una vulnerabilidad lógica.

Por supuesto, no debemos correr riesgos. Según los requisitos de supervisión, si realmente hay algunos comentarios ilegales e inapropiados, siempre habrá una manera de encontrarlo.

Es más, la mayoría de los ordenadores de oficina tendrán algún software de seguridad de la empresa preinstalado. En cuanto a lo que hacen estos software, ya sea que tomen las legendarias capturas de pantalla secretas o algo así, esto varía de persona a persona (empresa). ). (No discutiremos si un comportamiento similar implica una infracción de la privacidad de los empleados u otras cuestiones)

Sin embargo, personalmente creo que no hay necesidad de preocuparse demasiado. En términos generales, las empresas no le molestarán sólo porque accidentalmente busque algo mientras está en el trabajo, navegando por Taobao o consultando Weibo. Después de todo, no hay necesidad de "ir a la guerra" por un asunto tan trivial.

¿Pero no sería mejor consultar el manual del empleado para ver si hay conductas prohibidas? ¿Tu comportamiento fue demasiado lejos para evitar que te descubrieran? Como dice el refrán: "Si siempre caminas junto al río, tus zapatos no se mojarán".