encabezado TLS en la parte de contenido de la solicitud POST de HTTPS bien manejado

0

Estamos intentando comunicarnos desde una aplicación integrada a un dispositivo a través del protocolo HTTPS. Tenemos dificultades para hacerlo desde la aplicación incrustada, pero podemos hacerlo correctamente desde Windows usando el comando Curl. En el nivel de firmware con las bibliotecas que estamos utilizando (libcurl, openssl), vemos un encabezado TLS (línea) adicional antes del contenido de la solicitud POST (pero después de los encabezados HTTPS del POST), mientras que ese encabezado (línea) es no allí, cuando se comunica al dispositivo desde Windows.

Nota estamos superando con éxito el protocolo de enlace TLS en ambos escenarios.

La línea adicional es la ... 17 03 03 00 Línea 4d mostrada en la captura.  para el HttpsClient a continuación. La primera captura muestra la comunicación entre Windows Curl y el dispositivo. La segunda captura muestra la comunicación entre la aplicación integrada y el dispositivo. Las ubicaciones como enlace no tienen ningún problema en el manejo de esta línea de encabezado TLS adicional, ya que podemos comunicarnos con éxito desde esa aplicación.

En la aplicación integrada, las versiones de las bibliotecas son: Libcurl: 7.41.0 (versión del 25 de febrero de 2015) Openssl: openSSL 1.0.2h

No se nos ha informado qué versiones de las bibliotecas se están ejecutando en el dispositivo.

¿Alguien ha lidiado con esto antes o tiene alguna idea sobre cómo solucionarlo?

Aquí están las capturas ...

    
pregunta C. Brady 08.11.2017 - 23:06
fuente

1 respuesta

2

No hay tal cosa como una "línea de encabezado TLS". "17 03 03" en su salida solo significa el comienzo de una nueva trama TLS con datos de aplicación (tipo 23, es decir, 0x17, seguido por el protocolo TLS, donde 0x0303 significa TLS 1.2).

La salida que muestra en su lugar significa que un cliente está enviando el encabezado y el cuerpo de la POST dentro de un solo marco TLS mientras que el otro cliente está enviando el encabezado de la POST en un marco y el cuerpo de la POST en un segundo marco. Probablemente, esto se debe a que el primer cliente utiliza una única escritura de SSL que incluye encabezado y cuerpo, mientras que el cliente de segundos utiliza una escritura de SSL para el encabezado y otra para el cuerpo. Este es un comportamiento perfectamente válido e incluso podría dividir la carga útil en incluso más marcos TLS. Esto también significa que el servidor probablemente deba realizar varias lecturas para obtener el mensaje HTTP completo (encabezado y cuerpo).

Si el servidor tiene problemas con esto, entonces el servidor está roto. Dichos problemas a menudo se deben a que los autores del servidor intentan escribir su propia pila de HTTP con solo mirar unos pocos mensajes HTTP, en lugar de usar una pila establecida o leer correctamente el estándar. El estándar dice claramente dónde comienza un mensaje HTTP y dónde termina. Y dado que HTTP se establece sobre un protocolo de transmisión, es posible que se necesiten varias lecturas para obtener el mensaje HTTP completo. Esta es probablemente la razón por la que tiene éxito con un servidor implementado correctamente pero no con un servidor roto.

    
respondido por el Steffen Ullrich 09.11.2017 - 06:15
fuente

Lea otras preguntas en las etiquetas