OpenSSL s_client: il 403 del proxy arriva prima del TLS di destinazione
Interpreta un 403 su CONNECT tramite un proxy OpenSSL come un guasto della fase di tunnel e non diagnosticare il certificato di destinazione da un handshake che non è mai iniziato.
Se openssl s_client riceve un HTTP 403 in risposta alla sua richiesta CONNECT tramite il proxy, parti da quel rifiuto. Il tunnel richiesto non è stato stabilito.
Con -proxy, s_client chiede prima al proxy HTTP di connettersi alla destinazione indicata da -connect. Solo una risposta CONNECT riuscita trasforma questo scambio in un tunnel per l'handshake TLS della destinazione.
Questo ordine spiega un output altrimenti confuso: un errore del proxy seguito da intestazioni relative a TLS, nessun certificato del peer o una riga di verifica apparentemente rassicurante. Quei campi non dimostrano che il certificato della destinazione sia stato ricevuto e verificato. L'operazione si è fermata a uno stadio precedente.
Annota la risposta del proxy nonché l'host e la porta di destinazione richiesti. Un 403 sposta l'attenzione sulla decisione di accesso del proxy; un 407 richiede l'autenticazione al proxy. Nessuno dei due si risolve disattivando la verifica del certificato di destinazione.
Quando è consentito ispezionare lo scambio, l'output -debug di s_client può aiutare a svelare il rifiuto. Tieni qualsiasi credenziale del proxy fuori dalle tracce condivise. Un tunnel riuscito avrebbe comunque bisogno in seguito di una propria valutazione di TLS e dei certificati, ma non c'è alcuna catena di certificati di destinazione da diagnosticare finché quella fase non è stata realmente raggiunta.