SSL Handshake non riuscito

Question

SSL Handshake non riuscito

#1 da (7 voti)
#2 da (4 voti)

5

Sto lavorando su un'applicazione desktop Windows che viene creata usando C ++ (IDE: Qt creator). Ha un pannello di login, dove faccio la convalida dell'utente tramite la connessione https usando la libreria 1.0 di openssl. L'applicazione funziona nella maggior parte delle macchine, ma sto riscontrando anche un errore "SSL Handshake failed" durante l'esecuzione della connessione https da poche macchine.

Ho provato a eseguire il debug dell'errore utilizzando wireshark. La mia osservazione è la seguente:

1) Il client invia [SYN] al server.
2) Il server invia [SYN, ACK] al client.
3) Il client invia [ACK] al server.
4) Il client invia il messaggio "Client Hello" al server.
5) Il server invia la sua chiave pubblica con il messaggio "Server Hello, Certificate, Server Hello Done"
6) Il client invia la sua chiave pubblica con il messaggio "Scambio chiavi client, Modifica specifiche cifrario, Messaggio crittografato di handshake"
7) Il server invia un messaggio di handshake crittografato con il messaggio "Modifica specifiche cifrario, messaggio crittografato di handshake"
8) Il client invia [FIN, ACK]
9) Il server invia [FIN, ACK]
10) Il client invia [FIN]

In 7a fase, non appena il client riceve il messaggio crittografato dal server, il client avvia la chiusura dell'handshake tramite il segnale FIN. Qualche idea, perché il client abbatte la connessione ssl con "SSL handshake failure" dopo che entrambe le parti hanno scambiato le chiavi?

openssl tls session-management

posta ram 05.02.2014 - 08:42

fonte

2 risposte

Leggi altre domande sui tag openssl tls session-management

crittografia a chiave simmetrica rispetto all'hashing HTTP Web e insicuro - Utilizzo di RSA per crittografare le password sul lato client

score 7 · Answer 1

La descrizione della stretta di mano sembra indicare che il client e il server hanno condotto l'handshake completamente, e quindi il client ha interrotto la connessione. Ciò significa che "qualcosa" non era giusto dal punto di vista del cliente. Ci sono principalmente due possibili candidati:

Il certificato inviato dal server non è "corretto"; il cliente ha deciso che è necessaria la convalida dell'utente. Il client ha completato l'handshake per riaprire la sessione SSL con una "stretta di mano abbreviata" più veloce (riutilizzando il "master secret" negoziato senza dover nuovamente ricorrere alla crittografia asimmetrica), ma ha chiuso la connessione in modo da non mantenere le risorse aperte il server mentre l'utente umano prende una decisione (il sacchetto di carne è lento ).
Il messaggio Finished inviato dal server (che è il "messaggio di handshake crittografato") contiene un valore errato (dal punto di vista del client) a causa di qualche bug (probabilmente nel client). Questo non è un evento molto probabile.

La mia ipotesi è che tu sia nel primo caso: il server usa una catena di certificati che non è "buona" per il cliente. Colpevoli colpevoli:

La catena di certificati del server non si collega a una delle "radici attendibili" del client (a seconda della libreria utilizzata sul client, l'elenco delle radici può trovarsi in più posizioni).
Il server nome , come previsto dal client (quello nel suo URL) non è confrontato con i nomi nel certificato del server.
Il clock del client è completamente disattivato, quindi rifiuta un certificato che, dal suo punto di vista, viene emesso "in futuro" o scaduto a lungo.

score 4 · Answer 2

esportare il certificato del server sul computer client in un file come servercert.crt. Sulla corsa del cliente: certutil -verify -urlfetch servercert.crt

Quasi certamente ti dirà perché la catena di certificati del server non è stata considerata valida. Saluti