web-dev-qa-db-fra.com

Échec de la prise de contact SSL

Je travaille sur une application de bureau Windows créée à l'aide de C++ (IDE: Qt creator). Il a un panneau de connexion, où je fais la validation des utilisateurs via une connexion https en utilisant la bibliothèque openssl 1.0. L'application fonctionne sur la plupart des machines, mais je rencontre également une erreur "SSL Handshake failed" lors de la connexion https à partir de quelques machines.

J'ai essayé de déboguer l'erreur à l'aide de Wireshark. Mon observation est la suivante:

1) Le client envoie [SYN] au serveur.
2) Le serveur envoie [SYN, ACK] au client.
3) Le client envoie [ACK] au serveur.
4) Le client envoie le message "Client Hello" au serveur.
5) Le serveur envoie sa clé publique avec le message "Server Hello, Certificate, Server Hello Done"
6) Le client envoie sa clé publique avec le message "Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message"
7) Le serveur envoie un message de négociation chiffré avec le message "Modifier les spécifications de chiffrement, message de négociation chiffré"
8) Le client envoie [FIN, ACK]
9) Le serveur envoie [FIN, ACK]
10) Le client envoie [FIN]

À la 7e étape, dès que le client reçoit un message chiffré du serveur, le client lance la fin de la prise de contact par le signal FIN. Toute idée, pourquoi le client arrête-t-il la connexion SSL avec "échec de la prise de contact SSL" après l'échange des clés par les deux parties?

tlsopensslsession-management
5
ram

Votre description de la prise de contact semble indiquer que le client et le serveur ont effectué la prise de contact complètement, puis le client a abandonné la connexion. Cela signifie que "quelque chose" n'était pas juste du point de vue du client. Il y a principalement deux candidats possibles:

  1. Le certificat envoyé par le serveur n'est pas "correct"; le client a décidé qu'une validation de l'utilisateur était nécessaire. Le client a terminé la prise de contact afin qu'il puisse rouvrir la session SSL avec une "prise de contact abrégée" plus rapide (réutilisation du "secret principal" négocié sans avoir à refaire le cryptage asymétrique), mais a fermé la connexion afin de ne pas laisser les ressources ouvertes sur le serveur pendant que l'utilisateur humain se décide (le sac de viande est lent).

  2. Le message Finished envoyé par le serveur (c'est le "message de prise de contact chiffré") contient une valeur incorrecte (du point de vue du client) en raison d'un bug (probablement dans le client). Ce n'est pas un événement très probable.

Je suppose que vous êtes dans le premier cas: le serveur utilise une chaîne de certificats qui n'est "pas bonne" pour le client. Coupables habituels:

  • La chaîne de certificats du serveur n'est pas liée à l'une des "racines de confiance" du client (selon la bibliothèque utilisée sur le client, la liste des racines peut être à plusieurs endroits).
  • Le serveur nom, comme prévu par le client (celui dans son URL) n'est pas comparé aux noms dans le certificat du serveur.
  • L'horloge du client est complètement éteinte, elle rejette donc un certificat qui, de son point de vue, est soit émis "dans le futur", soit expiré depuis longtemps.
7
Tom Leek

exporter le certificat du serveur vers la machine cliente dans un fichier tel que servercert.crt. Sur le client exécutez: certutil -verify -urlfetch servercert.crt

Il vous expliquera presque certainement pourquoi la chaîne de certificats de serveur n'était pas considérée comme valide. Cordialement

4
lsousa