Wireshark captura el paquete y comprende el proceso de solicitud HTTPS.
Mi operación es la siguiente: colocar el teléfono móvil y la computadora en la misma LAN (por ejemplo, conectados al mismo wifi) y luego configurar un proxy en el wifi del teléfono móvil. La computadora usa a Charles como proxy y la IP es la IP de la LAN de la computadora. En mi entorno, la IP del teléfono móvil es 172.17.32.117 y la IP de la computadora es 172.17.32.117. Luego configure el puerto proxy en 8888. Después de configurar el proxy, la siguiente solicitud del teléfono móvil se enviará a través de la solicitud de proxy de la tarjeta de red de la computadora.
De hecho, no hay necesidad de andar así. La razón por la que se configura un proxy adicional es porque el teléfono móvil no puede recibir el punto de acceso wifi creado por la computadora. Esto se hace para permitir que los planes de telefonía celular sean rastreados a través de redes informáticas.
La forma más cómoda es instalar un punto de acceso wifi en tu ordenador y conectarlo a tu teléfono.
Después de crear la conexión proxy, utilice Wireshark para detectar la tarjeta de red. Por ejemplo, uso la tarjeta de red etho0 para acceder a la red. En este momento, si abre algunas solicitudes en su teléfono móvil, aparecerá una gran cantidad de paquetes de datos capturados en Wireshark. Existen varios protocolos, incluida la búsqueda ARP (encontrar la dirección física correspondiente a la IP), el paquete de conexión TCP y el paquete de solicitud HTTP.
Aquí, configuro reglas de filtrado para que NetEase filtre las solicitudes una tras otra, como se muestra a continuación:
El proceso completo de la solicitud HTTPS completa es el siguiente:
A continuación, el teléfono móvil llama a A (172.17.32.211) y la computadora llama a B (172.17.32.19).
Como el primer paquete TCP de todo el proceso, aquí hay un análisis detallado del mismo para comprender el formato y el contenido del mensaje TCP. TCP es un protocolo de capa de transporte responsable de la comunicación de datos confiable. Su posición en toda la arquitectura es la siguiente:
Como protocolo de capa de transporte, proporciona principalmente tres funciones para los protocolos de capa superior:
El protocolo TCP proporciona funciones de comunicación básicas para HTTP y Protocolos SSL. Entonces el protocolo SSL se basa en TCP.
El contenido del protocolo de enlace de tres vías es:
Análisis detallado de cada paquete:
a envía un paquete de datos con un bit de sincronización SYN para notificar al servidor para establecer una conexión.
El primer apretón de manos, los datos del paquete TCP enviado y los resultados del análisis de Wireshark son los siguientes:
La parte gris es el contenido de datos del mensaje TCP, los dos primeros los bytes son 0x8c85 = 35973 representa el puerto de origen.
El formato del mensaje TCP es el siguiente, correspondiente a la parte gris en la figura anterior. Las partes que no son grises son el encabezado IP y el encabezado del marco de datos, respectivamente.
Consulte el libro "Computer Network" de Xie Xiren y compárelo con la tabla de formato de mensaje completo para explicar la información binaria y los significados relacionados de todo el mensaje TCP:
En este momento, el datagrama TCP La parte fija del encabezado termina, la parte fija I * * * tiene 20 bytes. Es decir, el encabezado TCP debe tener al menos 20 bytes.
Una vez arreglado el encabezado, hay una opción de longitud variable:
El tamaño de todo el paquete TCP se puede expresar de la siguiente manera:
La cadena larga después de Wireshark El mensaje señala alguna información principal del mensaje TCP:
Como se puede ver en el análisis anterior, este paquete SYN no transporta datos, pero según el protocolo, aquí se consume un número de secuencia. .
Después de enviar el paquete SYN, el terminal A entra en el estado SYN-SENT.
bRecibe el paquete SYN y envía el paquete de confirmación SYN ACK.
Este paquete es a la vez una confirmación de recepción del primer protocolo de enlace y un paquete de sincronización enviado por el terminal B, que indica que está listo para comenzar a enviar datos.
En comparación con el primer paquete de protocolo de enlace, se pueden ver algunos cambios en el paquete TCP:
Como puede ver, la marca de tiempo de respuesta de este paquete es la marca de tiempo de transmisión del primer protocolo de enlace. . También se puede entender a partir de esto que este paquete es el paquete que responde al primer apretón de manos.
Por lo tanto, el receptor A puede usar este valor para calcular el RTT esta vez. Después de recibir un paquete para el segundo protocolo de enlace, calcular la marca de tiempo actual menos la marca de tiempo de respuesta del paquete es el retraso RTT.
Aunque se trata de un paquete ACK, también es un paquete SYN, por lo que también consume un número de secuencia.
Después de enviar este paquete, el terminal B entra en el estado SYN-REVD.
Después de recibir, A envía un paquete de confirmación ACK.
Los paquetes de software lanzados son los siguientes:
Aquí tenemos un problema. Aquí, el remitente A envía información de solicitud de conexión, el receptor B envía información de confirmación y los números de secuencia se sincronizan entre sí. ¿Es posible transferir datos? Pero en realidad, A debe enviar otro mensaje de confirmación ACK. Como se muestra en la figura, se confirma que se ha recibido el paquete de datos enviado por B en el segundo protocolo de enlace. En este momento, A y B ingresarán oficialmente al estado de establecimiento después de este paquete ACK. Este es el primer apretón de manos de tres vías.
¿A qué se debe esto?
Supongamos que usamos dos apretones de manos y luego, durante el primer apretón de manos, A envía el paquete de apretón de manos por primera vez y luego ocurre una situación: se ha retransmitido una vez y no se recibe respuesta. luego el paquete se envía nuevamente y luego declaramos que el último paquete no es válido.
Entonces podemos ver:
Entonces, solo después de que el receptor B envíe el tercer paquete de protocolo de enlace del remitente A, pensará que la conexión se ha establecido y comenzará a esperar al remitente. A Los datos enviados para que el receptor no reciba una excepción debido a un mensaje de solicitud de conexión no válida.
El diagrama de secuencia del protocolo de enlace de tres vías TCP es el siguiente:
El protocolo de enlace de tres vías tiene varias tareas importantes. Uno es el número de secuencia de sincronización. Tanto el extremo receptor como el extremo emisor envían paquetes de sincronización para notificarse mutuamente el número de secuencia inicial, de modo que los paquetes posteriores recibidos puedan transmitirse de manera confiable de acuerdo con el número de secuencia. Otra es preparar tanto al remitente como al destinatario. Luego comience a transferir datos.
Todo el proceso ocurre antes de que se envíe el mensaje HTTP. El protocolo HTTP se basa en el protocolo TCP para gestionar la transmisión. TCP puede considerarse como su administrador, que gestiona el tamaño de las transacciones de transmisión, por ejemplo, ¿se garantiza que el orden de los paquetes de datos sea coherente? ¿Cuándo se adjudica el contrato? ¿Quieres recoger el paquete? TCP es muy estricto.
A nivel de API de Java, el protocolo de enlace de tres vías corresponde a la creación de una conexión de socket (la última llamada es la capa nativa creada por el Socket):
El ConnectTimeout aquí Corresponde a la duración total del tiempo de protocolo de enlace de tres vías. Si se excede el límite de tiempo, se considerará un fallo de conexión.
Por ejemplo, en un escenario, después de que el cliente envía un mensaje SYN, no recibe un SYN ACK del servidor. En este momento, el cliente activa el mecanismo de retransmisión, duplica el intervalo de retransmisión y no recibe ningún paquete de datos. Luego, si este tiempo excede la configuración del tiempo de espera de la conexión, se produce un tiempo de espera de la conexión.
Por lo tanto, si el tiempo empleado en el protocolo de enlace de tres vías es siempre mayor que el tiempo de conexión aquí, este socket no puede establecer una conexión.
El tiempo de protocolo de enlace de tres vías que requerimos en este momento es de aproximadamente 180 ms.
Por ejemplo, en OkHttp, si la conexión se agota durante la fase de protocolo de enlace de tres vías, habrá un mecanismo de reintento. Es decir, se restablece la conexión y se reenvía el mensaje SYN para iniciar la conexión TCP. Al volver a conectarse, la ruta de la conexión cambiará. Si no hay una ruta alternativa, entonces esto realmente fracasa.
Bajo la configuración predeterminada de OkHttp 3.9.0, el tiempo de espera de la conexión es 10000ms = 10s. en OkHttpClient. Constructores
En la aplicación real, se deben realizar ajustes de acuerdo con los escenarios comerciales.
Para este requisito, para que Wireshark capture la bolsa del teléfono móvil, utilicé una computadora como proxy.
De hecho, el cliente A utiliza el protocolo HTTP para establecer una conexión con el servidor proxy B. Al igual que una solicitud HTTP normal, debe llevar el número de puerto IP. Si hay autenticación, también llevará información de autorización. El servidor proxy B utilizará la información de autorización para la autenticación.
Luego, el servidor proxy se conectará al host remoto y devolverá 200 después de que la conexión sea exitosa.
Wireshark capturó un paquete con dos datos, es decir, creó un proxy:
Mensaje de solicitud:
Mensaje de respuesta:
HTTP CONNECT es un nuevo comando en HTTP1.1 que admite el cifrado https.
Como uso un proxy para capturar paquetes, tengo este paso. Si captura el paquete HTTPS enviado por el navegador directamente en la PC, este proceso no ocurrirá.
Entonces consideremos por qué el servidor proxy necesita esta información, así como el nombre del host y el número de puerto al que conectarse.
Esto se debe a que el protocolo HTTP de cifrado SSL se implementó más tarde. Debido a que el servidor proxy no puede obtener la clave de cifrado, no puede obtener el encabezado HTTP y, por lo tanto, no puede saber a qué host se envió la solicitud. Por lo tanto, utilice el método CONNECT para informar al servidor proxy el nombre de host y el número de puerto correspondiente.
Esto también se conoce como protocolo de túnel HTTPS SSL. Después de establecer el túnel SSL, el agente reenviará los datos a ciegas.
Todo el protocolo SSL en realidad se divide en dos capas, el protocolo de registro SSL y otros subprotocolos (protocolo de reconocimiento SSL, protocolo de cambio de contraseña SSL, protocolo de advertencia SSL):
Estos dos protocolos La relación es en realidad la relación de encapsulación de datos. El protocolo de encapsulación de protocolo de enlace SSL encapsula otros protocolos de capa superior.
Protocolo de protocolo de enlace encapsulado:
Protocolo de datos de aplicación encapsulados, como HTTP:
Protocolo de intercambio de contraseñas encapsulado:
Protocolo de alerta encapsulado:
Por lo tanto, el protocolo de registro SSL es en realidad un portador de otros protocolos y solo proporciona funciones de encapsulación. Su formato es:
MAC es un código de verificación de mensajes, que se utiliza para verificar la integridad de los datos y garantizar que no haya manipulación en el proceso. Los códigos de verificación de mensajes son más débiles que las firmas digitales y el resumen se cifra con una clave simétrica. Las firmas digitales utilizan cifrado de clave asimétrica para distinguir entre claves públicas y privadas.
El propósito principal del protocolo de grabación es este y proporciona los siguientes servicios para otros subprotocolos SSL:
Después de que se completa el protocolo de enlace de tres vías TCP, la conexión del servidor proxy es exitoso, la conexión se establece exitosamente y el cliente A Cuando comienza a iniciar una conexión SSL, primero ingresará a la fase de protocolo de enlace SSL.
Los propósitos principales de la fase de protocolo de enlace SSL son los siguientes:
El proceso de protocolo de enlace SSL no es estático y depende del escenario de la aplicación real. Hay tres tipos principales:
El proceso de interacción completo del protocolo de enlace SSL es el siguiente. Aquí, el servidor y el cliente están autenticados:
Nuestra solicitud solo autentica el servidor, por lo que 7, 8 y 9 no están presentes.
Ahora analicemos detalladamente el contenido de cada etapa.
Hola cliente
Como primer paquete de protocolo de enlace SSL, hemos realizado un análisis detallado y una comprensión del contenido del paquete.
El siguiente es el paquete de datos del protocolo SSL analizado por Wireshark:
Cómo interpretar este paquete, según el análisis previo del protocolo SSL, en realidad está dividido en dos partes:
Debido a que es un proceso de protocolo de enlace, no hay una clave de negociación y aquí todavía se usa texto sin formato. El soporte de datos que registra el protocolo es el protocolo de protocolo de enlace SSL en texto claro.
El formato del protocolo de protocolo de enlace SSL es:
Podemos obtener esta información de los paquetes de datos del protocolo de protocolo de enlace:
Las suites de cifrado se desarrollan con el desarrollo de criptografía Y desarrollado, y dependiendo de la aplicación real, algunas contraseñas pueden ser descifradas, causando problemas de seguridad, por lo que generalmente se utilizan los conjuntos de cifrado más recientes y seguros.
En el sistema Android, en circunstancias normales, cuando se utiliza SSLSocket para conectarse, el conjunto de cifrado admitido por el sistema se incluirá de forma predeterminada. Sin embargo, este modelo tiene deficiencias, como que los algoritmos de cifrado de algunos conjuntos de cifrado están descifrados o vulnerabilidades de seguridad, y la respuesta es más lenta a medida que se actualiza el sistema. OkHttp utiliza la clase ConnectionSpec para proporcionar una gama de los últimos conjuntos de cifrado al realizar el protocolo de enlace con SSL.
Como puede ver en los comentarios, estos conjuntos de cifrado son totalmente compatibles con Chrome 51 y Android 7.0 y superiores.
Luego, estos conjuntos de cifrado se cruzan con los conjuntos de cifrado compatibles con el sistema Android y se envían al servidor. De esta manera, si hay un problema con algún conjunto de cifrado, se eliminará el soporte oficial de OkHttp. Con la iteración de la versión, la biblioteca de red OkHttp continuará proporcionando conjuntos de cifrado actualizados y abandonará aquellos conjuntos de cifrado inseguros. Acceda a la aplicación para actualizar OkHttp al instante para no tener que esperar actualizaciones lentas del sistema.
Si el servidor no admite todos los conjuntos de cifrado proporcionados, OkHttp tiene un mecanismo alternativo, por lo que lo mejor es elegir un conjunto más antiguo.
Hola servidor
El servidor recibe el saludo del cliente y proporciona la información de configuración final en función de la información de configuración del cliente y la propia situación del servidor.
El contenido de Wireshark analizado es el siguiente:
Los detalles son los siguientes:
Certificado
El servidor Hello mencionado anteriormente tiene Desarrolló el siguiente algoritmo de cifrado asimétrico.
El servidor emite un certificado y el cliente verifica la identidad del servidor y extrae la clave pública contenida en el certificado, es decir, la clave pública del algoritmo de cifrado de intercambio. Es decir, el algoritmo ECDHE (EC Diffie-Hellman) especificado en la fase Hola del servidor también se conoce comúnmente como cifrado DH.
Este mensaje de certificado envía una cadena de certificados del certificado digital y del certificado de CA, con su propia clave pública. En el campo del certificado:
CA es una parte importante del sistema PKI y se denomina autoridad de certificación.
Entonces, ¿qué es un certificado de CA? Se utiliza para certificar la validez del certificado emitido por el centro CA, que puede garantizar la confiabilidad del certificado y no ser reemplazado por un intermediario. ¿Pero también es posible que un intermediario intercepte y falsifique el certificado de CA? Luego autentíquelo usando otro certificado. Parece no tener fin nunca. De hecho, finalmente existe un certificado de CA raíz, que se almacena en el navegador o sistema operativo y el sistema confía directamente en él.
El certificado del servidor requiere un certificado CA para la autenticación. Aún utilizando firmas digitales, extrae información de los datos y la cifra con un certificado de CA. Luego, durante la verificación, se utiliza la clave pública del certificado de CA para descifrar, la parte de datos se resume utilizando el mismo algoritmo de agregación y se compara con la información descifrada.
El cliente dispone de un proceso para verificar la validez del certificado del servidor. Primero encontrará el certificado de certificación de este certificado, que es el certificado de CA intermedio. Luego busque el certificado de certificación del certificado de CA intermedio, que puede ser otro certificado de CA intermedio o el certificado de CA raíz. Esto llega al certificado de CA raíz.
Luego comience con el certificado de CA raíz y verifique la firma digital paso a paso. Por ejemplo, existe una cadena de certificados: Certificado de CA raíz -> Certificado de CA intermedia -> Certificado de servidor. Verifique la firma digital del certificado intermedio utilizando la clave pública del certificado de CA y luego verifique la firma digital del certificado del servidor utilizando la clave pública del certificado intermedio. Si falla alguna parte de la verificación, el certificado puede considerarse ilegal.
Este es el proceso de autenticación de toda la cadena de certificados:
Al observar los datos capturados, encontramos que solo hay dos certificados. Es el certificado del servidor y el certificado de CA intermedio. ¿Qué pasa con el certificado de CA raíz? Sigue las pistas para encontrarlo.
Primero mira el certificado del servidor.
El contenido es el siguiente:
Podemos vislumbrar esta información en este certificado:
El primero es el contenido del campo firmadoCertificado, que son los datos del certificado digital. :
Luego está la información de la firma de la autoridad de certificación:
Del emisor anterior, podemos saber que el certificado CA del certificado del servidor de autenticación es GeoTrust SSL CA-G3. El certificado intermedio correspondiente lo encontramos en Certificados de la siguiente manera (medio El certificado puede tener varios niveles, aquí solo tenemos un nivel):
El certificado intermedio que se puede obtener se llama GeoTrust SSL CA-G3, y la autoridad certificadora es GeoTrust Inc
El certificado de CA certificado ¿Dónde está el certificado? Veamos el campo emisor. El certificado de certificación se llama GeoTrust Global CA y la organización es GeoTrust Inc.
De hecho, este es el certificado de CA raíz. No se encuentra en esta solicitud, pero se puede encontrar en el navegador o sistema operativo. Los navegadores y sistemas comunes tendrán este certificado de CA integrado. Por lo tanto, el navegador o el sistema operativo confía en el certificado raíz y no requiere otros certificados como garantía.
Si desea que su sistema confíe en un certificado de CA raíz de una autoridad no general, instálelo.
Por ejemplo, mi sistema Windows tiene instalado un certificado CA GeoTrust Global:
Al igual que normalmente usamos Charles para capturar HTTPS, este es el principio en el que está instalado el certificado CA de Charles. el teléfono móvil y se convierte en un certificado de CA raíz de confianza.
El principio básico es que el proxy Charles actúa como un túnel SSL y no transmite de forma transparente, sino que actúa como intermediario, interceptando la información del protocolo de enlace SSL y modificando el certificado de CA en su interior. El teléfono móvil falso establece una conexión con el servidor real, obtiene la clave maestra, luego establece una conexión SSL entre el servidor falso y el cliente del teléfono móvil, modifica la CA y la firma digital del certificado del servidor y permite que Charles analice el HTTP cifrado. contenido.
El certificado del servidor modificado es el siguiente. Puede ver que el emisor es reemplazado por el certificado de Charles.