2013-07-07 13 views
7

Ho recentemente passato a HAProxy da AWS ELB. Sto terminando SSL al load balancer (HAProxy 1.5dev19).Come rintracciare gli errori di "Connection timout durante SSL handshake" e "Connection closed during handshake ssl"

Dopo il passaggio, continuo a ricevere alcuni errori di connessione SSL nel registro HAProxy (5-10% del numero totale di richieste). Ci sono tre tipi di errori che si ripetono: Connessione chiusa durante handshake SSL Timeout durante handshake SSL fallimento handshake SSL (questo accade raramente)

sto usando un certificato StartSSL libera, quindi il mio primo pensiero è stato che alcuni padroni di casa sono avendo problemi ad accettare questo certificato, e non ho visto questi errori in passato perché ELB non offre alcuna registrazione. L'unico problema è che alcuni host hanno finalmente connessioni riuscite.

Posso connettermi ai server senza errori, quindi non sono sicuro di come replicare questi errori sulla mia estremità.

risposta

8

Sembra che i clienti stiano andando via a metà handshake (TCP RST o timeout). Questo sarebbe normale ad un certo livello, ma il 5-10% sembra troppo alto. È possibile che si tratti di un problema di certificato; Io non sono certo esattamente come che presenta a

cose che si verificano a me:

  • Se la trattativa è molto lenta, avrete più clienti drop off.
  • Potresti avere problemi TCP sottostanti di cui non eri a conoscenza finché il tuo nuovo proxy endpoint SSL non ha iniziato a segnalarli.

Vedete singoli host che a volte riescono e talvolta falliscono? In tal caso, è improbabile che si tratti di un problema di certificato. Non sono sicuro di come le connessioni vengano abbattute quando un utente rifiuta un certificato non attendibile.

È possibile utilizzare Wireshark sulla macchina HAProxy per acquisire gli handshake SSL e analizzarli (non è necessario decodificare le sessioni per l'analisi dell'handshake, sebbene sia possibile disporre della chiave privata del server).

+1

Grazie a Tim per una risposta molto approfondita. In realtà è stata esattamente la tua prima ipotesi, quindi posterò i dettagli qui nel caso qualcuno avesse un problema simile. Abbiamo utilizzato questo back-end per servire una serie di app Android che inviavano analisi proprio mentre venivano chiuse. A volte (spesso su Android, meno spesso su iOS) non c'era abbastanza tempo per completare effettivamente la richiesta e l'app sarebbe stata uccisa durante la negoziazione https o immediatamente dopo, risultando in una richiesta BADREQ contrassegnata da HAProxy. Alla fine ho finito per usare ssldump e analizzare esattamente cosa stava andando storto. – andreimarinescu

0

Come è configurato il frontend haproxy ssl?

Per esempio io uso la seguente per mitigare gli attacchi BEAST: cifre 443 ssl crt /etc/haproxy/ssl/XXXX.pem no-SSLv3 RC4-SHA:: bind XXXX AES128-SHA: AES256-SHA

Ma alcuni client sembrano generare gli stessi errori "SSL handshake failure". Penso che sia perché la configurazione è troppo restrittiva.

1

Mi è capitato anche questo. Il seguente è apparso prima SSL handshake failure quindi, dopo lo spegnimento dello option dontlognull, è stato ottenuto Timeout during SSL handshake nei log di haproxy.

Inizialmente, mi sono assicurato che tutti i timeout defaults fossero corretti.

timeout connect 30s 
timeout client 30s 
timeout server 60s 

Sfortunatamente, il problema era nella sezione frontend

C'era una linea con timeout client 60 che presumo solo mezzo 60ms anziché 60s.

Sembra che alcuni client siano lenti a connettersi e siano stati espulsi durante l'handshake SSL. Controlla il tuo frontend per i timeout del client.

+0

grazie, adnan. Questo era davvero il problema, l'ho documentato nel mio commento sulla risposta di Tim. – andreimarinescu

Problemi correlati