Tabla de contenido
- Introducción
- Principio de captura de proxy
- Razones por las que algunas aplicaciones no pueden capturar paquetes
- solución
- Pasos de operación reales (Android)
- Principio de verificación de certificados
- Razones que no se pueden descifrar
- Método de solución y operación
- Pasos de funcionamiento del dispositivo IOS (IOS)
Introducción
La captura de paquetes en la capa de aplicación HTTP se ha convertido en una parte importante del trabajo diario de pruebas y depuración. Recientemente, cuando me comuniqué con un nuevo proyecto, de repente descubrí que los métodos de captura de paquetes anteriores no funcionaban bien. De repente, entre el front-end y el servicio entre el módulo y el módulo Todas las interacciones se volvieron invisibles y toda la persona parecía tener los ojos vendados.
De hecho, descubrí desde el principio que las aplicaciones como Alipay que suelo usar con software de captura de proxy como Fiddler o Charles no pueden capturar solicitudes de forma predeterminada, pero usar software de captura de tarjetas de red como Wireshark puede ver el tráfico de estas aplicaciones. El tráfico también indica que el protocolo de la capa de aplicación principal que utilizan estas aplicaciones sigue siendo HTTP (https), pero nuestra herramienta de captura de paquetes proxy ha fallado. Ahora finalmente lo encontré en el trabajo real y tuve que resolverlo. Después de todo, algo que me bloqueaba me hacía sentir incómodo.
Principio de captura de proxy
Para comprender por qué Fiddler o Charles no son válidos para estas aplicaciones, primero debemos comprender el principio de captura de proxy (por supuesto, no desea saber que también es completamente posible, solo observe la operación real detrás de esto, y analizar el principio en cualquier momento. Vuelve)
El software de captura de paquetes proxy utilizado por Fiddler o Charles es completamente diferente de Wireshark (los datos de la tarjeta de red utilizados por Wireshark se copian, siempre que pasen por la tarjeta de red designada, serán capturados), y solo puede tener efecto para el protocolo de red de la capa de aplicación que utiliza el proxy, como HTTP común (https), Websocket.
Aquí hay una breve explicación usando HTTP como ejemplo
El cliente necesita completar una solicitud HTTP y generalmente necesita encontrar el servidor primero. El cliente establecerá una conexión TCP con el host de destino según el nombre de host de la URL en la solicitud http (en realidad, use el nombre del protagonista en el host) y su puerto. El mensaje HTTP se envía al servidor de destino (para obtener más detalles, consulte https://tools.ietf.org/html/rfc7232 )
A continuación, déjeme ver cómo funciona el proxy HTTP. Cuando iniciamos Fiddler o Charles, iniciamos un servidor proxy HTTP. Este tipo de herramienta notificará al sistema operativo: "Ahora que he creado un proxy HTTP en el sistema, y la IP es el puerto XXXXXX. Es XX. Si está utilizando Linux, puede notificar manualmente al sistema operativo (export http_proxy = ip: port export https_proxy = $ http_proxy), si está utilizando un dispositivo móvil como un teléfono móvil , puede decirle al sistema que desea usar en la configuración de wifi actual proxy http. Ahora que le hemos dicho al sistema que queremos usar un proxy, cuando el cliente http que se ejecuta en el sistema envía una solicitud nuevamente, no funcionará Resolución DNS y conectarse al servidor de destino, pero conectarse directamente El sistema le indica la dirección del proxy (la ip y el puerto del proxy, tenga en cuenta que si es http o https u otros protocolos que admitan el proxy, se conectará al mismo puerto) Luego, el servidor proxy establecerá una conexión con el cliente, y luego el servidor proxy solicitará la información Luego se conectará al servidor real.
También hay un detalle aquí. Normalmente, la línea de solicitud enviada por el cliente al servidor sin un proxy contiene solo una parte del URI (en realidad, no hay esquema, nombre de host y puerto)
Como se muestra en la figura anterior, si no hay proxy, la línea de solicitud de la solicitud a www.baidu.com/index.html es en realidad GET /index.html HTTP / 1.1, que no es nuestro uri completo común. Debido a que el servidor intermedio (es decir, el proxy) no se considera en el diseño HTTP original, el cliente ya conoce la dirección del servidor y establece una conexión con él antes de enviar el mensaje, no es necesario enviar el esquema, el nombre de host y el puerto. . Sin embargo, este enfoque será problemático después de que aparezca el proxy El cliente se conecta al servidor proxy, pero el servidor proxy no puede conectarse al servidor correcto. Por lo tanto, la solicitud enviada por el cliente al proxy es en realidad ligeramente diferente.El cliente utilizará el uri completo en la línea de solicitud para que el servidor proxy pueda resolver la dirección real del servidor.
Ahora nuestras solicitudes se envían realmente a través de un servidor proxy (Fiddler o Charles), por lo que el software de captura de proxy no solo conoce todos los paquetes de la solicitud y respuesta http, sino que incluso puede modificar la solicitud y la respuesta en cualquier momento.
Razones por las que algunas aplicaciones no pueden capturar paquetes
Puede verse que la clave para la captura de proxy es que el cliente HTTP necesita conectarse al servidor proxy según sea necesario. En circunstancias normales, hemos configurado un proxy a nivel del sistema. Por lo general, los clientes http se implementan según sea necesario, antes de realizar una solicitud http El proxy del sistema se comprobará primero. Si se establece un proxy, el cliente utilizará directamente el uri completo para conectarse al servidor proxy. Las diferentes plataformas suelen implementar sus propios clientes http, aunque todas implementan la función de proxy según los requisitos del protocolo, no necesariamente utilizan el proxy del sistema directamente de forma predeterminada.
En realidad, hay bastantes casos en esta situación. Este es el caso de Flutter utilizado en el proyecto actual del autor. De forma predeterminada, Flutter no utilizará activamente el proxy del sistema y debe configurarse por separado. (Por supuesto, creo que esta estrategia también es razonable, aunque trae inconvenientes para las pruebas y la depuración, también mejora un poco la seguridad de los datos hasta cierto punto)
Es precisamente porque el cliente HTTP no usa el proxy del sistema que configuramos, naturalmente no se conectarán al servidor proxy creado por Fiddler o Charles, lo que en última instancia nos impide recibir solicitudes.
solución
Pero ahora que ya conocemos las razones específicas por las que Fiddler y Charles no pueden capturar paquetes, y el principio de captura de proxy se mencionó anteriormente, entonces tenemos una solución.
Como se mencionó anteriormente, el cliente HTTP utilizado por nuestra APLICACIÓN no está conectado al servidor proxy, lo que hace que nuestro software de captura de proxy no capture los paquetes normalmente. Entonces solo necesitamos encontrar una manera de que el cliente se vuelva a conectar al servidor proxy ( por supuesto, todo esto se basa en la premisa de no modificar la aplicación de software del cliente)
Método 1: controle la resolución de DNS y deje que el cliente piense que nuestro servidor proxy es el servidor de destino modificando dns.
Ventajas: fácil de operar, es muy conveniente modificar los hosts del dispositivo.
Desventajas: es necesario agregar un host de antemano para cada nombre de dominio que deba operarse
Es difícil modificar hosts en dispositivos de mano como teléfonos móviles (es decir, es difícil implementar aplicaciones como aplicaciones móviles)
Método 2: reenvío de tráfico directo en el dispositivo de red y reenvío de los datos enviados al puerto 80 y 443 en el dispositivo terminal designado directamente al puerto de destino del servidor proxy
Ventajas: se puede configurar por separado para dispositivos terminales conectados a dispositivos de red, y los dispositivos terminales, como teléfonos móviles, no requieren ningún equipo
Desventaja: requiere equipo de hardware separado
Método 3: use VPN para reenviar el tráfico del dispositivo terminal al servidor proxy
Ventaja: use el software VPN sin agregar otras pruebas.
Desventajas: la VPN del terminal reenviará directamente todo el tráfico de forma predeterminada, y una configuración razonable puede requerir costos de aprendizaje adicionales
Pasos de operación reales (Android)
El autor usa directamente el tercer método mencionado anteriormente (el método 1 es difícil de operar para aplicaciones móviles, el método 2 puede requerir otro equipo, por lo que no lo usamos aquí), porque nuestro objeto de prueba es una aplicación móvil móvil, por lo que primero debemos use el teléfono móvil Instale una VPN en su teléfono móvil y use un software VPN muy conveniente drony (presentado aquí https://github.com/SuppSandroB/sandrop/wiki/Drony-FAQ ), drony creará una VPN en su móvil teléfono y conéctelo a Todo el tráfico del teléfono se redirige al propio drony (no al servidor vpn), de modo que drony puede administrar el tráfico de red en todos los teléfonos e incluso configurar el tráfico de diferentes aplicaciones en el teléfono de forma individual.
1: Instale drony (el dispositivo Android que usa el teléfono aquí)
Puede buscar drony en Internet y elegir la versión que desea instalar, o descargarla aquí ( https://files.cnblogs.com/files/lulianqi/Drony_102.apk ). Una vez completada la instalación, abra el software Como se muestra abajo
2: Abra el software de captura de proxy (aquí el software de captura de proxy utiliza Fiddler)
El uso de Fiddler no se presentará aquí. Debe abrir el proxy remoto e instalar el certificado raíz de Fiddler en el teléfono.
La dirección del agente remoto abierto por el autor aquí es 192.168.2.244:8888
Hay algunos detalles sobre la instalación del certificado. El certificado raíz predeterminado de Fiddler está en formato cer, y algunos teléfonos móviles solo pueden reconocer certificados en formato pem.
Simplemente use openssl para darle la vuelta (openssl x509 -inform der -in FiddlerRoot.cer -out FiddlerRoot.pem)
Openssl generalmente se instala en windows / mac, y el comando se puede usar directamente, solo use el FiddlerRoot.pem generado para instalarlo en el teléfono (Charles usa el certificado pem por defecto)
3: configurar el reenvío de Drony
Abra Drony (en el estado APAGADO), deslícese hasta la página CONFIGURACIÓN, haga clic para seleccionar Redes Wi-Fi para ingresar a la configuración
En la lista de redes, seleccione y haga clic en la red de conexión wifi del teléfono móvil actual (debe asegurarse de que la red esté conectada a la red del servidor proxy de Fiddler)
Configure la entrada de proxy que se utilizará para la red actual (aquí puede completar directamente la dirección de proxy de Fiddler), seleccione el modo de proxy como Manual (Manual)
Tenga en cuenta que el método de proxy de tipo Proxy debe elegir Proxy http simple
Filtrar el valor predeterminado, seleccione Directo todo y luego haga clic en Regla a continuación para establecer las reglas de la aplicación
De forma predeterminada, su regla debe estar vacía. Haga clic en el signo más de arriba para agregar una regla (solo se reenviarán aquellas que cumplan con los requisitos de la regla)
Explique que las siguientes operaciones utilizarán pescado salado o Alipay como demostración. Sin embargo, el elemento de prueba actual del autor no es pescado salado o Alipay, ni es un empleado de su empresa. Elegí estas dos aplicaciones para la demostración porque estas aplicaciones se utilizan con más frecuencia y no pueden. La razón para capturar paquetes es similar a la aplicación actual del proyecto del autor.
Seleccione el SSID del wifi actual en ID de red
Acción seleccionar Cadena de proxy local
Aplicación Seleccione la aplicación que necesita ser forzada a proxy
Si el nombre de host y el puerto no están completos, significa que todos ellos se verán obligados a usar un proxy, porque la aplicación puede usar otros protocolos de red, no necesariamente http, y es posible que no desee desviar todo el tráfico al servidor proxy http, esta vez utilizará esta configuración para especificar la dirección IP y el reenvío de puertos
Guárdelo cuando haya terminado, luego regrese a la página de inicio de CONFIGURACIÓN, deslícese a la página de REGISTRO, haga clic en el botón de abajo para ponerlo en el estado ENCENDIDO (que indica habilitar)
En este momento, inicie Alipay o Xianyu, y podemos ver el tráfico normal en Fiddler. Sin embargo, si tiene la misma suerte que el autor, es posible que solo vea estos Túnel a (establecimiento de canalización TLS). Si está utilizando Charles, es posible que vea cruces rojas en la lista.
Por supuesto, el certificado raíz de Fiddler del autor se instaló correctamente y la configuración de Fiddler es correcta (la captura https de Chrome en el teléfono es normal)
Ahora que el tráfico ha llegado a Fiddler, el trabajo de Drony está perfectamente completado y algunas de las aplicaciones no pueden descifrar el mensaje https, lo que sigue siendo un problema con nuestro propio certificado. Primero, describa brevemente el proceso de verificación del certificado (si no desea ver estos procesos, puede ver directamente los siguientes pasos )
Principio de verificación de certificados
Tanto Fiddler como Charles usan ataques man-in-the-middle para reemplazar el certificado de enlace tls, descifrar el mensaje y luego cifrarlo y enviarlo al servidor real.
Puede consultar la Práctica de ataque HTTPS Man-in-the-Middle (Principio · Práctica) para obtener detalles sobre el ataque man-in-the-middle
En presencia de un proxy, el cliente primero se conecta al servidor proxy (es decir, el atacante en la figura). El cliente real es un canal TLS establecido directamente con el proxy, por lo que el proxy, por supuesto, utilizará la clave de transmisión de el canal TLS y luego descifrar el mensaje.
Sin embargo, debido a la existencia del certificado, el cliente verificará la validez del certificado y luego decidirá si se conecta al servidor. Usamos Fiddler o Charles para instalar el certificado raíz en el dispositivo antes de tomar https para pasar la verificación del certificado del cliente.
Busque cualquier página web https en el navegador y vea la información de su certificado.
Desde aquí podemos ver que el certificado contiene lo siguiente:
(1) La validez es también el período de validez. El período de validez incluye el tiempo efectivo y el tiempo de vencimiento, que es un intervalo de tiempo;
(2) Información de la clave pública del sujeto, incluido el algoritmo de cifrado de clave pública y el contenido de la clave pública;
(3) Información de huellas dactilares. Las huellas dactilares se utilizan para verificar la integridad del certificado y también son la clave para la verificación del certificado. Su garantía no ha sido modificada. El principio es que al emitir un certificado, el emisor calcula la huella dactilar hash de todo el certificado según el algoritmo de huella dactilar (aquí el certificado utiliza los algoritmos SHA-1 y SHA-256 con múltiples huellas dactilares para ser compatible con clientes antiguos) [certificado valor de hash de contenido El uso de cifrado de clave privada de CA es la huella dactilar] y lo junta con el certificado. Cuando el cliente abre el certificado, también calcula el valor de hash del certificado de acuerdo con el algoritmo de huella dactilar y utiliza la clave pública del certificado de confianza. certificado raíz para descifrar la huella digital hash para calcular el hash original, si el valor hash es inconsistente, indica que el contenido del certificado ha sido alterado;
(4) Valor de firma del certificado y algoritmo de firma del certificado, el algoritmo Hash y el valor Hash utilizado para firmar el certificado;
(5) Emisor de la institución CA que emitió el certificado;
(6) A qué organización / sujeto de la información de la empresa se emite el certificado;
(7) Versión del certificado Versión, número de serie del certificado Número de serie e información de extensión de extensiones, etc.
La figura anterior es el proceso de verificación de la huella digital del certificado. Es posible que vea que el núcleo del certificado de verificación del cliente es en realidad la clave pública de la CA para descifrar la huella digital original. ¿De dónde proviene la clave pública de la CA? Para garantizar la seguridad El sistema del dispositivo tendrá un lote de claves públicas de CA en las que confía Lista (certificado raíz). Estas claves públicas de CA generalmente corresponden a autoridades u organizaciones, y estas autoridades utilizarán sus propias claves privadas para firmar (generar huellas digitales para certificados) al emitir certificados. Esto asegura que solo los certificados emitidos por la autoridad a cada sitio web serán verificados por el cliente.
Filddler no tiene la clave privada correspondiente a la clave pública en estos certificados (la CA solo entregará la clave privada correspondiente al certificado completo al propietario del sitio web), por lo que no hay forma de completar el protocolo de enlace TLS con el cliente. . Para completar el protocolo de enlace, Filddler solo puede generar certificados para diferentes sitios.
Sin embargo, el certificado generado por usted debe estar firmado con su propia clave privada, y el cliente no puede encontrar el certificado raíz correspondiente en la lista de claves públicas de la CA de confianza por sí mismo, y no debe pasar la verificación del certificado. Por lo tanto, Filddler requiere que instalemos su certificado raíz en el dispositivo, para que el certificado emitido por sí mismo pueda pasar la verificación del certificado y pueda descifrar el mensaje https por sí mismo.
Razones que no se pueden descifrar
De hecho, a través de la descripción anterior, también está claro que la razón por la cual la conexión no se puede establecer normalmente para descifrar el mensaje https es que la verificación del certificado falló y la instalación de nuestro certificado raíz no está completa.
Desde Android7.0, el sistema permite que cada aplicación defina su propio conjunto de CA confiables . Algunas aplicaciones solo confiarán en el certificado CA preinstalado por el sistema de forma predeterminada, pero no confiarán en el certificado CA instalado por el usuario (o el marco de desarrollo utilizado por la aplicación solo confía en el certificado del sistema de forma predeterminada, porque los desarrolladores generalmente no lo hacen). se preocupan por estas configuraciones, ni ellos Para cambiarlo). En Android, los certificados instalados por los usuarios son todos certificados de usuario, por lo que ya sea Filddler o Charles, solo instalamos sus certificados raíz a los certificados de usuario. Estas aplicaciones no los usan, por lo que nuestros certificados instalados no son válidos.
Método de solución y operación
Ahora que se conoce el motivo, siempre hay una forma de solucionarlo. Solo necesitamos instalar el certificado raíz del software del agente como certificado del sistema.
De hecho, es relativamente sencillo instalar el certificado en el área del sistema, simplemente coloque el certificado en la ubicación especificada (/ system / etc / security / cacerts /) con el nombre especificado
Primero cambie el nombre de nuestro certificado raíz a <Certificate_Hash>. <Number>
Certificate_Hash representa el valor hash del archivo de certificado, y Number es el sufijo agregado para evitar que el valor hash del archivo de certificado sea consistente (use 0 en la línea)
Descargue su propio certificado raíz FiddlerRoot.cer, use openssl x509 -subject_hash_old -in <Certificate_File> para calcular el hash del certificado y cambie el nombre del certificado a 269953fb.0 basado en el hash (269953fb es el hash del certificado del autor, todos son definitivamente diferentes )
Luego copie el archivo 269953fb.0 en / system / etc / security / cacerts /
（
El método del blogger es realmente muy práctico, pero el comando final para calcular el hash del certificado carece de algunos detalles.
Cuando
calculé en el sistema Win 10, use el comando openssl x509 -subject_hash_old -in FiddlerRoot.cer
se quejará, luego de Internet para encontrar más tarde encontrará que necesita modificar el comando de la siguiente manera:
OpenSSL X509 -inform der -subject_hash_old -IN FiddlerRoot.cer -no hay
motivo para el Al calcular, debe señalar explícitamente que el formato del certificado llamado es cer, de lo contrario, informará un error y no se puede calcular.
）
Una vez finalizado, podemos ver que el certificado del software del agente aparece en el área del sistema.
Hay otro punto que debe explicarse por separado: el permiso de escritura del directorio / system / etc / security / cacerts / requiere permiso de root del teléfono.
En otras palabras, copiar el certificado a este directorio requiere que usted rootee su propio dispositivo.
En cuanto a rootear teléfonos Android, generalmente los fabricantes de teléfonos móviles tendrán sus propios tutoriales oficiales. Se recomienda seguir las operaciones oficiales para rootear
Tome el teléfono móvil Xiaomi como ejemplo ( http://www.miui.com/thread-12281379-1-1.html )
La raíz del teléfono móvil Xiaomi actual debe estar vinculada a la cuenta Xiaomi durante más de 7 días para desbloquearla. Después de desbloquear, deslice la versión de desarrollo para completar la raíz
Cabe señalar que no todos los teléfonos móviles Xiaomi tienen versiones de desarrollo correspondientes, así que preste atención al comprar equipos de prueba. ( Http://www.miui.com/download.html Aquí puede ver si hay una versión de desarrollo disponible para su teléfono móvil)
efecto
Ahora el certificado está instalado en el área del sistema y luego regrese a Fiddler para ver el efecto
Abra Xianyu nuevamente y ya podemos ver la solicitud https completa.
Busquemos una solicitud para modificar la solicitud para devolver los datos para ver el efecto
Use el complemento FreeHttp de Fiddler para modificar los datos devueltos de esta solicitud, modifique el teléfono móvil de segunda mano a un caballo de segunda mano y reemplace la imagen
Configuración como se muestra a continuación
(Para el uso específico de FreeHttp, consulte FreeHttp para alterar arbitrariamente los mensajes http (use · implementación) )
Abra Xianyu nuevamente, puede ver que los datos del proxy han sido manipulados (tenga en cuenta que el caché y los datos de la aplicación de Xianyu se borran durante la prueba para garantizar que se solicitarán los primeros datos cada vez que se abra la APLICACIÓN)
Después de la configuración anterior, el tráfico HTTP de estas APLICACIONES se puede obtener a través del software de captura de paquetes proxy, y el tráfico https también se puede decodificar normalmente.
Pasos de funcionamiento del dispositivo IOS (IOS)
ios (iphone) también usa el tercer método mencionado anteriormente (el principio es el mismo que el de android), y también necesita usar VPN. También hay muchos softwares con funciones similares a las de drony en ios. Puedes elegir el que más te guste. Aquí es el autor usando Shadowrocket
Como se muestra en la imagen de arriba, puede encontrar este software directamente en la App Store (sujeto a las regulaciones pertinentes del continente, si el área de su App Store no puede buscar este software en China, necesita para usar la cuenta en los EE. UU.)
Para completar la redirección del tráfico, Shadowrocket, como Drony, primero creará un servicio VPN local en el dispositivo y luego usará las reglas que establezca para procesar el tráfico.
Sin embargo, el uso de Shadowrocket será más conveniente, simplemente abra el software y configure como se muestra a continuación.
- Seleccione la ruta global como "proxy"
- Agregue un nodo de servicio (seleccione los tipos HTTP y HTTPS, la dirección y el puerto del servidor son la dirección y el puerto de su herramienta de captura de proxy)
- Configure el estado para habilitar (IOS creará VPN automáticamente al mismo tiempo)
Ahora abra directamente cualquier APLICACIÓN en el iphone (no es necesario configurar repetidamente el proxy en el wifi), puede ver el tráfico en la herramienta de captura de proxy y no puede analizar el tráfico HTTPS, pero IOS no lo hace como el nueva versión de Android. La APP rechaza el certificado raíz del usuario en el que confía manualmente el usuario, por lo que el certificado IOS instala más IOS que Android y no hay tantas operaciones adicionales. Simplemente siga el proceso normal de instalación del certificado. Una vez instalado el certificado, puede ver el tráfico HTTPS
Para que Android realice las operaciones anteriores, puede usar la raíz del emulador de Android para instalar los complementos en el marco xposed
Certificado autofirmado + verificación en la aplicación, aún no se puede aprobar. APP solo reconoce su propia CA.