Intestazione TLS nella porzione di contenuto della richiesta POST HTTPS gestita a caldo

Question

Intestazione TLS nella porzione di contenuto della richiesta POST HTTPS gestita a caldo

#1 da (2 voti)

0

Stiamo provando a comunicare da un'applicazione incorporata a un dispositivo tramite il protocollo HTTPS. Abbiamo difficoltà a farlo dall'applicazione incorporata, ma possiamo farlo con successo da Windows usando il comando Ricciolo. A livello di firmware con le librerie che stiamo utilizzando (libcurl, openssl) stiamo vedendo un'intestazione TLS aggiuntiva (riga) prima del contenuto della richiesta POST (ma dopo le intestazioni HTTPS del POST) mentre quella intestazione (riga) è non lì, quando comunichi al dispositivo da Windows.

Nota stiamo superando con successo l'handshake TLS in entrambi gli scenari.

La linea aggiuntiva è il ... 17 03 03 00 4d linea visualizzata nell'acquisizione per HttpsClient qui sotto. La prima cattura mostra la comunicazione tra Windows Curl e il dispositivo. La seconda cattura mostra la comunicazione tra l'applicazione incorporata e il dispositivo. Luoghi come link non hanno problemi a gestire questa riga di intestazione TLS in più poiché siamo in grado di comunicare con successo l'url dall'applicazione incorporata.

Nell'applicazione incorporata le versioni delle librerie sono: Libcurl: 7.41.0 (versione 25 febbraio 2015) Openssl: openSSL 1.0.2h

Non siamo stati informati su quali versioni di librerie vengono eseguite sul dispositivo.

Qualcuno ha già avuto a che fare con questo o ha qualche idea su come aggirare questo?

Ecco le catture ...

openssl tls curl

posta C. Brady 08.11.2017 - 23:06

fonte

1 risposta

Leggi altre domande sui tag openssl tls curl

Come sfruttare XSS riflesso per rubare i cookie Utilizzare il file PKCS # 12 per distribuire certificati CA affidabili?

score 2 · Accepted Answer

Non esiste una "linea di intestazione TLS". "17 03 03" nell'output significa solo l'inizio di un nuovo frame TLS con i dati dell'applicazione (tipo 23, ovvero 0x17, seguito dal protocollo TLS dove 0x0303 significa TLS 1.2).

L'output visualizzato indica invece che un client invia l'intestazione e il corpo POST all'interno di un singolo frame TLS mentre l'altro client invia l'intestazione POST in un frame e il corpo POST in un secondo frame. Ciò è probabilmente causato dal primo client che utilizza una sola SSL_write che include intestazione e corpo mentre il client secondi utilizza una scrittura SSL_write per l'intestazione e un'altra per il corpo. Questo è un comportamento perfettamente valido e potresti anche dividere il carico utile in un numero ancora maggiore di frame TLS. Ciò significa anche che il server probabilmente deve eseguire più letture per ottenere il messaggio HTTP completo (intestazione e corpo).

Se il server ha problemi con questo, il server è danneggiato. Tale rottura è spesso causata dal fatto che gli autori del server provano a scrivere il proprio stack HTTP semplicemente guardando alcuni messaggi HTTP, invece di usare uno stack stabilito o di leggere correttamente lo standard. Lo standard dice chiaramente dove inizia un messaggio HTTP e dove finisce. E poiché HTTP è impostato su un protocollo di streaming, potrebbe essere possibile che siano necessarie più letture per ottenere il messaggio HTTP completo. Questo è probabilmente il motivo per cui riesce con qualche server correttamente implementato ma non con il tuo server rotto.